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

[Erik Kline <[e-mail]>]

All,

I have reviewed rfc9268-auth48diff.html and all the changes look good to
me, including the presence of the Implementation section.  (I appreciate
the "At the time this document..." to aid the
quick-but-not-necessarily-careful reader. :-)

LGTM

Thank you all!

On Tue, Aug 16, 2022 at 9:35 AM Bob Hinden <[e-mail]> wrote:

> Erik,
>
> I wanted to add that it is the authors recommendation to keep the
> implementation section.  The pointer to the VPP source might be useful to
> another implementor.
>
> Bob
>
> > On Aug 16, 2022, at 9:30 AM, Alanna Paloma <[e-mail]> wrote:
> >
> > Hi Erik,
> >
> > This is a friendly reminder that we await your review and confirmation
> that the Implementation Status section should remain in this document.
> >
> > The latest files are 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
> >
> > 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-lastdiff.html (last version
> to this one)
> > https://www.rfc-editor.org/authors/rfc9268-lastrfcdiff.html (last
> version to this one with changes side by side)
> > https://www.rfc-editor.org/authors/rfc9268-auth48diff.html (AUTH48
> changes)
> >
> > The AUTH48 status page is here:
> > https://www.rfc-editor.org/auth48/rfc9268
> >
> > Thank you,
> > RFC Editor/ap
> >
> >> On Aug 9, 2022, at 8:16 AM, Alanna Paloma <[e-mail]> wrote:
> >>
> >> Hi Gorry,
> >>
> >> We have noted your approval on the AUTH48 status page:
> >> https://www.rfc-editor.org/auth48/rfc9268
> >>
> >> Best regards,
> >> RFC Editor/ap
> >>
> >>
> >>> On Aug 9, 2022, at 12:32 AM, Gorry Fairhurst <[e-mail]>
> wrote:
> >>>
> >>> On 08/08/2022 20:29, Alanna Paloma wrote:
> >>>> Hi Bob and Gorry,
> >>>>
> >>>> Thank you for your replies. We have noted Bob’s approval on the
> AUTH48 status page and updated the files per Gorry’s request.
> >>>>
> >>>> Once we have received approvals from Erik and Gorry, we will ask IANA
> to update their registry accordingly. After the IANA updates are complete,
> we will move forward with the publication process.
> >>>>
> >>>> The latest files are 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
> >>>>
> >>>> 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-lastdiff.html (last
> version to this one)
> >>>> https://www.rfc-editor.org/authors/rfc9268-lastrfcdiff.html (last
> version to this one with changes side by side)
> >>>> https://www.rfc-editor.org/authors/rfc9268-auth48diff.html (AUTH48
> changes)
> >>>>
> >>>> The AUTH48 status page is here:
> >>>> https://www.rfc-editor.org/auth48/rfc9268
> >>>>
> >>>> Thank you,
> >>>> RFC Editor/ap
> >>>
> >>> Thanks for making these changes. I'll add my approval also for
> publication.
> >>>
> >>> Gorry
> >>>
> >>>
> >>>>> On Aug 8, 2022, at 4:31 AM, Gorry Fairhurst <[e-mail]>
> wrote:
> >>>>>
> >>>>> On 05/08/2022 23:53, Bob Hinden wrote:
> >>>>>> Alanna,
> >>>>>>
> >>>>>> Thanks very much, the new version looks fine to me.  I approve.
> >>>>>>
> >>>>>> Bob
> >>>>>>
> >>>>>>
> >>>>> Thanks for all your work, this is nearlky ready. I have done a
> detailed review of the final formatted version and have a few minor
> additional requests:
> >>>>>
> >>>>> (a) Format: Section 2 para 2 appears to be a continuation of the
> first para.
> >>>>>
> >>>>> Please concatenate para 1 with para 2:
> >>>>>
> >>>>> OLD:
> >>>>>
> >>>>> or do not have a return
> >>>>>  path to the source host.
> >>>>>
> >>>>>  This results in many transport-layer connections being
> >>>>>
> >>>>> NEW:
> >>>>>
> >>>>> or do not have a return path to the source host.This results in many
> transport-layer connections being
> >>>>> ====
> >>>>>
> >>>>> (b) Figure 2 explanatory text, appears to have lost the indent for
> the explanation of Length. Please ident lines to be consistent with other
> definitions in this block.
> >>>>>
> >>>>> OLD:
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> NEW:
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> ----
> >>>>> (c) Section 6.3.1.
> >>>>> We previously requested you to move the definition
> >>>>> of DPLPMTUD earlier in the document, which I can see you did.
> >>>>> This means there is now no need for a re-definition here:
> >>>>>
> >>>>> OLD:
> >>>>> A datagram transport can utilize Datagram Packetization Layer PMTU
> >>>>>     Discovery (DPLPMTUD) [RFC8899].
> >>>>> NEW:
> >>>>> A datagram transport can utilize DPLPMTUD [RFC8899].
> >>>>>
> >>>>> ---
> >>>>> (d) In Figure 3:
> >>>>> Please remove last dash and replace by an arrow,
> >>>>> in line prior to "..." to
> >>>>> be consistent with other packets sent from left top right:
> >>>>>
> >>>>> OLD:
> >>>>>    ----Packets of data size d -------------------------------
> >>>>> NEW:
> >>>>>    ----Packets of data size d ------------------------------>
> >>>>>
> >>>>>
> >>>>> ---
> >>>>> (e) It would be helpful to add a comma before "d" in this case:
> >>>>>
> >>>>> OLD:
> >>>>> confirmed probe size d.
> >>>>> NEW:
> >>>>> confirmed probe size, d.
> >>>>>
> >>>>>
> >>>>> Best wishes,
> >>>>>
> >>>>> Gorry
> >>>>>
> >>>>>
> >>>>>>> On Aug 5, 2022, at 3:11 PM, Alanna Paloma <[e-mail]>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi *Erik, Bob, and Gorry,
> >>>>>>>
> >>>>>>> Thank you for your replies. We have updated the files as requested.
> >>>>>>>
> >>>>>>> Note that we have reverted the text to <artwork> as requested.
> FYI, we used <dl> because it seemed appropriate use of the XML. If RFC 8200
> were being published today, we would have used <dl> for that list.
> >>>>>>>
> >>>>>>> *Erik - As the AD, please review and confirm that the
> Implementation Status section should remain in this document.
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/authors/rfc9268-auth48diff.html
> >>>>>>>
> >>>>>>>
> >>>>>>> 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-lastdiff.html
> >>>>>>> (last version to this one)
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/authors/rfc9268-lastrfcdiff.html
> >>>>>>> (last version to this one with changes side by side)
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/authors/rfc9268-auth48diff.html
> >>>>>>> (AUTH48 changes)
> >>>>>>>
> >>>>>>> Please review the document carefully as documents do not change
> once published as RFCs.
> >>>>>>>
> >>>>>>> We will await any further changes you may have and approvals from
> each author and *Erik prior to moving forward in the publication process.
> >>>>>>>
> >>>>>>> Please see the AUTH48 status page for this document here:
> >>>>>>>
> >>>>>>> https://www.rfc-editor.org/auth48/rfc9268
> >>>>>>>
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> RFC Editor/ap
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Aug 4, 2022, at 2:02 AM, Gorry Fairhurst <[e-mail]
> >
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks for this review. Please see below the detailed feedback
> following your review,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -------- Forwarded Message --------
> >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9268
> <draft-ietf-6man-mtu-option-15> for your review
> >>>>>>>>> Date: Thu, 14 Jul 2022 08:03:11 -0700 (PDT)
> >>>>>>>>> From:
> >>>>>>>>> [e-mail]
> >>>>>>>>>
> >>>>>>>>> To:
> >>>>>>>>> [e-mail], [e-mail]
> >>>>>>>>>
> >>>>>>>>> CC:
> >>>>>>>>> [e-mail], [e-mail],
> [e-mail], [e-mail], [e-mail],
> [e-mail]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Authors,
> >>>>>>>>>
> >>>>>>>>> While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> >>>>>>>>>
> >>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that
> appear in the title) for use on
> >>>>>>>>> https://www.rfc-editor.org/search
> >>>>>>>>> . -->
> >>>>>>>>>
> >>>>>>>> Auth: These are our suggestions:
> >>>>>>>> DPLPMTUD
> >>>>>>>> PMTUD
> >>>>>>>>
> >>>>>>>>> 2) <!--[rfced] Figure titles: Would you like to provide captions
> for the figures in this document?
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>> Auth: Yes, please do add captions, as below:
> >>>>>>>>
> >>>>>>>> NEW:
> >>>>>>>> Figure 1: An example path between the source host and the
> destination host.
> >>>>>>>>
> >>>>>>>> Figure 2: Three scenarios that arise from using the path shown in
> Figure 1.
> >>>>>>>>
> >>>>>>>> Figure 3: Format of the Minimum Path MTU Hop-by-Hop Option.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 3) <!--[rfced] We see a number of author-inserted comments in
> the .xml file
> >>>>>>>>> for this document. We are unsure if these have been resolved.
> Please
> >>>>>>>>> review and let us know if these can be deleted or if they need
> to be
> >>>>>>>>> addressed.
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> Please remove prior to publication.
> >>>>>>>>>
> >>>>>>>> Auth: OK
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 4) <!-- [rfced] Section 5: Please review the formatting of the
> descriptions of the Minimum Path MTU Hop-by-Hop Option, and let us know if
> any changes are needed.
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> 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.
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> Auth: Bob raised an issuem about this proposal.
> >>>>>>>>> 5) <!--[rfced] Section 6.3: We note that the following text
> states that probe packets are used for "two distinct functions"; however,
> it is then followed by a list of four items. May we update this list to
> maintain the first two items and move the last two items into separate
> paragraphs?
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> PLPMTUD [RFC9000] uses probe packets for two distinct functions:
> >>>>>>>>>
> >>>>>>>>> * Probe packets are used to confirm connectivity...
> >>>>>>>>>
> >>>>>>>>> * A second use of probe packets is to explore if a path supports
> a
> >>>>>>>>> packet size greater than the current PLPMTU...
> >>>>>>>>>
> >>>>>>>>> * The PMTU Hop-by-Hop Option Probe can be sent on packets that
> >>>>>>>>> include application data...
> >>>>>>>>>
> >>>>>>>>> * Using a PMTU Probe on packets that do not carry application
> data
> >>>>>>>>> will avoid the need for loss recovery...
> >>>>>>>>>
> >>>>>>>>> Perhaps:
> >>>>>>>>> PLPMTUD [RFC9000] uses probe packets for two distinct functions:
> >>>>>>>>>
> >>>>>>>>> * Probe packets are used to confirm connectivity...
> >>>>>>>>>
> >>>>>>>>> * A second use of probe packets is to explore if a path supports
> a
> >>>>>>>>> packet size greater than the current PLPMTU...
> >>>>>>>>>
> >>>>>>>>> The PMTU Hop-by-Hop Option probe can be sent on packets that
> >>>>>>>>> include application data...
> >>>>>>>>>
> >>>>>>>>> Using a PMTU probe on packets that do not carry application data
> >>>>>>>>> will avoid the need for loss recovery...
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>> Auth:
> >>>>>>>> This REF seems slightly wonky.
> >>>>>>>> The RFC to be cited is RFC 8899.
> >>>>>>>> The change itself looks OK.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 6) <!-- [rfced] Section 6.3.5: We have updated "R-bit" to
> "R-Flag" in the following. Please let us know if any changes are necessary.
> >>>>>>>>>
> >>>>>>>>> Original:
> >>>>>>>>> To bound the delay in discovering an increase in
> >>>>>>>>> the actual PMTU, a host with a link MTU larger than the current
> PMTU
> >>>>>>>>> SHOULD periodically send the MinPMTU HBH Option with the R-bit
> set.
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> To bound the delay in discovering an increase in
> >>>>>>>>> the actual PMTU, a host with a link MTU larger than the current
> PMTU
> >>>>>>>>> SHOULD periodically send the MinPMTU HBH Option with the R-Flag
> set.
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>> Auth: Yes, we agree.
> >>>>>>>>
> >>>>>>>>> 7) <!-- [rfced] Section 7: IANA has recorded the following
> description in the "Destination Options and Hop-by-Hop Options" registry <
> https://www.iana.org/assignments/ipv6-parameters/>
> >>>>>>>>> :
> >>>>>>>>>
> >>>>>>>>> IANA registry: Path MTU Record Option
> >>>>>>>>>
> >>>>>>>>> Should the description in the registry instead say "Minimum Path
> MTU Hop-by-Hop Option"?
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Auth: Yes, we agree.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 8) <!-- [rfced] Section 8.6: We are having difficulty parsing
> the following sentence. Does the forged packet cause a packet with a
> MinPMTU HBH option to be sent?
> >>>>>>>>>
> >>>>>>>>> Current:
> >>>>>>>>> When a forged packet causes a packet to be sent including the
> MinPMTU
> >>>>>>>>> HBH option and the return path does not forward packets with this
> >>>>>>>>> option, the packet will be dropped (see Section 6.3.6).
> >>>>>>>>> Perhaps:
> >>>>>>>>> When a forged packet causes a packet that includes the MinPMTU
> HBH option to be sent and the return path does not forward packets with
> this option, the packet will be dropped (see Section 6.3.6).
> >>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>> Auth: Yes. This change looks good
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 9) <!--[rfced] Per RFC 7942 ("Improving Awareness of Running
> Code: The
> >>>>>>>>> Implementation Status Section"), may we remove the Implementation
> >>>>>>>>> Status section? -->
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Auth: This section seems correct, we are not sure why it should
> be removed. We think we should keep it, or keep it wiyh a preface that
> says  "At the time of publication..."
> >>>>>>>>
> >>>>>>>>> 10) <!--[rfced] Informative References: The titles of the
> following references don't match the information found at the provided
> URLs. Please review and let us know if/how these references should be
> updated. Note that if the Implementation Status section is removed, this
> question becomes moot.
> >>>>>>>>> Original:
> >>>>>>>>>
> >>>>>>>>> [VPP_SRC] "VPP Source",
> >>>>>>>>> <https://gerrit.fd.io/r/c/vpp/+/21948>
> >>>>>>>>> .
> >>>>>>>>>
> >>>>>>>> Auth: The link goes to a page titled "ip: HBH MTU recording for
> IPv6.” That seems correct.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> [WIRESHARK]
> >>>>>>>>> "Wireshark Network Protocol Analyzer",
> >>>>>>>>>
> >>>>>>>>> <https://www.wireshark.org>
> >>>>>>>>> .
> >>>>>>>>>
> >>>>>>>> Auth: This seems correct.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Perhaps:
> >>>>>>>>>
> >>>>>>>>> [VPP_SRC] "vpp", commit 21948, ip: HBH MTU recording for IPv6,
> >>>>>>>>>
> >>>>>>>>> <https://gerrit.fd.io/r/q/project:vpp>
> >>>>>>>>> .
> >>>>>>>>>
> >>>>>>>> Auth: That seems OK.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 11) <!--[rfced] Terminology
> >>>>>>>>>
> >>>>>>>>> a) Throughout the text, the following terminology appears to be
> >>>>>>>>> used inconsistently. Please review these occurrences and let us
> know
> >>>>>>>>> if/how they may be made consistent.
> >>>>>>>>>
> >>>>>>>>> Minimum Path MTU (8 instances) vs. minimum Path MTU (2 instances)
> >>>>>>>>> Option (62 instances) vs. option (106 instances)
> >>>>>>>>> Option Data (9 instances) vs. option data (2 instances)
> >>>>>>>>> Reported MTU (1 instance) vs. reported MTU (1 instances)
> >>>>>>>>>
> >>>>>>>>> b) For consistency, should parentheses be used in instances that
> label sizes?
> >>>>>>>>>
> >>>>>>>>> For example: size (d') vs. size d' -->
> >>>>>>>>>
> >>>>>>>>> Auth: ??? Bob
> >>>>>>>>>
> >>>>>>>> Auth: We have a small preference for the Caps version. For
> example "Minimum Path MTU”.
> >>>>>>>>
> >>>>>>>> Auth: We think “ size d’ “ is better without brackets.
> >>>>>>>>
> >>>>>>>> When making this change please keep alignment with the end of
> each line in the diagram.
> >>>>>>>>
> >>>>>>>> 12) <!--[rfced] Please review the "Inclusive Language" portion of
> the online Style Guide
> >>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >>>>>>>> and let us know if any changes are needed. For example, please
> consider whether "black-holing" should be updated to "an infinite loop".
> >>>>>>>> Auth:
> >>>>>>>> “black-holing” is a term commonly used in code and papers to
> refre to a "black hole" effect, as in astronomy. It is not the same as “an
> infinite loop”, and does not imply anything predjudicial about the word
> "black" only that no light is emitted from a black hole. The term is used
> extensivly in software and discussion and is defined in RFC8899.
> >>>>>>>> OLD:
> >>>>>>>> Increasing the PMTU can result in black-holing (see Section 1.1
> of [RFC8899])...
> >>>>>>>> NEW:
> >>>>>>>> Increasing the PMTU can result in a path silently dropping
> packets (described as a black hole in [RFC8899])...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>> RFC Editor/ap/jm
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 7/14/22 9: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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The following files are provided to facilitate creation of your
> own diff files of the XML.
> >>>>>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>>>>>
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9268.original.v2v3.xml
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Please let us know how you plan to proceed.
> >>>>>>>>
> >>>>>>>> Best wishes,
> >>>>>>>>
> >>>>>>>> Gorry & Bob
> >>
> >
>
>