Re: [auth48] AUTH48: RFC-to-be 9268 <draft-ietf-6man-mtu-option-15> for your review

[Bob Hinden <[e-mail]>]

Hi Alanna,

> On Aug 3, 2022, at 5:48 PM, Alanna Paloma <[e-mail]> wrote:
> 
> Hi Bob and Gorry,
> 
> Thank you for your replies.  We have updated the files as follows:
> 
> 1)
>>> The original xml contained this text formatted within <artwork>; however, this is semantically incorrect,
>> 
>> Sorry, I don’t follow.  Why is it “semantically incorrect”.   It correctly describes the content of the header.
> 
> Apologies for not clarifying. The formatting of the text was semantically incorrect because it was originally formatted within <artwork>; however, the text is not <artwork>, so we have updated the files with our suggested formatting. Please review and let us know if further updates are needed.

I still don’t see this as being "semantically incorrect”.    The resulting output is correct and clear.

I don’t like the new version, it is not as clear as we had it in the draft, and as I noted before matches the style used in countless RFCs, including RFC8200 that is an Internet Standard.

I reviewed the new version you sent, in my view it looses a lot in the new formatting.  For comparison:

Original Draft:

   Option Type (see Section 4.2 of [RFC8200]):

     BB     00   Skip over this option and continue processing.

     C       1   Option data can change en route to the packet's final
                 destination.

     TTTTT 10000 Option Type assigned from IANA [IANA-HBH].

     Length:  4  The size of the value field in Option Data
     field supports PMTU values from 0 to 65,534 octets, the
     maximum size represented by the Path MTU option.


     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.

     Rtn-PMTU: n 15-bits.  The returned Path MTU field, carrying the 15
                 most significant bits of the latest received Min-PMTU
                 field for the forward path.  The value zero means that
                 no Reported MTU is being returned.

     R        n  1-bit.  R-Flag.   Set by the source to signal that
                 the destination host should include the received
                 Rtn-PMTU field updated by the reported Min-PMTU value
                 when the destination host is to send a PMTU Option back
                 to the source host.

New Version:

 Option Type (see Section 4.2 of [RFC8200]):

   BB         00.  Skip over this option and continue processing.

   C          1.  Option data can change en route to the packet's final
              destination.

   TTTTT      10000.  Option Type assigned from IANA [IANA-HBH].

   Length:    4.  The size of the value field in the Option Data field
              supports PMTU values from 0 to 65,534 octets, which is the
              maximum size represented by the Path MTU option.

   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.

   Rtn-PMTU:  n. 15-bits.  The returned Path MTU field, carrying the 15
              most significant bits of the latest received Min-PMTU
              field for the forward path.  The value zero means that no
              Reported MTU is being returned.

   R          n. 1-bit.  R-Flag.  Set by the source to signal that the
              destination host should include the received Rtn-PMTU
              field updated by the reported Min-PMTU value when the
              destination host is to send a PMTU Option back to the
              source host.

I think it is important to match the style of RFC8200 (and note the first line even refers to RFC8200).

I also note that the additions of the “.” after the values is not correct.  For example, BBB, TTTTT, these are binary values, not decimal.   The original text did not have “.”, not sure why this was added to all of the values.


> 
> 2) We have updated the IANA Considerations section to include mention of the "Internet Protocol Version 6 (IPv6) Parameters” registry per Amanda’s guidance.
> 
> Current:
>  IANA has registered an IPv6 Hop-by-Hop Option type in the
>  "Destination Options and Hop-by-Hop Options" registry within the
>  "Internet Protocol Version 6 (IPv6) Parameters” registry group [IANA-HBH].)

This is fine.

Bob


