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

[Bob Hinden <[e-mail]>]

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