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