Subject: Comments on QPIM-01 draft

From: [email-masked]
Date: Thu, 31 Aug 2000 13:30:07 -0400

Since the end of August is upon us, here are some
comments I have on the QPIM-01 draft.  I hear from
JohnS that the authors are working on a new version
of the document, so some of these concerns may have
already been addressed.  But I'd like to get them
onto the list now:

1. Showing its roots, the QPIM is still much more
   of a thinly veneered LDAP schema than it is
   a technology independent information model.
   For example:
     - There are *no* new associations defined in
       the QPIM.
     - Containment language still plays far too
       prominent a role in the QPIM.

2. The class QosPolicySimpleCondition is supposed
   to be a subclass of PolicyCondition (from PCIM),
   which places it under ManagedElement.  But a
   subclass of ManagedElement can't have the
   object references that QosPolicySimpleCondition
   contains -- object references are allowed only
   in association classes.

3. Something's not quite right with the modeling of
   meters in QPIM.  The parameters for a meter are
   modeled not in the meter object itself, and not
   even in an object directly related to the meter
   object.  Instead, they're in a traffic profile
   object associated with an action object, which
   in turn is associated with the meter object.
   Since multiple action objects can be associated
   with a single meter (representing the fan-in of
   multiple traffic streams into that one meter),
   this opens up the possibility of having two
   incompatible traffic profiles governing the
   operation of a single meter.

4. The document says that constraints are modeled
   in QPIM, but I can't find any class to do this.

5. The qpValueTypes property appears to repeat the
   same information that's already expressed in
   the document in Table 3.  (Aside:  This table
   looks like one that will need to transition to
   IANA once QPIM is published as an RFC.)  Why
   is this known information being repeated in
   every instance of qosPolicyVariable?

6. For the variable names "Application" and "User"
   (in Table 2), how does an implementation know
   where in the packet to look for the values?
   In other words, how does an implementation know
   how to go about evaluating a
   QosPolicySimpleCondition like "Application =
   LotusNotes" or "User = YoramSnir"?

7. Section 8.18 needs to say a lot more about how
   the object reference part of the reference to a
   property value works.  (Like naming, object
   references are hard to discuss at the level of a
   technology-independent information model.)  Once
   you've gotten to the right object, it's relatively
   easy to find the right value, given that you have
   both the attribute (property) name and the value.
   But QPIM needs to generalize the object reference
   explanation beyond the single example of an RSVP
   Identity.

8. The document says that it defines nesting of
   policy rules, but I can't find any definitions
   that actually do this.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]