Subject: FW: Policy Terminology Draft

From: "Andrea Westerinen" <[email-masked]>
Date: Mon, 28 Aug 2000 11:16:31 -0700

Juergen, Replies inline.

Thanks.
Andrea

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, August 22, 2000 3:39 AM
To: [email-masked]; Keith McCloghrie
Cc: [email-masked]
Subject: Re: Policy Terminology Draft

>>>>> Andrea Westerinen writes:

Andrea> The Policy Framework WG has created an I-D to try to
Andrea> disambiguate policy terminology across all IETF Work Groups.

[...]

Andrea> Please look the draft over, and if you have feedback, please
Andrea> reply to me and/or to the policy mail list
Andrea> ([email-masked]).

I have read <draft-ietf-policy-terminology-00.txt> and I believe that
this document is very valuable. I also have some comments you may want
to consider when you revise this text.

 1. The definition of "Authentication, Authorization, Accounting" has
    lots of text on the current process within the AAA and related
    WGs. For example, the last sentence is IMHO completely irrelevant
    in the longer term (which does of course not mean that the work
    being done is irrelevant). I suggest to rewrite at least the last
    two sentences in this definition (perhaps removing most of it).

<arw> In rereading the definition, the last sentences really don't add to
the explanation/definition of policy and its applicability to AAA.  So, we
will just remove them from the draft.  There were also some decisions made
in AAA in Pittsburgh that need to be reflected in the text - so the new AAA
explanation reads:
     (A) AAA efforts in the IETF have focused on the most widely
       deployed use of authentication: Remote Authentication Dial In
       User Service (RADIUS), and its expansion in Diameter (a "radius"
	 pun and not an acronym, DIAMETER). Referencing the RADIUS RFC
       (R2138), a network access server sends dial-user credentials to a
       AAA server, and receives authentication that the user is who he/she
       claims along with a set of attribute-value pairs authorizing
       various service features for that user. Policy is implied in
       both the authentication, which can be restricted by time of day,
       number of sessions, calling number, etc., and the attribute-
       values authorized.

 2. In the definition of CIM, you wrote: "CIM includes a set of files,
    written in the language specified in the Specification. These are
    known as the Core and Common Models, and define an information
    model for the "enterprise" ..." I think this puts too much
    importance on the concept of storing CIM models in a (MOF) file,
    which is just one way to represent a CIM model. Many people are
    much more familiar with the graphical UML-style representation of
    CIM models, I think. And this is not even explicitly mentioned
    in the CIM definition.

<arw> Here is a rewrite ...
     (M) An object-oriented information model published by the DMTF
       (Distributed Management Task Force) [DMTF]. It consists of a
       Specification detailing the abstract modeling constructs and
       principles of the Information Model, and a textual language
       definition to represent the Model. CIM's schemas are defined
       as a set of files, written in the language of the Specification,
       with graphical renderings using UML [UML]. Sets of classes and
	 associations represent CIM's Core and Common Models, defining
       an information model for the "enterprise" - addressing general
	 concepts (in Core), and systems, devices, users, software
       distribution, the physical environment, networks and policy (in
       the Common Models). (See also "information model.")

 3. You define IPSP, which is an IETF working group. You do not define
    other working groups. I think that not defining working groups in
    this document is a good thing since WGs come and go (even though
    some WGs seem to never really go away ;-).

<arw> This is a valid point.  We should only list "areas" of work, not WGs.
But we must be sure to include all the data models, specification language
and exchange protocols defined by IPSP in the terminology draft.

 4. The definition of MPLS as a "label swapping framework" surprised
    me - but this indeed what RFC 2702 says. Anyway, I believe that
    "label switching framework" or perhaps "label swapping and
    switching framework" is less confusing - at least for me.

<arw> Will change wording.

 5. I have some more important problems with the definition of a
    Policy Rule Class. The current text says:

    $ Policy Rule Class (PRC)
       (M) An ordered set of scalar attributes, defined in a PIB. "Policy
         Rule Classes" are arranged in a hierarchical structure similar
         to tables in SNMP's SMIv2. [R2578, PIB]

    I suggest to use the following text:

    $ Policy Rule Class (PRC)
       (M) An ordered set of attributes. PRCs are defined in PIB modules
         and registered in the Object Identifier tree. PRIs which are
         instances of the same PRC are organized in a table, similar to
         conceptual tables in the SMIv2. [R2578, SPPI]

<arw> OK - text will be updated.

    Note that reference [PIB] does not exist anymore.

<arw> I think that the correct reference is draft-ietf-diffserv-pib-01.txt.
Also, we will include the framework PIB reference
(draft-ietf-rap-frameworkpib-00.txt).

    I also found
    "scalar attribute" confusing for people who are familiar with
    SMIv2 scalars. You probably wanted to highlight the fact that PRC
    attributes are primitive and not compound - but I think you need
    to be more precise if this details is really essential. I also
    think the acronym PRI should be defined in this document, e.g.

    $ Policy Rule Instance (PRI)
       (M) is an instantiation of a PRC.

    $ PRI
       See "Policy Rule Instance"

