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

See below

On 11/02/2022 10:03, Olivier Bonaventure via Datatracker wrote:
> 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@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".
>
>
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art

A note on RFCs:

I expect you mean RFC8201 for IPv6, and particularly RFC8899 for path 
MTU discovery, rather than RFC1191?

Gorry