Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09
Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 27 August 2015 02:56 UTC
Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9951ACDE6; Wed, 26 Aug 2015 19:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESkN89JB9s2A; Wed, 26 Aug 2015 19:56:31 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FDA1A8A8B; Wed, 26 Aug 2015 19:56:31 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-bb-55de127f0fef
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.B7.26730.F721ED55; Wed, 26 Aug 2015 21:24:47 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Wed, 26 Aug 2015 22:56:29 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: Robert Sparks <rjsparks@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-conex-destopt@ietf.org" <draft-ietf-conex-destopt@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "conex@ietf.org" <conex@ietf.org>
Thread-Topic: Gen-art LC review: draft-ietf-conex-destopt-09
Thread-Index: AQHQ4DyWm48WNKikiUGJlz4OFxxbqw==
Date: Thu, 27 Aug 2015 02:56:29 +0000
Message-ID: <E87B771635882B4BA20096B589152EF63A8DF670@eusaamb107.ericsson.se>
References: <55DE1F65.5070106@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPuG690L1Qg2VzpS0OXfvJaNG9+he7 xdVXn1ksnm2cz2JxbU4jmwOrx5IlP5k8Zu18whLAFMVlk5Kak1mWWqRvl8CV0bNCpaBTt6J3 wwa2BsZJKl2MnBwSAiYSS+fcZYGwxSQu3FvP1sXIxSEkcJRR4tner8wQznJGie51HUwgVWxA HRt2fgazRQReMEq8eh8FYgsLWEvMnvuEDSJuIzFx5k9GCFtPYuPft2BxFgFVibtHT4DZvAK+ Es/WvQKzhQS0JJoPLAa7ghHoiu+n1oDNZxYQl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwphK0nM eX2NGaJeR2LB7k9sELa2xLKFr5khdglKnJz5hGUCo8gsJGNnIWmZhaRlFpKWBYwsqxg5SotT y3LTjQw3MQJj4pgEm+MOxgWfLA8xCnAwKvHwLvh3N1SINbGsuDL3EKM0B4uSOK+0X16okEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbCGA8HVg3+DWaPDG7OVj12wdDk16+PW+++bpmTdPR3 Vv7yLQc/M7inVDxm4J13YW/kIUG9R9ucX23ReilbfffItwU+fDITMu98PleTu2RpwXtbgxXO 89znT4mL2y+7Vl3ywtOidR7sborai77W9bG/lH/ieYJBwLWQR/JBoeqDYGGXlqlrZ3kpsRRn JBpqMRcVJwIAapsBi2oCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/IQsv2QFVe1BKCkN87npGGLiIM-I>
Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 02:56:33 -0000
Hi Robert, Thanks a lot for your careful review. Please find responses inline. On 08/26/2015 04:20 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-conex-destopt-09 > Reviewer: Robert Sparks > Review Date: 26 Aug 2015 > IETF LC End Date: 31 Aug 2015 > IESG Telechat date: 1 Oct 2015 > > Summary: On the right track with open issues > > Major issues: > > M1) This document claims to specify "the ConEx wire protocol in IPv6". > But it reads more like "this document just defines an option, other > documents will talk about how and when the option is used". The > abstract-mech document requires that concrete ConEx specifications > discuss the audit function explicitly, with several requirements for > detail scattered through that document. In particular, it asks for a > discussion of how the concrete protocol defends against a set of > likely attacks against the audit function. This document is silent, > and I think a side-effect of being processed in parallel with > tcp-modifications, and suspect most of the thinking on meeting the > requirements for discussing the audit function has concentrated there. > However, nothing in _this_ document restricts its use to other > transport extensions that have talked about these things. Should > there be a statement that this option must not be used unless by a > transport extension that's discussed how to use it? If not, then > shouldn't this document talk about what happens if there's no > transport header below to inform audit function behavior? I will let Mirja take this one as she had some extensive discussions about the audit functionalities in the wg phase. > > > Minor issues: > > m1) Figure 1 isn't right. I think what you want is: > > 0 1 2 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Length |X|L|E|C| res | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Will fix it. Not only that, I just noticed that the whole draft seems to be off in the formatting department including left justified titles and a left justified third author. My locally rendered copy looks more normal with the figure rendered like in version -08. > > m2) There is confusion in two places in the document where you discuss > where to put the CDO (at the end of page 5 and the end of page 7). The > current text says the option MUST be the first option in whatever > destination options block it appears in. That seems problematic. What > if some other option also declares it MUST be the first option? I > wonder if instead of trying to say "must be the first option in the > block" you are trying only to say "If you use a CDO, use it in the > destination options block that comes before an AH block, not the one > that might come after". Will fix. > > m3) Third paragraph of section 6: Should the last sentence end with > "in a given stream." ? It should be more like "for a given set of tunnel endpoints". > > Nits/editorial comments: > > Introduction: Should "Due to space limitation" be "Due to space > limitations in the IPV4 header"? Yes. Will clarify. > > Section 4: Right after the definition of Reserved, there is a line > that says "foo". What should it say instead? Nothing. Looks like this was a typo introduced in -09. > > The last sentence on page 6: I don't think it's the network node that > you are saying must be aware. Perhaps you mean designers of network > nodes? It should be the auditor instead. Will fix. > > At the top of page 7, you have "They MAY log". You shouldn't use a > 2119 MAY here - it's not part of the protocol.Similarly, in section > 6, "MAY compare the two, and MAY log" should not use 2119. In case other bits are added in the future, these log entries can signal the admins to take a closer look. In the second case we are using it to say the decapsulators are not required to do this but they can if they want to. Can you clarify a bit why you think this is not appropriate usage of RFC2119 language? > > First paragraph of section 6: "natively" is not clear. Perhaps > replacing "will not natively copy" with "will not normally copy"? Sounds good. > > Second paragraph of section 6: I suggest replacing "ignore any > CDO" with "ignore any CDO in the outer header". Sounds good. > > Consider moving the description of the bits in the option type field, > particularly the chg bit, earlier in the document. Right now, the > first mention is in the security consideration section, and most > of the definition doesn't happen until the IANA considerations. > It would help if it were clear what that bit was going to be before > you ever mention AH. Will do. Thanks Suresh
- [conex] Gen-art LC review: draft-ietf-conex-desto… Robert Sparks
- Re: [conex] Gen-art LC review: draft-ietf-conex-d… Suresh Krishnan
- Re: [conex] Gen-art LC review: draft-ietf-conex-d… Mirja Kühlewind
- Re: [conex] Gen-art LC review: draft-ietf-conex-d… Robert Sparks
- Re: [conex] Gen-art LC review: draft-ietf-conex-d… Bob Briscoe
- Re: [conex] Gen-art LC review: draft-ietf-conex-d… Robert Sparks