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

[Bob Hinden <[e-mail]>]

Alanna,

Thanks, comments below.

Bob

> On Aug 2, 2022, at 1:43 PM, Alanna Paloma <[e-mail]> wrote:
> 
> Hi Bob and Gorry,
> 
> Thank you for your replies. We have addressed Bob’s questions below and updated  the text to "Datagram Packetization Layer PMTU Discovery (DPLPMTUD)” at the end of Sections 2 and 4.
> 
> Note that we have 12 remaining queries (sent on 7/14/2022). Please review and send us responses to those queries, along with any further updates you may have.

Gorry and I are working on that.

> 
>>> The style of the header diagram in Section 5. "IPv6 Minimum Path MTU Hop-by-Hop Option" was changed.   For example from the draft we submitted:
>>> 
>>>    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].
>>> 
>>> as compared to what is shown in the new RFC editor 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].
>>> 
>>> 
>>> What we did matches the style in RFC8200.  Why was this change made?
> 
> 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.

I think it’s important to match the style of RFC8200.


> so we converted it to be a definitions list. We are unable to apply spacing in a definitions list in the same way that it appeared within <artwork>, but may we format the text as follows?
> 
>    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].

This didn’t survive the email, I didn’t see it in the new files linked below.   Can you send a file to review?

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

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

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.


