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? 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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". m3) Third paragraph of section 6: Should the last sentence end with "in a given stream." ? Nits/editorial comments: Introduction: Should "Due to space limitation" be "Due to space limitations in the IPV4 header"? Section 4: Right after the definition of Reserved, there is a line that says "foo". What should it say instead? 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? 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. First paragraph of section 6: "natively" is not clear. Perhaps replacing "will not natively copy" with "will not normally copy"? Second paragraph of section 6: I suggest replacing "ignore any CDO" with "ignore any CDO in the outer header". 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.