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

[Amanda Baber via RT <[e-mail]>]

Hi,

> Please update the “Destination Options and Hop-by-Hop Options”
> registry <https://www.iana.org/assignments/ipv6-parameters/ipv6-
> parameters.xhtml#ipv6-parameters-2>
> as follows.
> 
> Old:
> Description
> Path MTU Record Option
> 
> New:
> Description
> Minimum Path MTU Hop-by-Hop Option

This change is complete:

https://www.iana.org/assignments/ipv6-parameters

(Recipient list adjusted slightly to include individual chair/AD addresses, as mail from our ticketing system sometimes bounces when we try to use the -chairs/-ads/-all aliases.)

thanks,

Amanda Baber
IANA Operations Manager

> Diff file is here:
> https://www.rfc-editor.org/authors/rfc9268-diff.html
> 
> Best regards,
> RFC Editor/ap
> 
> > On Aug 18, 2022, at 9:05 AM, Alanna Paloma <[e-mail]> wrote:
> >
> > Hi Erik,
> >
> > Thank you for your reply. We have noted you approval on the AUTH48
> > status page:
> > https://www.rfc-editor.org/auth48/rfc9268
> >
> > We will now ask IANA to update their registry accordingly. After the
> > IANA updates are complete, we will move forward with the publication
> > process.
> >
> > Best regards,
> > RFC Editor/ap
> >
> >> On Aug 17, 2022, at 7:33 PM, Erik Kline <[e-mail]> wrote:
> >>
> >> 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], 6man-
> >>>>>>>>>>> [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
> >>>>
> >>>
> >>
> >