<arw> Will add.

 6. Now to my fundamental PRC/PRI terminology concern: The usage of
    "policy rule" in the terms PRC and PRI conflicts with the
    definition of the term "policy rule". A PRC does not bind actions
    to a set of conditions.  This is IMHO a very fundamental
    terminology problem we have.

    In my view of the world, PRCs and PRIs just convey (network-wide)
    configuration information to a device. So a better explanation of
    these acronyms (if we want to keep them) would probably be
    "Provisioning Class (PRC)" and "Provisioning Class Instance
    (PRI)". One could also argue that different terms should be used
    here.

    I do not expect that there is agreement here on changing the
    interpretation of PRC and PRI or to introduce new terms to replace
    them. But I think it is important to highlight that there is at
    least a problem here.

<arw> In discussions among the editors of the draft, we agree with your
distinction here.  We will clarify the PolTerm draft, and indicate that a
discrepancy exists between the use of the words "policy rule" in PRC and
other drafts.  Also, we will work with the RAP team to try to get different
words adopted for PRC (based on your suggestion of Provisioning Class).

 7. The example for "policy translation" is about the conversion of a
    PIB into a CLI format. I think we had several discussions about
    translations and mappings before. What you describe here is
    probably what some of us would call a mapping and not a
    translation. It is also unclear to me whether policy conversion is
    the same as policy translation and/or policy mapping. Perhaps
    policy conversion is the superset of policy translation and policy
    mapping, where policy translations happen between abstraction
    levels and policy mappings happen between different
    representations at the same abstraction level?

<arw> These distinctions are actually not made in any draft and seem to draw
arbitrary dividing lines between synonomous terms. The example that you site
is listed specifically as an example. We discussed this issue at some length
among the PolTerm editors and found that one person's/implementation's view
of changing "levels" was another's view of staying at the same level.  We
will be happy to add some text that "policy mapping" is another synonym -
but the essence of translating/converting/mapping is the "transformation of
a policy from a representation and/or level of abstraction, to another
representation and/or level of abstraction." This is how the draft is
currently worded.

 8. There are some funny characters in the definition of "service".

<arw> Will remove these.

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Aug 2000 11:05:07 +0200

>>>>> Andrea Westerinen writes:

Andrea> [...] so the new AAA explanation reads:

Looks good to me.

Andrea> Here is a rewrite ...

[...]

Andrea> graphical renderings using UML [UML]. Sets of classes and
Andrea> associations represent CIM's Core and Common Models, defining
Andrea> an information model for the "enterprise" - addressing general
Andrea> concepts (in Core), and systems, devices, users, software
Andrea> distribution, the physical environment, networks and policy
Andrea> (in the Common Models). (See also "information model.")

So the "Policy Core Information Model" produced by the Policy WG is a
"Common Model" in CIM terminology, right? Isn't that a bit confusing?

[...]

Andrea> These distinctions are actually not made in any draft
Andrea> and seem to draw arbitrary dividing lines between synonomous
Andrea> terms. The example that you site is listed specifically as an
Andrea> example. We discussed this issue at some length among the
Andrea> PolTerm editors and found that one person's/implementation's
Andrea> view of changing "levels" was another's view of staying at the
Andrea> same level.  We will be happy to add some text that "policy
Andrea> mapping" is another synonym - but the essence of
Andrea> translating/converting/mapping is the "transformation of a
Andrea> policy from a representation and/or level of abstraction, to
Andrea> another representation and/or level of abstraction." This is
Andrea> how the draft is currently worded.

So are we going to kick people out of the door in the future who start
arguing about the differences between translations and mappings? Or
are we just taking the easy way out here?

Sure, the line between translations and mappings will be somewhat
fuzzy - but I generally thought that the distinction is useful. My
understanding is that a translation requires significant additional
input from secondary sources while a mapping just transforms the
primary input into some new output format:

(a)         input
              |
	      v
         translation <-- significant secondary input
              |
              v
           output

(b)         input
              |
	      v
           mapping
              |
              v
           output

For example, a rule which refers to the accounting department needs
significant secondary information to turn it into concrete device
configurations that use IP addresses to identify traffic to/from the
accounting department while a mapping from a CIM model to an LDAP
schema is basically an algorithmic problem where secondary input is
only needed to fine tune the mapping.

But perhaps you are right that this is just a rathole.

/js

---

From: Bob Natale <[email-masked]>
Date: Wed, 30 Aug 2000 14:57:34 -0400

At 8/28/2000:02:16 PM, Andrea Westerinen wrote:

Hi Andrea,

>representation and/or level of abstraction." This is how the draft is

