Subject: RE: Comments on draft-ietf-policy-terminology-03.txt

From: "Andrea Westerinen" <[email-masked]>
Date: Mon, 7 May 2001 17:33:40 -0700

Thanks for the comments.  Replies inline.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Guus Sliepen
Sent: Monday, May 07, 2001 7:49 AM
To: [email-masked]
Cc: AAAARCH mailing list
Subject: Comments on draft-ietf-policy-terminology-03.txt

Hello,

We've been asked by Ed Elleson to review your terminology draft since it's
in
Last Call. I've send a subscribtion request for the policy mailing list but
since I haven't received a confirmation yet, please CC me if you reply to
this.

  $ Authentication, Authorization, Accounting (AAA)
      (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
        [...]

This is not a definition of the term "AAA". But since this document is all
about AAA, maybe the term itself should be explained as well.

<arw> We purposely did not try to define AAA since we only talk about AAA as
an area of use.  Aspects of policy and AAA can exist without the other.  My
concern is that the definition of AAA should reside with the AAA WG, not
with the Policy WG or its terminology document.

  $ Differentiated Services (DS)
      (T) The IP header field, called the DS-field. In IPv4, it
        defines the layout of the ToS (Type of Service) octet; in
        IPv6, it is the Traffic Class octet. [R2474]

This is only a very specific part of DS. There is also routing based on for
example source IP or protocol type/port number. This definition appears to
me
as if what you describe is the only thing to DS.

<arw> There is also an "(A)" (area of use) documented in the definition and
a pointer to "Quality of Service."  Again, our definition takes its lead
from the DiffServ WG's documents and charter.  That said, the definition
could be expanded as follows:
      (A) "Differentiated Services" is also an "area of use" for
        QoS policies. It requires policy to define the
        correspondence between codepoints in the packet's DS-field
        and individual per-hop behaviors (to achieve a specified
        per-domain behavior). In addition, policy can be used to
        specify the routing of packets based on various classification
        criteria. (See also "Quality of Service" and "filter.")
The sentence before "(See also ..." is added, also the reference to "filter"
is added.  And, we would have to add a similar sentence to the definition of
"Quality of Service."

  $ information model
      (T) An abstraction and representation of the entities in a
        managed environment, their properties, attributes and
        operations, and the way that they relate to each other. It
        is independent of any specific repository, application,
        protocol, or platform.

I think you mean "implementation" instead of "application". QoS for example,
is an application.

<arw> "Application" refers to "software usage".  Repositories, software that
uses the model, protocols and platforms are all "implementations."  I can
change the wording to "software usage", if this is clearer.

  $ policy condition
      (P) A representation of the necessary state and/or
          [...]
        - In [R3060], a rule's conditions can be expressed as
           either an ORed set of ANDed sets of statements
           (disjunctive normal form), or an ANDed set of ORed sets
           of statements (conjunctive normal form). Individual
           condition statements can also be negated.

I think the second part of this definition should be labeled with a (T).

<arw> Agreed.

  $ policy enforcement
      (P) The execution of a policy decision.

Shouldn't that be the execution of the actions related to a policy decision?

<arw> A "policy decision" is the resultant set of actions.  The definition
for policy decision reads:
  $ policy decision
      (P) Two perspectives of "policy decision" exist:
        - A "process" perspective that deals with the evaluation of
           a policy rule's conditions
        - A "result" perspective that deals with the actions for
           enforcement, when the conditions of a policy rule are
           TRUE
The decision and enforcement definitions are coupled.

  $ Service Level Specification (SLS)
      (P) Specifies handling of a customer's traffic by a network
        provider. It is negotiated between a customer and the
        provider, and defines DiffServ parameters (such as specific
        Code Points and Per-Hop-Behaviors, profile characteristics
        and treatment of the traffic for those Code Points).
        [...]

Policies can also be about other things than QoS, I think you shouldn't
mention the part about DiffServ. I know you are doing lots of QoS specific
things, but this is still is the Policy Terminolgy draft from the Policy
Framework WG :).

<arw> The major focus of the Policy Framework WG was/is QoS.  That is the
reason behind this focus in the terminology draft.  However, we could
address your concern/comment by modifying the definition slightly to read
(changes in CAPS):
      (P) Specifies handling of a customer's traffic by a network
        provider. It is negotiated between a customer and the
        provider, and (FOR EXAMPLE) IN A DIFFSERV ENVIRONMENT,
        defines parameters such as specific Code Points and
        Per-Hop-Behaviors, profile characteristics and
        treatment of the traffic for those Code Points.
        [...]

-------------------------------------------
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[email-masked]>
-------------------------------------------
See also: http://tinc.nl.linux.org/
          http://www.kernelbench.org/
-------------------------------------------