[NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

I have finally completed my AD review of the QoS NSLP and QSPEC
documents. QSPEC will be dealt in a separate email. But here are my
questions and comments.

A. Section 3.1.2: Please expand DSCP on its first usage.

B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth.
This is an informational reference. But I do wonder about the security
solution and its need to carry authentication information. No, I don't
want to make this a normative reference. But I do wonder how the WG
plans to present the lack of even one fully specified security solution,
even if this is going for experimental.

C. Section 3.2.12.1: How long does it take to detect that a new down
stream peer exist, or that truncation has happened?

D. Section 4.6, page 35, second paragraph. It is not clear to me how (1)
can be guaranteed to arrive prior to (2), or if both message are sent
width bound to the other one?

E. Section 4.7.1, page 39:
"Note that the egress should use a timer, with a
   preconfigured value, that can be used to synchronise the arrival of
   both messages, i.e., the end-to-end RESERVE message and the local
   RESERVE' message."

I can't understand this "using a timer for synchronization" in this
sentence.

F. Section 5.1.2.1: "If the session of this message is bound to another
session, then the RESERVE message SHOULD include the SESSION_ID of that
other session in a BOUND_SESSION_ID object."

Why a SHOULD here. Please explain when you could or should break the SHOULD.

G. Section 5.1.2.2:
"A QUERY message
   MAY contain a second QSPEC object."
     QUERY = COMMON_HEADER
              [ RII ][ *BOUND_SESSION_ID ]
              [ PACKET_CLASSIFIER ] [ INFO_SPEC ] QSPEC

The BNF seem to not allow for a second QSPEC object.

H. Section 5.1.3:
"The remaining bits marked 'r' are reserved." There are no definition of
the meaning of reserved bits. I assume SHALL be set to 0, SHALL be
ignored on reception?

I. Section 5.1.3.5:
  "The method-specific classifier data is two bytes long and consists of
   a set of flags:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|Y|P|T|F|S|A|B|                      Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+"

This seems to be 4 bytes, and not 2.

J. Section 5.1.3.6
"   Offset: The byte in the object at which the QNE found the error.
   When this field is set to "0", the complete object is included."

I don't get these two sentences to match. First sentence says this is a
pointer to where the error is. Second sentence indicates that the object
has been truncated upto the given offset. Please clarify.

K. Section 5.3.6:
 "
   A SESSION_ID_LIST is carried in RESERVE messages.  It is used in two
   cases, to refresh or two tear down the indicated sessions. "

Second "two" should be a "to"?

L. Section 6. Please update reference to RFC 5226.

M. Section 7. "The protocol mechanisms s in this
   document try to minimize exhaustion attacks against these resources
   when performing authentication and authorization for QoS resources."

Is the lone "s" after mechanisms intended?



-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------