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