> 
> …
> 
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9268.xml
> https://www.rfc-editor.org/authors/rfc9268.txt
> https://www.rfc-editor.org/authors/rfc9268.html
> https://www.rfc-editor.org/authors/rfc9268.pdf
> 
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9268-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9268-rfcdiff.html (comprehensive diff with changes side by side)
> https://www.rfc-editor.org/authors/rfc9268-auth48diff.html (AUTH48 changes)
> 
> The AUTH48 status of the document can be seen here:
>  https://www.rfc-editor.org/auth48/rfc9268
> 
> Thank you.
> RFC Editor/ap
> 
>> On Aug 3, 2022, at 11:43 AM, Amanda Baber via RT <[e-mail]> wrote:
>> 
>> Hi Bob, all,
>> 
>> On Wed Aug 03 15:31:10 2022, [e-mail] wrote:
>>> Sandy,
>>> 
>>> Thanks very much, a few comments below.
>>> 
>>> Bob
>>> 
>>> 
>>>> On Aug 2, 2022, at 4:15 PM, Sandy Ginoza <[e-mail]> wrote:
>>>> 
>>>> Hi Bob, IANA,
>>>> 
>>>> Just jumping in on this one — I’ve added IANA to this thread so they
>>>> can chime in if we’ve misunderstood or in case anything has changed.
>>>> 
>>>>> On Aug 2, 2022, at 2:26 PM, Bob Hinden <[e-mail]> wrote:
>>>>> 
>>>>>>>> 
>>>>>>>> I note that the reference to the IANA HBH option registry was
>>>>>>>> changed from:
>>>>>>>> 
>>>>>>>> [IANA-HBH] "Destination Options and Hop-by-Hop Options",
>>>>>>>> 
>>>>>>>> <https://www.iana.org/assignments/ipv6-parameters/
>>>>>>>>          ipv6-parameters.xhtml#ipv6-parameters-2>
>>>>>>>> .
>>>>>>>> 
>>>>>>>> to:
>>>>>>>> 
>>>>>>>> [IANA-HBH] IANA, "Destination Options and Hop-by-Hop Options",
>>>>>>>> 
>>>>>>>> <https://www.iana.org/assignments/ipv6-parameters/>
>>>>>>>> .
>>>>>>>> 
>>>>>>>> The original reference goes directly the specific Destination
>>>>>>>> Options and Hop-by-Hop Options registry, where the new one goes
>>>>>>>> to the general IPv6 parameter registry.   Why the change?
>>>>>> 
>>>>>> We updated the reference per input from IANA. IANA recommended that
>>>>>> RFCs point to the top-most registry since they are considered
>>>>>> stable; they prefer that the direct URLs to specific registries on
>>>>>> a page not be used.
>>>>> 
>>>>> I wasn’t aware of that.   The result is a little confusing.  The
>>>>> text in the reference says:
>>>>> 
>>>>> "Destination Options and Hop-by-Hop Options”
>>>>> 
>>>>> but it goes to a page titled:
>>>>> 
>>>>> Internet Protocol Version 6 (IPv6) Parameters
>>>> 
>>>> I see what you’re saying.  My hope is that a reader will search for
>>>> the registry title on the main page.  Would it be more clear to add
>>>> some text where the registry is cited?  For example:
>>>> 
>>>> IANA has registered an IPv6 Hop-by-Hop Option type in the
>>>> "Destination Options and Hop-by-Hop Options" registry within the
>>>> "Internet Protocol Version 6 (IPv6) Parameters” registry [IANA-HBH].)
>>> 
>>> Yes, that would help.
>> 
>> I'd recommend changing "registry" to "registry group" in that last line:
>> 
>> IANA has registered an IPv6 Hop-by-Hop Option type in the
>> "Destination Options and Hop-by-Hop Options" registry within the
>> "Internet Protocol Version 6 (IPv6) Parameters” registry group [IANA-HBH].)
>> 
>>>> 
>>>> 
>>>> 
>>>>> Would something like the following be better?
>>>>> 
>>>>> IANA, "Destination Options and Hop-by-Hop Options”, Internet
>>>>> Protocol Version 6 (IPv6) Parameters, <https://www.iana.org/
>>>>> assignments/ipv6-parameters/>.
>>>> 
>>>> The current format is based on IANA’s input.  We suggested a similar
>>>> format in the past, but there was a preference not to include the
>>>> top-level registry/group title as the page may/will be formatted
>>>> differently in the future (e.g., the registry/group title may change
>>>> or no longer appear).
>>>> 
>>>> Previously proposed:
>>>> [NAME]  IANA, "Top-Level Registry Name: Registry Name", <URL to top-
>>>> level registry>.
>>>> 
>>>> 
>>>>> Seems to me that for IANA registries that are stable, like this one,
>>>>> it’s not too burdensome for IANA to have a stable link to each sub-
>>>>> registry.
>>>> 
>>>> I believe this is in the works.
>>> 
>>> That would be helpful.
>> 
>> IANA is in the process of moving from an XML-based to a database-based registry system. Once this change has been implemented, https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2 will still work, but will take you only to the list of IPv6 Parameters registries that includes Destination Options and Hop-by-Hop Options, rather than Destination Options and Hop-by-Hop Options itself. We will provide permanent links to specific registries like Destination Options and Hop-by-Hop Options, but that system isn't yet available.
>> 
>> Best regards,
>> 
>> Amanda Baber
>> IANA Operations Manager
>