Subject: Policy Terminology Draft

From: "Andrea Westerinen" <[email-masked]>
Date: Fri, 18 Aug 2000 00:44:37 -0700

This note has been sent to the AAA, ISSLL, RAP, DiffServ, IPSP, MPLS,
SNMPCONF and RSVP mail lists.

The Policy Framework WG has created an I-D to try to disambiguate policy
terminology across all IETF Work Groups.  This draft is located at:
http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-00.txt

In creating the draft, the team tried to look across all RFCs and WGs to
gain an understanding of policy and its applicability, and consolidate
definitions.  At the Pittsburgh Policy Framework session, it was recommended
that this draft be forwarded to all work groups where it may be applicable.
(If you receive multiple copies, my apologies.)

Please look the draft over, and if you have feedback, please reply to me
and/or to the policy mail list ([email-masked]).  Some questions to
be considered are ... Are there definitions that should be updated?  Are
there additional terms that should be defined?

For the current terms in the draft, please try to use these terms
consistently.  Our goal is to take this draft through the standards process
and have it serve a function similar to RFC2828.

Thanks.
Andrea Westerinen
Policy Terminology Draft Editor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Aug 2000 12:38:53 +0200

>>>>> 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).

 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.

 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 ;-).

 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.

 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]

    Note that reference [PIB] does not exist anymore. 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"
 
 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.

 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?

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

/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/>