Reviewer: Brian Trammell Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document is OK for transport. Thanks for this document; it's a valiant effort at fixing v6 hop-by-hop options to be current-reality compliant. Given the TTL of various devices doing things the old way, I'm skeptical that it will have much immediate effect but I still consider it quite useful to publish as an update to 8200 for its eventual future effects. A couple of questions/nits: in Section 4: "Significant reordering of the packets belonging to a flow can impact the performance of upper layer protocols and needs to be avoided." The first part of this is obviously true. The second part is mostly true for most protocols in most of the Internet, but I'm not sure "needs to be avoided" is universally true for all transports. In the absence of any good way to know how reordering-tolerant a given flow is, I'm not sure I have advice for making this text better, but it makes me feel a little sad nonetheless. in Section 5.2: "If a router is unable to process further Hop-by-Hop options (or is not configured to do so), the router SHOULD skip the remaining options using the "Hdr Ext Len" field in the Hop-by-Hop Options header." -- This is good advice, of course, and the document refers to eh-limits with respect to how long an HbH header should be. Do we have confidence that deployed routers can skip on the fast path? Section 5.2.1, in essence if not in explicit language, deprecates the Router Alert option, but the IANA considerations leave https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml (and its references) untouched. Is this intentional? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call