Subject: [NSIS] QoS NSLP Review

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 18 Jul 2006 14:44:23 +0200

Hi all, 

I have reviewed the QoS NSLP draft again (as I promised). The document
looks good. I have only a few minor comments:

Technical:

* Section 3.1.3.

Change from:

"
   The protocol does not currently define a way to carry such additional
   information (sometimes called "Policy data"), but this could be
   provided as a later extension. Some work in this direction is
   described in [NSLP-AUTH].
"

to:

"
The QoS NSLP does not contain objects to carry authorization
information. [NSLP-AUTH] provides this functionality for the QoS NSLP
and the NATFW NSLP. 
"

* In Section 3.3.1 (overview section) you use RFC 2119 language. I don't
think it is necessary. 

* Section 3.3.5 describes two different aspects. Put the second
paragraph into a separate subsection, if you think it is needed. 

* Section 5.1.1: Difference between message-specific flags and generic
flags is not obvious since even the generic flags are not applicable to
all messages. Is this still inline with your thinking? 

* Section 5.1.2.1, TEAR(T) flag: The usage of a QSPEC seems to depend on
a few things that are not described. This might make it more difficult
for interoperability. Would a QoSM describe the semantic. The same is
true for the usage of the QSPEC object in a QUERY, a RESPONSE or a
NOTIFY. Is it sufficient to point to the QSPEC or QoSMs with regard to
the behavior?

* Section 5.1.3.5: You might want to include an MRI identifier if you
think that the parameter description is different for other MRIs.

Hence, delete the following figure:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //          Method-specific classifier data (variable)         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* Section 5.3.6:

The following text is wrong:
"
Yet, if the top most QSPEC
   (i.e., te first QSPEC in the message) defines an unknown QOSM not
   understood by the RMF, the QNE MUST send an RESPONSE containing an
   INFO_SPEC and MUST NOT attempt to recover by inspecting the other
   QSPEC at the bottom of the stack.
"

If a QNE does not understand the QOSM then it looks at the mandatory
objects. You could just point to the QSPEC template draft. 

* IANA Consideration Section:

 - How can you define new Error Source Identifiers?

 - For the QoS NSLP ID you don't need IANA to instruct a new registry.
Delete the text in Section 6.4 and ask IANA to allocate a value from the
registry created by GIST.

 - I guess you need to create a registry for the BOUND_SESSION_ID
Binding Codes. 

 - I guess you also have to create a registry for the PACKET_CLASSIFIER
flags. 

 - With Section 6.2 I was not quite sure what you ask IANA todo. How
would the registry look like? 

Editorial:

* Editor: Check the document for missing 'the' in front of "QoS NSLP". I
got the impression that many of them are missing. 

* Make the RFC editors job easier by using capitalized headings. This is
what I mean:

Change from: "3.1. Overall approach" to ""3.1. Overall Approach"

Not a lot of work but the editor will be thankful. 

* Use only QoS NSLP (instead of QoS-NSLP). See, for example, Section
3.1, first paragraph. 

* Section 5.3.4

"
   There are two time parameters relevant to each QoS NSLP state in a
   node: the refresh period R between generation of successive refreshes
   for the state by the neighbor node, and the local state's lifetime L.
   Each RESERVE message may contain a REFRESH_PERIOD object specifying
   the R value that was used to generate this (refresh) message. This R
   value is then used to determine the value for L when the state is
   received and stored. The values for R and L may vary from peer to
   peer. This peer-to-peer refreshing (as opposed to the QNI initiating
   a refresh which travels all the way to the QNR) allows QNEs to choose
   refresh intervals as appropriate for their environment. For example,
   it is conceivable that refreshing intervals in the backbone, where
   reservations are relatively stable, are much larger than in an access
   network.
"

to:

"
There are two time parameters relevant to each QoS NSLP state in a
   node: the refresh period R between generation of successive refreshes
   for the state by the neighbor node, and the local state's lifetime L.
   Each RESERVE message may contain a REFRESH_PERIOD object specifying
   the R value that was used to generate this (refresh) message. This R
   value is then used to determine the value for L when the state is
   received and stored. The values for R and L may vary from peer to
   peer.
"

Reason: The deleted text appeared already in a previous paragraph. 

Ciao
Hannes

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis