Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09

Suresh Krishnan <> Thu, 27 August 2015 02:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF9951ACDE6; Wed, 26 Aug 2015 19:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ESkN89JB9s2A; Wed, 26 Aug 2015 19:56:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25FDA1A8A8B; Wed, 26 Aug 2015 19:56:31 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-bb-55de127f0fef
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DF.B7.26730.F721ED55; Wed, 26 Aug 2015 21:24:47 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Wed, 26 Aug 2015 22:56:29 -0400
From: Suresh Krishnan <>
To: Robert Sparks <>, General Area Review Team <>, "" <>, "" <>, "" <>
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: <>
References: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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: <>
Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> <>.
> 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.