Hmmm.  "Transformation" and "conversion" imply more or less
the same thing to me in this context...both encompass the
kinds of actions denoted by "translation" and "mapping"
(and probably other terms as well).  However, to my understanding,
there is an important diff between "translation" and "mapping"
(as typically used in technical literature); namely:

   - mapping is deterministic, a set of precise rules
     govern the conversion process; whereas

   - translation allows for interpretation (e.g., the
     application of alternatives) during the conversion
     process.

However, I realize this issue could be debated at this
level forever.  So, while I understand and favor Juergen's
suggestion in this respect, I think the explanation you
offer above for the course of action you want to follow
is reasonable enough.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: Jon Saperia <[email-masked]>
Date: Thu, 31 Aug 2000 07:22:42 -0400

>> representation and/or level of abstraction." This is how the draft is

I wanted to comment on this piece specifically though it was in an exchange
between Bob and Andrea since it helps illustrate one of the points about
levels of abstraction I made in my comments to this group a few days ago and
in the ID I pointed to.

In short, we want to keep the levels of abstraction discussion (and terms)
distinct from the transport conversion or access mechanism terms. What an
object will look like at any level of abstraction will change depending on
the access method. What I mean by this is that if I am expressing a PBH for
a class of traffic via the CLI, it will look quite different than if I
express it via a PIB or MIB. In fact, not all transport/access methods have
mappings to all levels of abstraction.

Could we use 'conversion' as opposed to translation to refer to the task of
changing a policy at whatever level of abstraction to a protocol specific
form. This may not always be obvious or algorithmic.

/jon

---

From: Jon Saperia <[email-masked]>
Date: Thu, 31 Aug 2000 10:02:52 -0400

on 08/31/2000 9:26 AM, John Schnizlein at [email-masked] wrote:

> After raising the issue Juergen (who missed the "benefit" of our
> conference call "discussion") reached the same conclusion we did.
> Reaching consensus on particular distinctions is impossible and
> pointless. Although we all agree some amount of conversion
> (translation, mapping) occurs, it need not be standardized.

I am confused by this. I thought the purpose was to come up with terms that
we agreed were relevant to this area. What I am suggesting is that while we
may not agree on how the translation/mapping takes place we should have
common protocol neutral terms that describe levels of abstraction as opposed
to the function of translating them (or whatever term we select) for
protocol specific purposes.

With regard to levels of abstraction, I think they are fundamentally
important and a useful set of levels are needed.

/jon

---

From: John Schnizlein <[email-masked]>
Date: Thu, 31 Aug 2000 09:26:39 -0400

The exchange excerpted below suggests the sort of argument that
appears whenever we attempt to define translation (conversion, 
or mapping) between different levels of abstraction.
How many levels? What should they be? 
Between which is the process conversion or mapping or translation? 
It was because these philosophical discussions do not lead to
any conclusion that we chose not to attempt a consensus definition.

John

At 11:05 AM 08/29/2000 +0200, Juergen Schoenwaelder wrote:
>...
>arguing about the differences between translations and mappings? 
>Or are we just taking the easy way out here?
>...

At 07:22 AM 08/31/2000 -0400, Jon Saperia wrote:
>...
>Could we use 'conversion' as opposed to translation to refer to the 
>task of changing a policy at whatever level of abstraction to a 
>protocol specific form. This may not always be obvious or algorithmic.

At 08:35 AM 08/31/2000 -0400, [email-masked] wrote:
>...
>Changing it to a protocol-specific form from what?  The only
>answer that I can think of is "From another protocol-specific form."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Aug 2000 17:54:11 +0200

>>>>> John Schnizlein writes:

John> After raising the issue Juergen (who missed the "benefit" of our
John> conference call "discussion") reached the same conclusion we
John> did.  Reaching consensus on particular distinctions is
John> impossible and pointless. Although we all agree some amount of
John> conversion (translation, mapping) occurs, it need not be
John> standardized.

This was not really my conclusion. For me, there is a difference
between translations and mappings.

What I agree with is the observation that in many real-world
situations, you may end up doing 95 % translation + 5 % mapping or 95
% mapping plus 5 % translation to get a job done. So discussing
whether a concrete action is a translation or a mapping may turn out
to be a rathole because most of these actions will be a combination
of both.

But this does not mean that a conceptual differentiation between these
two activities translation and mapping is not worthwhile to understand
and communicate about fundamental concepts in policy-based mgmt.

/js

---

From: Bob Natale <[email-masked]>
Date: Thu, 31 Aug 2000 14:02:41 -0400

At 8/31/2000:07:22 AM, Jon Saperia wrote:

Hi Jon,

>form. This may not always be obvious or algorithmic.

Sounds good to me...your final sentence there rules
out "mapping" in my view (as much as I wish we could
do mappings!) and "conversion" seems better suited
(i.e., somewhat more predictable) than "translation".

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------