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@ietf.org if you reply to or forward this review.

The authors addressed some of the comments raised in the previous review, but section 6.3 remains very vague on what transport layer protocols could do using this option. I would expect a more precise description of how some transport layer protocols (ICMPv6 could be the first protocol discussed in this section) would use the proposed extension.

The following comments raised for version 12 have not been adequately addressed :

Then the document can discuss in details the format of the proposed option.
Section 6 should be split in two parts: - a section that discusses the behavior
of routers based on the provided text - a section that discusses the behavior
of different transport layer protocols that could adopt the proposed solution.
It is fine if some transport are not discussed and only a subset of the
possible protocols are discussed, but for each discussed protocol, the
presentation should make it clear how the proposed option would be used by the
protocol. I would suggest to start with ping ICMP because this could be a good
approach to experiment with the proposed option and collect information from
experiments. DNS could also be a possibility since DNSSec responses could
benefit from this solution.