[NSIS] AD comments on draft-ietf-nsis-ntlp-14
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 26 November 2007 16:09 UTC
Return-path: <nsis-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgWr-0003tD-Q0; Mon, 26 Nov 2007 11:09:49 -0500
Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IwgWq-0003su-OT for nsis-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:09:48 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgWq-0003sm-BG for nsis@ietf.org; Mon, 26 Nov 2007 11:09:48 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgWp-0004N6-F0 for nsis@ietf.org; Mon, 26 Nov 2007 11:09:48 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8DE972054F; Mon, 26 Nov 2007 17:09:46 +0100 (CET)
X-AuditID: c1b4fb3e-ae69ebb00000459d-ce-474aefca278c
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71840203AB; Mon, 26 Nov 2007 17:09:46 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:09:46 +0100
Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:09:46 +0100
Message-ID: <474AEFC9.8090204@ericsson.com>
Date: Mon, 26 Nov 2007 17:09:45 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: draft-ietf-nsis-ntlp@tools.ietf.org, NSIS <nsis@ietf.org>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2007 16:09:46.0024 (UTC) FILETIME=[C32A6A80:01C83046]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc:
Subject: [NSIS] AD comments on draft-ietf-nsis-ntlp-14
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org
Hi, I am sorry for the long time this AD review has taken. I really liked to read the document from first to last word before progressing it. I have now done this and thinks the document is in pretty good shape. I would appreciate an updated version as soon as we have resolved the questions. 1. Page 29: " 2. The signalling application does not wish to set up state with the Querying node and become its peer. This includes the case where a node wishes to avoid taking part in the signalling for overload protection reasons. GIST MUST propagate the Query, similar to the case described in Section 4.3.4. No message is sent back to the Querying node. The application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. Note that if the node which finally processes the Query returns an Error message, this will be sent directly back to the originating node, bypassing any forwarders. For these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload and GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order. An implementation MAY choose to achieve this by retaining the original message, rather than reconstructing it from some parsed internal representation." I can't quite understand "For these diagnostics to be meaningful, any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload and GIST hop count; in particular, it MUST NOT modify any other GIST payloads or their order." Why does a forwarding node may modify the NSLP payload? Can you please explain this? GIST hop is clearly 2. Section 5.3.2.2: " The upper layer protocol MUST be UDP without intervening encapsulation layers. Following the hop-by-hop option header, the IP header MUST NOT include any extension headers other than routing options or destination options, and for the last extension header MUST have a next-header field of UDP." Here I must actually ask if this specification really can require that other IP extensions not are used. This seem to have potential clashes with other basic building blocks. So I would like to understand why the WG thinks it is necessary to make these restrictions. 3. Section 5.3.3, page 59: "A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction, such as 5%, of the node's lowest-speed interface." I think it should be made clear that the token bucket parameter for bit-rate is "no larger than 5%" rather than suggesting that 5% is a general good value. 4. Section 5.7.3.1: "For example, *.example.com in the APD would match certificates for a.example.com, foo.example.com, *.example.com, etc., but would not match example.com. Similarly, a certificate for *.example.com would be valid for APD identities of a.example.com, foo.example.com, *.example.com, etc., but not example.com." Is it intentional to have two sentences saying the same thing, or am I dense here. It looks very much like a repeat. 5. Section 9: NSLP ID I actually wonder about the selection of IESG approval for new NSLP IDs. Isn't that kind of restricting? Sure, it can potentially be easier to register than specification required. However, it does put load on the IESG. It also assumes that the IESG will have enough clue in the future to know what the correct way to handle a registration requests. Can someone provide me with the WGs reasoning behind this policy? 6. Appendix A. I think the text about "reserved" and its meaning needs to be moved from section A.2 to the front text for Appendix A. Otherwise it is wrongly scoped and does not cover A.1 or any A.3... 7. Section A.1: There is no explicit mention of what values should be listed in the version field for this spec. Earlier it says this is Version 1 of GIST, but that could be encoded both a 0 and 1 in this field based on previous protocols from IETF. 8. ID-nits warnings: == Unused Reference: '14' is defined on line 5231, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '15') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '18') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2960 (ref. '19') (Obsoleted by RFC 4960) I definitely like to know if the new versions are fine or not. == Outdated reference: A later version (-04) exists of draft-ietf-behave-turn-03 == Outdated reference: A later version (-15) exists of draft-ietf-nsis-nslp-natfw-14 == Outdated reference: A later version (-02) exists of draft-pashalidis-nsis-gist-legacynats-01 == Outdated reference: A later version (-05) exists of draft-pashalidis-nsis-gimps-nattraversal-04 == Outdated reference: A later version (-04) exists of draft-ietf-nsis-ntlp-statemachine-03 == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-tcpsecure-07 Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] AD comments on draft-ietf-nsis-ntlp-14 Magnus Westerlund
- [NSIS] RE: AD comments on draft-ietf-nsis-ntlp-14 Hancock, Robert
- [NSIS] IPv6 options (was: RE: AD comments on draf… Hancock, Robert
- [NSIS] Re: IPv6 options Magnus Westerlund
- [NSIS] Re: AD comments on draft-ietf-nsis-ntlp-14 Magnus Westerlund
- [NSIS] RE: AD comments on draft-ietf-nsis-ntlp-14 Hancock, Robert
- [NSIS] Re: AD comments on draft-ietf-nsis-ntlp-14 Magnus Westerlund