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

[Jukka Manner <jukka.manner at tkk.fi>]

Hi Magnus, thank you for the review.

I'll try to answer from my part, haven't talked to the co-authors, yet.

cheers,
Jukka

Magnus Westerlund wrote:
> 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.

Ack.

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

Good question. This item is not on our charter but me, Martin and Hannes
have worked on the topic sometime ago. Do you see we should add the user
authentication and authorization e.g. as an experimental extension to
the current NSLPs? The work is there, we could seek to finish it asap.

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

I believe this is a GIST functionality and parameter, and can be
configured differently depending on the deployment.

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

I'll pass this to Georgios, he is the prime designer here, I believe. :)

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

I'll pass this to Georgios, too. :)

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

I don't actually know why only a SHOULD, this probably ought to be a 
MUST. If there is a binding, it must be indicated.

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

Roland already answered this, we'll fix it.

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

Yes, clearly this statement is missing, will add.

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

Yes. :)

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

This means that either (1) there is the full object ("0") or (2) from 
"offset" upto the end of the object (not from beginning upto offset), 
where the problematic part starts at "offset". I'll clarify this.

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

Yes. :)

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

Ack.

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

Surely not. :)