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

[Alanna Paloma <[e-mail]>]

Thank you!

RFC Editor/ap

> On Aug 18, 2022, at 12:58 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> 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
>>>>>> 
>>>>> 
>>>> 
>>> 
>