> 
> 
> 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)
> 
> Please review the document carefully.  Note that we do not make changes once a document is published as an RFC.
> 
> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
> 
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9268
> 
> Thank you,
> RFC Editor/ap
> 
>> On Aug 1, 2022, at 11:29 AM, Gorry Fairhurst <[e-mail]> wrote:
>> 
>> On 01/08/2022 18:55, Bob Hinden wrote:
>>> Hi,
>>> 
>>> I reviewed the diff.   The majority of the changes look fine, but I have a few questions about two of them.
>>> 
>>> -------------
>>> 
>>> The style of the header diagram in Section 5. "IPv6 Minimum Path MTU Hop-by-Hop Option" was changed.   For example from the draft we submitted:
>>> 
>>>    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].
>>> 
>>> as compared to what is shown in the new RFC editor 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].
>>> 
>>> 
>>> What we did matches the style in RFC8200.  Why was this change made?
>>> 
>>> ---------
>>> 
>>> 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?
>>> 
>>> Bob
>>> 
>>> 
>>> 
>>>> On Jul 14, 2022, at 7:58 AM, [e-mail]
>>>> wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2022/07/14
>>>> 
>>>> RFC Author(s):
>>>> --------------
>>>> 
>>>> Instructions for Completing AUTH48
>>>> 
>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>> approved by you and all coauthors, it will be published as an RFC.
>>>> If an author is no longer available, there are several remedies
>>>> available as listed in the FAQ (
>>>> https://www.rfc-editor.org/faq/
>>>> ).
>>>> 
>>>> You and you coauthors are responsible for engaging other parties
>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>> your approval.
>>>> 
>>>> Planning your review
>>>> ---------------------
>>>> 
>>>> Please review the following aspects of your document:
>>>> 
>>>> *  RFC Editor questions
>>>> 
>>>>  Please review and resolve any questions raised by the RFC Editor
>>>>  that have been included in the XML file as comments marked as
>>>>  follows:
>>>> 
>>>>  <!-- [rfced] ... -->
>>>> 
>>>>  These questions will also be sent in a subsequent email.
>>>> 
>>>> *  Changes submitted by coauthors
>>>> 
>>>>  Please ensure that you review any changes submitted by your
>>>>  coauthors.  We assume that if you do not speak up that you
>>>>  agree to changes submitted by your coauthors.
>>>> 
>>>> *  Content
>>>> 
>>>>  Please review the full content of the document, as this cannot
>>>>  change once the RFC is published.  Please pay particular attention to:
>>>>  - IANA considerations updates (if applicable)
>>>>  - contact information
>>>>  - references
>>>> 
>>>> *  Copyright notices and legends
>>>> 
>>>>  Please review the copyright notice and legends as defined in
>>>>  RFC 5378 and the Trust Legal Provisions
>>>>  (TLP –
>>>> https://trustee.ietf.org/license-info/
>>>> ).
>>>> 
>>>> *  Semantic markup
>>>> 
>>>>  Please review the markup in the XML file to ensure that elements of
>>>>  content are correctly tagged.  For example, ensure that <sourcecode>
>>>>  and <artwork> are set correctly.  See details at
>>>> 
>>>> <https://authors.ietf.org/rfcxml-vocabulary>
>>>> .
>>>> 
>>>> *  Formatted output
>>>> 
>>>>  Please review the PDF, HTML, and TXT files to ensure that the
>>>>  formatted output, as generated from the markup in the XML file, is
>>>>  reasonable.  Please note that the TXT will have formatting
>>>>  limitations compared to the PDF and HTML.
>>>> 
>>>> 
>>>> Submitting changes
>>>> ------------------
>>>> 
>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>> the parties CCed on this message need to see your changes. The parties
>>>> include:
>>>> 
>>>>  *  your coauthors
>>>> 
>>>>  *
>>>> [e-mail]
>>>> (the RPC team)
>>>> 
>>>>  *  other document participants, depending on the stream (e.g.,
>>>>     IETF Stream participants are your working group chairs, the
>>>>     responsible ADs, and the document shepherd).
>>>> 
>>>>  *
>>>> [e-mail]
>>>> , which is a new archival mailing list
>>>>     to preserve AUTH48 conversations; it is not an active discussion
>>>>     list:
>>>> 
>>>>    *  More info:
>>>> 
>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>> 
>>>> 
>>>>    *  The archive itself:
>>>> 
>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>> 
>>>> 
>>>>    *  Note: If only absolutely necessary, you may temporarily opt out
>>>>       of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>       If needed, please add a note at the top of the message that you
>>>>       have dropped the address. When the discussion is concluded,
>>>> 
>>>> [e-mail]
>>>> will be re-added to the CC list and
>>>>       its addition will be noted at the top of the message.
>>>> 
>>>> You may submit your changes in one of two ways:
>>>> 
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>> 
>>>> Section # (or indicate Global)
>>>> 
>>>> OLD:
>>>> old text
>>>> 
>>>> NEW:
>>>> new text
>>>> 
>>>> You do not need to reply with both an updated XML file and an explicit
>>>> list of changes, as either form is sufficient.
>>>> 
>>>> We will ask a stream manager to review and approve any changes that seem
>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>>> and technical changes.  Information about stream managers can be found in
>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>> 
>>>> 
>>>> Approving for publication
>>>> --------------------------
>>>> 
>>>> To approve your RFC for publication, please reply to this email stating
>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>> as all the parties CCed on this message need to see your approval.
>>>> 
>>>> 
>>>> Files
>>>> -----
>>>> 
>>>> The files are available here:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268.xml
>>>> 
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268.html
>>>> 
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268.pdf
>>>> 
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268.txt
>>>> 
>>>> 
>>>> Diff file of the text:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268-diff.html
>>>> 
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268-rfcdiff.html
>>>> (side by side)
>>>> 
>>>> Diff of the XML:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268-xmldiff1.html
>>>> 
>>>> 
>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>> only:
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9268.form.xml
>>>> 
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> 
>>>> https://www.rfc-editor.org/auth48/rfc9268
>>>> 
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9268 (draft-ietf-6man-mtu-option-15)
>>>> 
>>>> Title            : IPv6 Minimum Path MTU Hop-by-Hop Option
>>>> Author(s)        : B. Hinden, G. Fairhurst
>>>> WG Chair(s)      : Bob Hinden, Ole Trøan, Jen Linkova
>>>> 
>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>> 
>>>> 
>>>> 
>> (1)
>> I'm also interested in whether Bob's questions result in chnages, but the rest looks OK, except for the following:
>> 
>> 
>> 
>> (2)
>> 
>> "Datagram Packetization Layer PMTU Discovery (DPLPMTUD)" isn't defined the first time it is used, so would this be better defined in the last line of section 4:
>> 
>> 
>> OLD (as modified by Ed):
>> 
>> datagram PLPMTUD [RFC8899]
>> 
>> NEW:
>> 
>> Datagram Packetization Layer PMTU Discovery (DPLPMTUD) [RFC8899]
>> ...
>> 
>> 
>> 
>> If so, you can undo the change you suggested later to add this definition?
>> 
>> Gorry
>> 
>> 
>