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 document revisits RFC1063 and RFC1191 to adapt it to IPv6 and proposes to conduct experiments with a new Path MTU Hop-by-Hop option for IPv6.

I've looked at this document from the perspective of the transport area and struggled to correctly understand how this could be applied to a protocol that runs above above. The document discusses several possible directions but I could not find clear recommendations on how a transport protocol (or even ICMP for ping) would adopt this approach and experiment with it. This discussion is important if we want to encourage experiments beyond simply sending packets with this option and explore whether they pass through firewalls and middleboxes.

I would suggest to restructure the document. This introduction should start from RFC1063 and motivate why it us useful to revisit this problem now with IPv6.

Then, I would suggest to provide a high level overview according to RFC4101 of features of the proposed protocol with both the min-PMTU and the Run-PMTU and why this second field, which is an addition compared to RFC1063, is important.

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.

The security considerations must consider in details the different transport protocols that are discussed in the text.  A possible security consideration could be "this approach MUST not be used with protocol X for security reasons".