[Tsv-art] Tsvart last call review of draft-ietf-6man-mtu-option-12

[Olivier Bonaventure via Datatracker <[e-mail]>]

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
[e-mail] 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".