Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
"Georgios Karagiannis" <karagian@cs.utwente.nl> Mon, 12 October 2009 10:23 UTC
Return-Path: <karagian@cs.utwente.nl>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8893A68C6 for <nsis@core3.amsl.com>; Mon, 12 Oct 2009 03:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.096
X-Spam-Level: **
X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q16qMLPdjycB for <nsis@core3.amsl.com>; Mon, 12 Oct 2009 03:23:37 -0700 (PDT)
Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 288843A681E for <nsis@ietf.org>; Mon, 12 Oct 2009 03:23:37 -0700 (PDT)
Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id n9CANTqh022047; Mon, 12 Oct 2009 12:23:32 +0200 (MEST)
From: Georgios Karagiannis <karagian@cs.utwente.nl>
To: 'Jukka Manner' <jukka.manner@tkk.fi>, 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
References: <21741_1254405419_ZZ0KQU00DKH9EYBC.00_4AC4B492.6070005@ericsson.com> <4ACCFF63.1000808@tkk.fi>
Date: Mon, 12 Oct 2009 12:23:25 +0200
Message-ID: <004301ca4b26$0bf0eea0$810c5982@dynamic.ewi.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4ACCFF63.1000808@tkk.fi>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcpHk894O9C4AiMLS7OiycLlVLRzlgDkfjBQ
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 12 Oct 2009 12:23:35 +0200 (MEST)
Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, 'NSIS' <nsis@ietf.org>
Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2009 10:23:38 -0000
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@tkk.fi] > Sent: woensdag 7 oktober 2009 22:52 > To: Magnus Westerlund > Cc: NSIS; draft-ietf-nsis-qos-nslp@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. :) >
- [NSIS] AD review comments of draft-ietf-nsis-qos-… Magnus Westerlund
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Georgios Karagiannis
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka MJ Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Magnus Westerlund
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Magnus Westerlund