Subject: Re: [NSIS] QoS NSLP Review

From: Andrew McDonald <[email-masked]>
Date: Mon, 28 Aug 2006 11:50:08 +0100

Hi Hannes,

Tschofenig, Hannes wrote:
> * 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. 
> "

I agree. Added as Issue 94.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue94

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

I agree - section 3 is supposed to be informative rather than normative 
anyway. Added as Issue 95.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue95

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

The first is about a GIST interaction (i.e. fits in section 3.3), the 
second part isn't. However, there is some connection since they are both 
part of the "how to indicate that no QoS was provided along some part of 
the path" question that, I think, is still open.

I've added issue 96 to track this for now.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue96

> * 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? 

I think this is more of a text structuring issue than a technical change.

I think that the generic flags should be defined once in section 5.1.1. 
It so happens that the 'S' (scoping) flag doesn't affect the behaviour 
of NOTIFY, because of the way the default scope of that message is 
defined. i.e. it doesn't make any difference whether 'S' is set or not, 
so the 'S' flag could be used for NOTIFY (it would be strange, but not 
invalid).

Added issue 97.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue97

> * 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?

What is your proposal here? Is it just to delete the example (",e.g. for 
an aggregation ... from the aggregate.")?

> * 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)         //
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

An MRI identifier was included in the first iteration of this. It was 
removed since it is carried in the GIST MRI anyway. The MRI identifier 
in this object would always be the same as that in the GIST MRI. So, it 
would carry no additional information, and leave us with an additional 
error case to deal with.

> * 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. 

Agreed. Added issue 98.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue98

> * 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. 
> 
>  - With Section 6.2 I was not quite sure what you ask IANA todo. How
> would the registry look like? 

I've added these to the existing issue 45.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue45

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

I don't think these needs a new IANA registry - it just relies on the 
GIST MRM registry. What, I think, is needed is some guidance on what to 
do when defining QoS NSLP support for a new MRM. It would probably be 
sufficient to add some words to 5.1.3.5 saying: "When QoS NSLP support 
for a new MRM is defined, appropriate Method-specific Classifier Data 
needs to be defined."

I've added this as issue 99.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue99

> 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. 

I've added these as issue 100.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue100

> * 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. 

Added these as issue 101.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue101

thanks,

Andrew

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