Dirk Kutscher is the document shepherd and Martin Stiemerling the responsible Area Director.
This document specifies an IPv6 destination option that is capable of
carrying ConEx markings in IPv6 datagrams. The information that is
represented by such markings can be used by any element on the path
from a sender to a receiver, e.g., for traffic management or egress
policing. This mechanism is a key element to ConEX operations, and
therefore this document has been selected by the WG as one the
essential specifications for ConEX. The intended status in
EXPERIMENTAL (as for all ConEX specifications).
2. Review and Consensus
There was large consents in the working group to adopt and follow-on with this document as this is a required mechanism to deploy ConEX in IPv6 networks.
This document has seen 8 revision and was serval times presented in
the working group session. There has been no controversial discussion
about the document in the meetings or on the list. The document has
received a detailed review by at least on of the experts in the
To my knowledge no issues with this document exist.
3. Intellectual Property
All authors have confirmed conformance with BCP 78/79 and that there
are no IPR disclosures on the document.
4. Other Points
The new IPv6 destination option for ConEX needs to be allocated by IANA. The document has an IANA considerations section that explains this precisely.
There are few improvements that should be done in the final editing round before publication:
Section 3, paragraph 7
"devices [...] might have to bury into inner IP headers to find ConEx information" -- not whether that "bury" is the right word. "look into"?
Option Type: this should be updated after IANA has allocated the option number.
Section 6, paragraph 1
"However, it MAY copy the CDO to the outer in order to facilitate..." -- do you want to say "outer header"?
Section 8 on preferential dropping
The second paragraph can still be improved wrt readibility. I think, you should say in the beginning of the paragraph that there can be value in treating ConEX packets preferentially. (Starting with Diffserv PHB is confusing IMO).
These authors agreed to address these suggestions before final
publication. Other than that, there are no issues with this document,
and it should be published.