[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [NSIS] 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:jukka.manner at tkk.fi]
> Sent: woensdag 7 oktober 2009 22:52
> To: Magnus Westerlund
> Cc: NSIS; draft-ietf-nsis-qos-nslp at tools.ietf.org
> 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. :)
>