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

[Bob Hinden <[e-mail]>]

See below, marked GF+BH :

> On Apr 5, 2022, at 7:42 AM, Lars Eggert via Datatracker <[e-mail]> wrote:
> 
> 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.

GF+BH: We designed this option to support packet lengths that can be carried in the IPv6 header.   No consideration was given to go beyond that.

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

GF+BH: We will look at these in the next revision of the draft.


> 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".
> 
> 
>