Lars Eggert's No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-6man-mtu-option-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5. , paragraph 9, comment:
>      Min-PMTU: n 16-bits.  The minimum MTU recorded along the path
>                  in octets, reflecting the smallest link MTU that
>                  the packet experienced along the path.
>                  A value less than the IPv6 minimum link
>                  MTU [RFC8200] MUST be ignored.

Would there be any value in using a scheme that can encode MTUs larger than
64K? Could steal some bits by not defining a way to encode values below 1280.

Thanks to Paul Kyzivat for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/cSJ1VnpREVnAknRj_ANN0QFRdA0).

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 3, nit:
-    This results in many transport connections being configured to use
+    This results in many transport-layer connections being configured to use
+                                  ++++++

Section 2. , paragraph 4, nit:
-    size available for a transport to use.  Also, some use-cases increase
+    size available for a transport protocol to use.  Also, some use-cases increase
+                                  +++++++++

Section 6.3. , paragraph 3, nit:
-    This avoids the transport needing to retransmit a lost packet that
+    This avoids the transport protocol needing to retransmit a lost packet that
+                             +++++++++

Section 6.3.1. , paragraph 10, nit:
-    *  A datagram transport can utilise DPLPMTUD [RFC8899].  For example,
-                                     ^
+    *  A datagram transport can utilize DPLPMTUD [RFC8899].  For example,
+                                     ^

Section 6.3.4. , paragraph 4, nit:
-    *  The actual PMTU may be lower than the Rtn-PMTU value because the
-                                                                   ----

Reference [RFC2460] to RFC2460, which was obsoleted by RFC8200 (this may be on
purpose).

Reference [RFC1063] to RFC1063, which was obsoleted by RFC1191 (this may be on
purpose).

Section 4. , paragraph 3, nit:
> IANA-HBH]. Length: 4 The size of the each value field in Option Data field su
>                                  ^^^^^^^^
Two determiners in a row. Choose either "the" or "each".

Section 6.2. , paragraph 2, nit:
> acket with this option in response to a R-flag, as well as which packets to i
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.4. , paragraph 4, nit:
>  mitigate the impact by responding to a R-Flag by including the option in a p
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".