Subject: RE: Comments on QPIM-01 draft

From: LE.GARREC.Frederic.FTRD/DMI/[email-masked]
Date: Fri, 1 Sep 2000 08:54:05 +0200

Some comments about Bob's points #1, 2 and 6:

1. I agree.

2. Although the subject of the mail is QPIM, forgive me for disgressing a
little : mention of ManagedElement makes me think about the lack of
associations to replace the now deleted ConditionTarget/ConditionSubject
assocs in PCIM. Am I wrong to believe that such associations should now be
defined in PolicyCondition subclasses ? As for now, only available assoc
left to replace them is Dependency (quite huge an assoc for such small use).

6. Doesn't it belong to PEP's capabilities to know packets structures so
that it can find a username inside ? Payloads structure are
application-specific, and info about fields "position" should, in my
opinion, not be modeled.

Regards,
_________________________________
Frederic LE GARREC
France Telecom R&D
FT.BD/FTR&D/DMI/ASE
Tel: +33 4 92 94 52 88

-----Message d'origine-----
De: [email-masked] [mailto:[email-masked]]
Date: jeudi 31 août 2000 19:30
À: [email-masked]
Objet: Comments on QPIM-01 draft

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]

---

From: Ron Cohen <[email-masked]>
Date: Sat, 02 Sep 2000 06:19:14 -0700

Bob,

Thanks for the feedback.
Please see inline.

>        prominent a role in the QPIM.
There are several new associations and aggregations defined in QPIM, 
including policyVariableInSimpleCondition and policyValueInSimpleCOndition, 
etc. These associations/aggregations were not explicitly stated as such. 
This will be fixed in the new draft.

>    contains -- object references are allowed only
We'll try to answer this in a separate mail.

>    operation of a single meter.
   " Traffic meters measure the temporal properties of the stream of
    packets selected by a classifier against a traffic profile.. " RFC2475. 
We have chosen to separate the modeling into a traffic profile, that 
includes the set of parameters (rate and burst) from the fan-in indicator. 
In this way we can reuse the traffic profile across multiple rules, without 
implying fan-in. Only those rules that include the same qosPolicyMeter 
fan-in together and contribute to the actual measured meter. This also 
allows to indicate measure-only actions vs. policing actions.

In theory, as you indicate, there could be separate rules using different 
traffic profile governing the operation of a single meter. This will not be 
a common situation, but what is wrong with it? Consider the following rules:

Rule 1: If (TFTP) measure using the 'File Transfer Meter' and police to 64Kb/s
Rule 2: If (FTP) measure using the 'File Transfer Meter' and police to 128Kb/s

The outcome of these two rule will make sure that File Transfer meter will 
measure all possible file-transfers (FTP or TFTP), and when it reaches 
64Kb/s, only FTP file transfer can be used up to a total of 128Kb/sec.

>    in QPIM, but I can't find any class to do this.

The constraints modeled in QPIM are on the possible values of a given 
variable using the variable's property qpValueConstraints. The example 
given in the draft is of a source-port variables that constrains the 
possible values to a range of integers 0-65535. The variable references an 
integer value holding the above constraint.

>    every instance of qosPolicyVariable?
Table 3 indicates the default value types that a variable uses. This is 
informational. The idea is that both variables and values are extendable, 
therefore one could define a new value or a new variable and indicate using 
the information model which types of values can be bound to which types of 
values. The variable's property qpValueTypes may therefore holds this 
information for each variable.
This property may further constrain a given variable to use only part of 
the possible values defined in Table 3. For example, indicating that a 
source-IP variable used in some expressions may hold only 
qosPolicyIPv4AddressValues and not qosPolicyIPv6AddressValues.

We'll add this clarification to the revised draft.

We should follow all IANA considerations. We'll get guidance from the WG 
chairs on what is needed to be done.

>    LotusNotes" or "User = YoramSnir"?

One example of use of user and application variables are given in the 
draft: An RSVP flow may carry policy Identity policy objects carrying the 
user-id or application policy objects carrying the application id. This 
policy object information includes the LotusNotes and YoramSnir values.
There are other methods in which the user can find out the user or 
application identities. For example, there are network devices that can 
track layer 4 flows and find application parameters - i.e. know that a flow 
is an http flow, regardless of the port used.

>    explanation beyond the single example of an RSVP

In choosing the possible variables and values we have tried to capture the 
most important standards around Intserv and Diffserv. The identity policy 
object carrying application and user ids do provide crucial information, 
therefore we added variables and values to express user and application 
based policies. It seemed plausible that using other techniques (802.1x) 
one can get similar information. QPIM does not mandate the way in which 
this information is gathered, as long as there is a reliable mechanism to 
do that.

>    policy rules, but I can't find any definitions

This will be better explained in the new draft

Thanks
Ron