Reviewer: Olivier Bonaventure Review result: Not Ready 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. 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
