Subject: [NSIS] QoS NSLP comments

From: Christian Dickmann <[email-masked]>
Date: Wed, 16 Aug 2006 15:28:36 +0200

Hi,

I did a brief review of the QoS NSLP and came up with some issues.
None of them is really severe.

Issue 1) Section 3.3 "GIST Interactions":
"When GIST passes the QoS NSLP data to the NSLP for processing, it
   must also indicate the value of the 'D' (Direction) flag for that
   message. This is done in the Direction attribute of the SendMessage
   and RecvMessage primitives."
Most likely this is outdated. There is no Direction attribute in the
primitives, but the direction is indicated through the D-Flag in the
MRI.

Issue 2) Section 5.1 "QoS NSLP Message and Object Formats":
"An implementation should create messages with the objects
   in the order shown here, but accept the objects in any order."
Maybe this should be changed to something like:
"An implementation SHOULD create message with the objects
 in the order shown here, but MUST accept the objects in any order"
At least, it should be really clear, what an implementation
is allowed to do and which aspects are mandatory.

Issue 3) Section 5.1.1 "Common header":
Why is this header a COMMON header, if there is a field in there, which
is message specific? And in addition, why are the generic fields
not really generic, but get their meaning based on the actual message
type?
This does not seem to be very reasonable to me. First, the common header
is not common and then the generic flags are not generic. 

Generic fields should have a generic meaning, which is defined once for
all message types. Of course, some messages might have certain flags set
to 0 or 1 every time, but again, this should not change the meaning of the
flag.
I suggest to change all flags to real generic ones, like it is done in
GIST for example. Then the generic flags are generic and the header is 
common.

Issue 4) Section 5.1.2:
Various time you state "There are no requirement on
   transmission order, although the above order is recommended."
However, you already said so in the beginning of section 5.1 
(see Issue 2). So to my mind, you do not have to repeat it for 
every message. 

Issue 5) Section 5.1.2.1: "RESERVE"
"[ [ PACKET_CLASSIFIER ] [ QSPEC ] [ QSPEC ] ]". The outer brackets
are unnecessary and should be removed. In addition see Issue 6.

Issue 6) Section 5.1.2:
In the RESPONSE message, you use the notation "[ QSPEC  [ QSPEC ] ]",
while you use "[ QSPEC ] [ QSPEC ]" in NOTIFY and RESERVE.
I suggest to one use one version, namely the first one.

Issue 7) Section 5.1.3.6: "INFO_SPEC":
You should move the error codes their own section, that can be found
in the table of contents. This would help to quickly lookup some
error. 

Issue 8) Section 5.2.1: "State manipulation":
"The state information for a given key includes:
   Flow ID"
Maybe calling it MRI (maybe in brackets) helps to map the different names,
especially if you talk about GIST identifiers here in the section.
(I know, that you define it in the terminology, but it might help here)

Issue 9) Section 5.2.4: "Retransmissions":
"In the latter case, a failure SHOULD be indicated to
   the signaling application."
I am not sure, if it is 100% clear here, which entity the "signaling application"
is. For example in section 3.2.10.1 you write
"GIST will also notify the signaling application that no downstream
   GIST nodes supporting the QoS NSLP are present."
Here, the signaling application seems to be the QoS NSLP itself, since
GIST will only communicate with the NSLPs.

Issue 10) Section 6 "IANA Considerations":
One the one hand you say, that you contribute your object types to the common
NSLP object type registrym, but you also claim to create a NEW registry 
called "QoS NSLP Object Types". The same for the NSLP ID. From my understanding
(I am absolutely no IANA expert) GIST opens the registry and the NSLP only 
contributes a a new entry instead of opeing of a new registry.

Issue 11) Section 5.1.3 "Object Formats":
I am not sure, if the semantics of AB=11 are really wise. One the one hand, I 
am not exactly sure, why you would want such a behavior. On the other hand, I
am absolutely not sure, if there aren't any security implications. By placing
the AB=11 flag, you can trick any node to send an opaque object with every
message it sends for that session. 

Issue 12) Small editorial stuff in Intoduction: 
"Section then clarifies the protocol by means of a number of 
examples in Section 4." is broken.
"The subsequent sections describe AINA allocation issues, and 
security considerations." You mean IANA?

Issue 13)
Section 3.3: Again, editorial: "Currently, the QoS NSLP
specification considers mainly the coupled MRM."
There is an "path-" missing.

Regards,
Christian Dickmann

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

---

From: Andrew McDonald <[email-masked]>
Date: Mon, 28 Aug 2006 16:07:07 +0100

Hi Christian,

> primitives, but the direction is indicated through the D-Flag in the

Agreed. Added as issue 102.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue102

> is allowed to do and which aspects are mandatory.

I agree, we should use RFC2119 language here. Added issue 103.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue103

> GIST for example. Then the generic flags are generic and the header is 

I agree. I think this is captured in issue 97 which I opened in response 
to a similar comment from Hannes.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue97

> are unnecessary and should be removed. In addition see Issue 6.

Based on the text in that section, I think this should actually be:
[ [ PACKET_CLASSIFIER ] QSPEC [ QSPEC ] ]

i.e. you can have a QSPEC without a PACKET_CLASSIFIER, but not vice versa

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

> I suggest to one use one version, namely the first one.

By 'first one', I assume you mean "[ QSPEC  [ QSPEC ] ]".

I think that one shows the intent better (though in pure BNF terms they 
actually mean the same things since all 'QSPEC's are the same).

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

> in the table of contents. This would help to quickly lookup some

I've no particular view on this. I suspect, as a fifth level heading, it 
won't appear in the ToC anyway.

I've added it as issue 106, so that Jukka (as Editor) can make a decision.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue106

> (I know, that you define it in the terminology, but it might help here)

I'd suggest changing the first sentence of the description to say "Based 
on GIST MRI."

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

> GIST will only communicate with the NSLPs.

I'm not sure what this is meant to say. Jukka may be able to comment.

> contributes a a new entry instead of opeing of a new registry.

Yes, some fixing needs to happen here.

I think that the current proposal is that the first NSLP opens the 
registry, rather than GIST, but the idea is basically the same.

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

> message it sends for that session. 

The idea for this original came up when we were looking at the 
extensibility considerations for the NTLP (i.e. what became GIST). 
However, it was then removed from there since it didn't make sense in 
the context of GIST's per-hop applicability.

I think that some form of 'policy data' (authorization tokens, etc) has 
been suggested as one extension that might make use of this.

I don't think the security issue is as bad as it might first sound, 
since it is only those nodes that are accepting the reservation (and 
hence agreeing to do somewhat more than forward/repeat a lump of opaque 
data) that have to worry about this.

I'd be interested to see any other comments on this.

> security considerations." You mean IANA?

Added as issue 108.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue108

> There is an "path-" missing.

Added as issue 109.
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue109

thanks,

Andrew