Subject: draft-snir-polic-quo-infomodel-00.txt

From: "Jon Sjoberg" <[email-masked]>
Date: Tue, 28 Sep 1999 12:23:22 -0400

Had some comments on the above draft.

First the mundane stuff:
Pgr 1.2.1.1.1.2: 2nd sentence ("Each atom folder contains..."), last word is
"atoms", S/B "constants".

Pgr 1.2.2:
  First pgrph after the diagram: Start using "qosPolicyRule" here, but the
diagram and later document refers to "qosPolicy" (also in beginning of 1.3).
  Second pgrph after the diagram: Start using "qosPolicyNamedPolicyGroup",
but diagram and later document refers to "qosNamedPolicyContainer".

Pgr 4.1: "DERIVED FROM: Policy" S/B "DERIVED FROM: Policy Group" (said so on
pg. 2)

Pgr 4.5:
  Transposed "qos" and "named" in prose so "qosNamedPolicyContainer" became
"namedQosPolicyContainer"
  "AUXILIARY CLASSES" section duplicates "PolicyRuleContainmentAuxClass"
(one s/b group)

Pgr 4.6.1:  Have "in" and "out", not sure what that means.  Into the router,
input queue, into the policy domain, into the network, etc.

Now for something completely different...

Class qosPolicyRoot:  Why have redirections to the list of repository/domain
DN names, why not just have the list right here.  Saves an LDAP read and
eliminates two classes and two attributes from a pretty complex schema, and
I'm not sure we lose anything.

General: Why are there so many DN references to do what directory tree
structuring could/should do?  The qosPolicyDomain class could be a container
class, and all qosPolicyRules have to be subordinate to that class.  In this
case a whole domain of policies could be loaded in one LDAP request.  While
the current DN referencing approach gives some flexibility, the cost is
increased complexity for an implementation that really isn't recomended
(having qosPolicy dispersed sparsely through the tree).

General 2: The whole QoS scheme is becomming quite large and complex to
support features which aren't yet required or, in some cases, recommended.
Also, as large/complex as it is, it is still far short of what an
implementation needs to really do QoS level policies.  We are still missing
the basic concepts of a "flow" or "traffic profile", never the less
"application" or "service".

Jon

---

From: "Yoram Snir" <[email-masked]>
Date: Thu, 30 Sep 1999 14:08:44 -0700

Jon
Thanks for the comments, a new version (01) will be submitted before the
next IETF meeting that would include some additions and fixes to the
version00 of the draft.
Please see inline for specifics.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jon Sjoberg
> Sent: Tuesday, September 28, 1999 9:23 AM
> To: [email-masked]
> Subject: draft-snir-polic-quo-infomodel-00.txt
>
>
True, will be fixed.
> but diagram and later document refers to "qosNamedPolicyContainer".
True, typos will be fixed in next version.
> Pgr 4.1: "DERIVED FROM: Policy" S/B "DERIVED FROM: Policy
Thanks, the error is in the text.
> input queue, into the policy domain, into the network, etc.

It refers to the direction of the flow per interface (diff-serv model).
We will explain it in details in the next version.
> (having qosPolicy dispersed sparsely through the tree).
As for downloading everything in one LDAP query, you can do it since,
although dn references appears in each container, the referenced elements,
unless they are reusable elements are located as sons of the referencing
object. In this case, rules and policy named groups are not reusable, so
they will appear as children of the qosPolicyDomain.

The value of the reference is in the consistency checking mechanism it
allows, especially in a multi readers / writers environment. This issue is
under discussion on the mailing list.

Each domain has other attributes associated, such as Per Hop Behavior of the
domain. The next version defines PHB and associates a PHB set to a domain.
That is the reason the qosPolicyDomain  was not just a container.

> "application" or "service".
The next version includes the notion of "application", "service" and
"traffic profile", or at least the way we understand them.