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

Hi Magnus, Hi Jukka

Magnus, thank you very much for the comments!

I am working out comments D and E!

Best regards,
Georgios
 

> -----Original Message-----
> From: Jukka Manner [mailto:[email protected]] 
> Sent: woensdag 7 oktober 2009 22:52
> To: Magnus Westerlund
> Cc: NSIS; [email protected]
> Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
> 
> 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. :)
>