All, As IANA has completed its registry updates and we have received all necessary approvals, we consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9868
As this document is part of Cluster C405, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C405 Thank you for your attention and guidance during the AUTH48 process. We will move this document and RFCs-to-be 9869 and 9870 forward in the publication process at this time. Alanna Paloma RFC Production Center > On Oct 1, 2025, at 9:36 AM, Alanna Paloma <[email protected]> > wrote: > > Hi Amanda, > > The updates look good. Thank you! > > Alanna Paloma > RFC Production Center > >> On Sep 30, 2025, at 5:22 PM, Amanda Baber via RT <[email protected]> >> wrote: >> >> Hi, >> >> These updates are complete: >> >> https://www.iana.org/assignments/tcp-parameters >> https://www.iana.org/assignments/udp >> >> We'll list the draft string in the TCP/UDP ExIDs registry note until we can >> link to the published RFC. >> >> thanks, >> Amanda >> >> On Mon Sep 29 18:14:39 2025, [email protected] wrote: >>> IANA, >>> >>> Please update your registries as follows to match the edited document >>> at https://www.rfc-editor.org/authors/rfc9868-diff.html. >>> >>> 1) Please update the note in the “UDP Option Kind Numbers” registry >>> <https://www.iana.org/assignments/udp/udp.xhtml#udp-options> as >>> follows. >>> - close “code points” >>> - update “an” to “on” >>> - capitalize “UDP options" >>> >>> Old: >>> Code points 0-7 MUST be supported an any implementation supporting >>> UDP options. All others are supported at the discretion of each >>> implementation. >>> >>> New: >>> Codepoints 0-7 MUST be supported on any implementation supporting >>> UDP Options. All others are supported at the discretion of each >>> implementation. >>> >>> >>> 2) Please update the “Meaning” column in the "UDP Option Kind Numbers” >>> registry <https://www.iana.org/assignments/udp/udp.xhtml#udp-options> >>> as follows. >>> >>> Old: >>> Kind Length Meaning >>> 1 - No operation (NOP) >>> 2 6 Additional payload checksum (APC) >>> 4 4 Maximum datagram size (MDS) >>> 5 5 Maximum reassembled datagram size (MRDS) >>> 8 10 Timestamps (TIME) >>> 9 (varies) Reserved for Authentication (AUTH) >>> 192 (varies) Reserved for Compression (UCMP) >>> 193 (varies) Reserved for Encryption (UENC) >>> 254 (varies) [RFC3692]-style experiments (UEXP) >>> >>> New: >>> Kind Length Meaning >>> 1 - No Operation (NOP) >>> 2 6 Additional Payload Checksum (APC) >>> 4 4 Maximum Datagram Size (MDS) >>> 5 5 Maximum Reassembled Datagram Size (MRDS) >>> 8 10 Timestamp (TIME) >>> 9 (varies) RESERVED for Authentication (AUTH) >>> 192 (varies) Reserved for UNSAFE Compression (UCMP) >>> 193 (varies) Reserved for UNSAFE Encryption (UENC) >>> 254 (varies) RFC3692-style UNSAFE experiments (UEXP) >>> >>> >>> 3) Please update the note in the "TCP/UDP Experimental Option >>> Experiment Identifiers (TCP/UDP ExIDs)” registry >>> <https://www.iana.org/assignments/tcp-parameters/tcp- >>> parameters.xhtml#tcp-udp-exids> to point to the actual RFC rather >>> than “the corresponding reference”. >>> >>> Old: >>> 16-bit ExIDs can be used with either TCP or UDP; 32-bit ExIDs can be >>> used with TCP or their first 16 bits can be used with UDP. Use with >>> each transport (TCP, UDP) is indicated in the protocol column, as >>> defined in the corresponding reference. >>> >>> New: >>> 16-bit ExIDs can be used with either TCP or UDP; 32-bit ExIDs can be >>> used with TCP or their first 16 bits can be used with UDP. Use with >>> each transport (TCP, UDP) is indicated in the protocol column, as >>> defined in RFC 9868. >>> >>> Thank you, >>> Alanna Paloma >>> RFC Production Center >>> >>>> On Sep 29, 2025, at 10:50 AM, Alanna Paloma <[email protected] >>>> editor.org> wrote: >>>> >>>> All, >>>> >>>> We have noted Gorry’s approval on the AUTH48 status page: >>>> https://www.rfc-editor.org/auth48/rfc9868 >>>> >>>> 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, >>>> Alanna Paloma >>>> RFC Production Center >>>> >>>>> On Sep 27, 2025, at 12:12 AM, Gorry Fairhurst <[email protected]> >>>>> wrote: >>>>> >>>>> On 26/09/2025 21:58, Alanna Paloma wrote: >>>>>> Hi Joe, >>>>>> >>>>>> Thank you for your approval. It has been noted on the AUTH48 status >>>>>> page: >>>>>> https://www.rfc-editor.org/auth48/rfc9868 >>>>>> >>>>>> Once we have received Gorry’s approval of the changes in Section >>>>>> 13, we will ask IANA to update their registry accordingly. After >>>>>> the IANA updates are complete, we will move forward with the >>>>>> publication process. >>>>>> >>>>>> Best regards, >>>>>> Alanna Paloma >>>>>> RFC Production Center >>>>> Alama, >>>>> I approve these changes to Section 13, thank you for all your work, >>>>> Gorry >>>>> (WIT AD) >>>>>> >>>>>> >>>>>>> On Sep 26, 2025, at 1:36 PM, [email protected] wrote: >>>>>>> >>>>>>> Hi, all, >>>>>>> >>>>>>> Looks good from here. >>>>>>> >>>>>>> Joe >>>>>>> — >>>>>>> Dr. Joe Touch, temporal epistemologist >>>>>>> www.strayalpha.com >>>>>>> >>>>>>> >>>>>>>> On Sep 26, 2025, at 11:48 AM, Alanna Paloma <[email protected] >>>>>>>> editor.org> wrote: >>>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> Thanks for spotting that! We’ve updated the files to fix that >>>>>>>> typo. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>> >>>>>>>> The relevant diff files have been posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>> (comprehensive diff) >>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48diff.html >>>>>>>> (AUTH48 changes) >>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48rfcdiff.html >>>>>>>> (AUTH48 changes side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html (last >>>>>>>> version to this one) >>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastrfcdiff.html >>>>>>>> (rfcdiff between last version and this) >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Alanna Paloma >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 26, 2025, at 11:21 AM, C. M. Heard <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Greetings Alanna, >>>>>>>>> >>>>>>>>> Thanks as always for the fast turnaround. I see one residual >>>>>>>>> typo in Section 14: >>>>>>>>> >>>>>>>>> CURRENT >>>>>>>>> Put another way, all options are treated the same, in that the >>>>>>>>> transmitter can add each option as desired and the receiver has >>>>>>>>> the >>>>>>>>> choice to require a given option or not. Only if a particular >>>>>>>>> option >>>>>>>>> is inidcated as mandatory by a receiver (e.g., by API >>>>>>>>> configuration) >>>>>>>>> would the receiver need to confirm it being present and correct. >>>>>>>>> NEW >>>>>>>>> Put another way, all options are treated the same, in that the >>>>>>>>> transmitter can add each option as desired and the receiver has >>>>>>>>> the >>>>>>>>> choice to require a given option or not. Only if a particular >>>>>>>>> option >>>>>>>>> is indicated as mandatory by a receiver (e.g., by API >>>>>>>>> configuration) >>>>>>>>> would the receiver need to confirm it being present and correct. >>>>>>>>> Apart from that, what I see in https://www.rfc- >>>>>>>>> editor.org/authors/rfc9868-lastrfcdiff.htm looks good to me. >>>>>>>>> >>>>>>>>> Mike Heard >>>>>>>>> >>>>>>>>> On Fri, Sep 26, 2025 at 11:11 AM Alanna Paloma >>>>>>>>> <[email protected]> wrote: >>>>>>>>> Hi Joe and Mike, >>>>>>>>> >>>>>>>>> Thank you for your replies. We have noted Mike's approval and >>>>>>>>> updated the files with the additional changes. >>>>>>>>> >>>>>>>>> The files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>> >>>>>>>>> The relevant diff files have been posted here: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>> (comprehensive diff) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48diff.html >>>>>>>>> (AUTH48 changes) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48rfcdiff.html >>>>>>>>> (AUTH48 changes side by side) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html (last >>>>>>>>> version to this one) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastrfcdiff.html >>>>>>>>> (rfcdiff between last version and this) >>>>>>>>> >>>>>>>>> Once we receive approvals from Joe and Gorry (AD), we will move >>>>>>>>> this document forward for publication. >>>>>>>>> >>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9868 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Alanna Paloma >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 26, 2025, at 7:11 AM, Joe Touch <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> That’s better - agreed! >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Joe >>>>>>>>>> — >>>>>>>>>> Joe Touch, temporal epistemologist >>>>>>>>>> www.strayalpha.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Sep 26, 2025, at 7:06 AM, C. M. Heard <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> I would suggest using the word "expression" in place of the >>>>>>>>>>> word "equation" in the following: >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> where Total Per-Frag IP/UDP Options includes the size of all >>>>>>>>>>> IP >>>>>>>>>>> IS: >>>>>>>>>>> In the above equation, the Total Per-Frag IP/UDP Options >>>>>>>>>>> includes >>>>>>>>>>> the size of all IP >>>>>>>>>>> >>>>>>>>>>> Otherwise I am OK with the latest round of proposed changes. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> >>>>>>>>>>> Mike Heard >>>>>>>>>>> >>>>>>>>>>> On Thu, Sep 25, 2025 at 7:49 PM [email protected] >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Hi, all, >>>>>>>>>>> >>>>>>>>>>> I would like to suggest the following edits for clarity. >>>>>>>>>>> Please let me know if the WAS text is insufficiently specific >>>>>>>>>>> to indicate the single location of each edit. I didn’t bother >>>>>>>>>>> indicating that the text not shown continues as-is. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Joe >>>>>>>>>>> ------------ >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> A UDP packet, composed of a UDP header and UDP >>>>>>>>>>> payload; as discussed herein, that payload need >>>>>>>>>>> IS: >>>>>>>>>>> A UDP packet, composed of a UDP header and UDP >>>>>>>>>>> payload; as discussed herein, the UDP payload need >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> that non-terminal fragments are never be >>>>>>>>>>> smaller than 500 bytes. >>>>>>>>>>> IS: >>>>>>>>>>> that non-terminal fragments are never >>>>>>>>>>> smaller than 500 bytes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> Ensuring that unrecognized APC lengths are treated as >>>>>>>>>>> incorrect >>>>>>>>>>> checksums enables future variants of APC to be treated like >>>>>>>>>>> APC. >>>>>>>>>>> IS: >>>>>>>>>>> Ensuring that unrecognized APC lengths are treated as >>>>>>>>>>> incorrect >>>>>>>>>>> checksums enables future variants of APC to be treated >>>>>>>>>>> similarly. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> Define MMS_S as the PMTU less the size of >>>>>>>>>>> IS: >>>>>>>>>>> MMS_S is defined as the PMTU less the size of >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> Then, the size of the largest pre-fragmentation UDP packet >>>>>>>>>>> that the >>>>>>>>>>> receiver will guarantee to accept is the smaller of the MRDS >>>>>>>>>>> size and >>>>>>>>>>> IS: >>>>>>>>>>> Given the above size definitions, the size of the largest >>>>>>>>>>> pre- >>>>>>>>>>> fragmentation UDP packet that the receiver will guarantee to >>>>>>>>>>> accept >>>>>>>>>>> is the smaller of the MRDS size and the following: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> where Total Per-Frag IP/UDP Options includes the size of all >>>>>>>>>>> IP >>>>>>>>>>> IS: >>>>>>>>>>> In the above equation, the Total Per-Frag IP/UDP Options >>>>>>>>>>> includes >>>>>>>>>>> the size of all IP >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> That is, all options are treated the same, in that the >>>>>>>>>>> transmitter >>>>>>>>>>> can add it as desired and the receiver has the option to >>>>>>>>>>> require it >>>>>>>>>>> or not. Only if it is required (e.g., by API configuration) >>>>>>>>>>> would >>>>>>>>>>> the receiver require it being present and correct. >>>>>>>>>>> IS: >>>>>>>>>>> Put another way, all options are treated the same, in that the >>>>>>>>>>> transmitter can add each option as desired and the receiver >>>>>>>>>>> has the choice to require a given option or not. Only if a >>>>>>>>>>> particular option is indicated as mandatory by a receiver >>>>>>>>>>> (e.g., by API configuration) would >>>>>>>>>>> that receiver need to confirm it being both present and >>>>>>>>>>> correct. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WAS: >>>>>>>>>>> That is, for all options: >>>>>>>>>>> IS: >>>>>>>>>>> In summary, for all options: >>>>>>>>>>> >>>>>>>>>>> — >>>>>>>>>>> Dr. Joe Touch, temporal epistemologist >>>>>>>>>>> www.strayalpha.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sep 24, 2025, at 10:57 AM, Alanna Paloma >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Mike, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for sending those additional changes. The files >>>>>>>>>>>> have been updated accordingly. >>>>>>>>>>>> >>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>>>>> >>>>>>>>>>>> The relevant diff files have been posted here: >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48diff.html >>>>>>>>>>>> (AUTH48 changes) >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48rfcdiff.html >>>>>>>>>>>> (AUTH48 changes side by side) >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html >>>>>>>>>>>> (last version to this one) >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastrfcdiff.html >>>>>>>>>>>> (rfcdiff between last version and this) >>>>>>>>>>>> >>>>>>>>>>>> Once we have approval from each author and Gorry (AD), we >>>>>>>>>>>> will move this document forward in the publication process. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Alanna Paloma >>>>>>>>>>>> RFC Production Center >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 24, 2025, at 6:02 AM, C. M. Heard <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Greetings, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for the fast turnaround with the previous updates. >>>>>>>>>>>>> In reviewing I found two residual issues with option >>>>>>>>>>>>> capitalization: >>>>>>>>>>>>> >>>>>>>>>>>>> Section 11.1: >>>>>>>>>>>>> CURRENT >>>>>>>>>>>>> The End of Options List (EOL, Kind=0) option NEW >>>>>>>>>>>>> The End of Options List (EOL, Kind=0) Option >>>>>>>>>>>>> >>>>>>>>>>>>> Section 11.2: >>>>>>>>>>>>> CURRENT >>>>>>>>>>>>> The No Operation (NOP, Kind=1) option >>>>>>>>>>>>> NEW >>>>>>>>>>>>> The No Operation (NOP, Kind=1) Option >>>>>>>>>>>>> >>>>>>>>>>>>> I also noticed that we have an incorrect section number in >>>>>>>>>>>>> the reference in the last sentence of Section 11.1: >>>>>>>>>>>>> CURRENT >>>>>>>>>>>>> for UDP DPLPMTUD (Section 4.1 of [RFC9869]). >>>>>>>>>>>>> NEW >>>>>>>>>>>>> for UDP DPLPMTUD (Section 4.4 of [RFC9869]). >>>>>>>>>>>>> >>>>>>>>>>>>> Mike Heard >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Sep 23, 2025 at 10:50 AM Alanna Paloma >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> Hi Authors and Gorry*, >>>>>>>>>>>>> >>>>>>>>>>>>> *Gorry - As the AD, please review and approve of the >>>>>>>>>>>>> following update in Section 13. >>>>>>>>>>>>> >>>>>>>>>>>>> Old: >>>>>>>>>>>>> >>>>>>>>>>>>>>> All options MUST indicate whether they can be used per- >>>>>>>>>>>>>>> fragment >>>>>>>>>>>>>>> >>>>>>>>>>>>> and, if so, MUST also indicate how their success or failure >>>>>>>>>>>>> is >>>>>>>>>>>>> reported to the user. It is RECOMMENDED to support UDP >>>>>>>>>>>>> Options for >>>>>>>>>>>>> each fragment; it is also RECOMMENDED that options used for >>>>>>>>>>>>> each >>>>>>>>>>>>> fragment be reported to the user as a finite aggregate >>>>>>>>>>>>> (e.g., a sum, >>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>> >>>>>>>>>>>>> Current: >>>>>>>>>>>>> >>>>>>>>>>>>>>> All options MUST indicate whether they can be used per- >>>>>>>>>>>>>>> fragment >>>>>>>>>>>>>>> >>>>>>>>>>>>> and, if so, MUST also indicate how their success or failure >>>>>>>>>>>>> is >>>>>>>>>>>>> reported to the user. It is RECOMMENDED that new options be >>>>>>>>>>>>> designed >>>>>>>>>>>>> to support per-fragment use; it is also RECOMMENDED that >>>>>>>>>>>>> options used >>>>>>>>>>>>> per-fragment be reported to the user as a finite aggregate >>>>>>>>>>>>> (e.g., a sum, >>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>> >>>>>>>>>>>>> See this diff file: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Authors - Thank you for sending the additional changes. We >>>>>>>>>>>>> have updated the files accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Finally, I see in the thread beginning with >>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/auth48archive/VH0cX9X- >>>>>>>>>>>>>> owK3pzcKwjS1Dd9HWKs/ that RFC-to-be 9870 <draft-ietf- >>>>>>>>>>>>>> opsawg-tsvwg-udp-ipfix-14> has been approved by the >>>>>>>>>>>>>> authors; does the RFC Editor intend to update the >>>>>>>>>>>>>> informative reference [Bo24] to point to the published RFC >>>>>>>>>>>>>> instead of the draft? >>>>>>>>>>>>>> >>>>>>>>>>>>> We have updated this reference to use the RFC number. RFCs- >>>>>>>>>>>>> to-be 9868, 9869, and 9870 will be published at the same >>>>>>>>>>>>> time. >>>>>>>>>>>>> >>>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> The relevant diff files have been posted here: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48diff.html >>>>>>>>>>>>> (AUTH48 changes) >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868- >>>>>>>>>>>>> auth48rfcdiff.html (AUTH48 changes side by side) >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html >>>>>>>>>>>>> (last version to this one) >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastrfcdiff.html >>>>>>>>>>>>> (rfcdiff between last version and this) >>>>>>>>>>>>> >>>>>>>>>>>>> We will await any further changes you may have as well >>>>>>>>>>>>> approvals from each author and *Gorry prior to moving this >>>>>>>>>>>>> document forward in the publication process. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Alanna Paloma >>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 22, 2025, at 5:16 PM, C. M. Heard <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Greetings everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I ran the following change requests past Joe, and he stated >>>>>>>>>>>>>> that he agrees with them but would like to have the >>>>>>>>>>>>>> opportunity for one more pass after the changes are >>>>>>>>>>>>>> applied. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What's written below is divided into two parts: change >>>>>>>>>>>>>> requests on the current review version, followed by >>>>>>>>>>>>>> proposed resolution to the option capitalization question. >>>>>>>>>>>>>> Note that the detailed change requests in the first part do >>>>>>>>>>>>>> NOT address the option capitalization question, so to the >>>>>>>>>>>>>> extent that they are accepted, they need to be applied >>>>>>>>>>>>>> BEFORE option capitalization changes are applied. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, allow me to point out (with apologies) that we had a >>>>>>>>>>>>>> change of heart accepting as-is the RFC Editor's change to >>>>>>>>>>>>>> Section 13 to satisfy Gorry's comment, so the list of >>>>>>>>>>>>>> detailed changes includes further editorial suggestions >>>>>>>>>>>>>> that we think better capture the intended meaning. Gorry, >>>>>>>>>>>>>> please look for "may require AD approval" and let us all >>>>>>>>>>>>>> know if you are OK with this proposed change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Finally, I see in the thread beginning with >>>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/auth48archive/VH0cX9X- >>>>>>>>>>>>>> owK3pzcKwjS1Dd9HWKs/ that RFC-to-be 9870 <draft-ietf- >>>>>>>>>>>>>> opsawg-tsvwg-udp-ipfix-14> has been approved by the >>>>>>>>>>>>>> authors; does the RFC Editor intend to update the >>>>>>>>>>>>>> informative reference [Bo24] to point to the published RFC >>>>>>>>>>>>>> instead of the draft? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 4, last paragraph - please eliminate the acronym TE >>>>>>>>>>>>>> as was done in Section 22. >>>>>>>>>>>>>> CURRENT: >>>>>>>>>>>>>> IPv6 Teredo extensions (TEs) [RFC4380] [RFC6081] use a >>>>>>>>>>>>>> similar inconsistency between UDP and IPv6 packet lengths >>>>>>>>>>>>>> to support trailers, but in this case, the values differ >>>>>>>>>>>>>> between the UDP header and an IPv6 length contained as the >>>>>>>>>>>>>> payload of the UDP user data. This allows IPv6 trailers in >>>>>>>>>>>>>> the UDP user data but has no relation to the surplus area >>>>>>>>>>>>>> discussed in this document. As a consequence, TEs are >>>>>>>>>>>>>> compatible with UDP Options. >>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>> IPv6 Teredo extensions [RFC4380] [RFC6081] use a similar >>>>>>>>>>>>>> inconsistency between UDP and IPv6 packet lengths to >>>>>>>>>>>>>> support trailers, but in this case, the values differ >>>>>>>>>>>>>> between the UDP header and an IPv6 length contained as the >>>>>>>>>>>>>> payload of the UDP user data. This allows IPv6 trailers in >>>>>>>>>>>>>> the UDP user data but has no relation to the surplus area >>>>>>>>>>>>>> discussed in this document. As a consequence, Teredo >>>>>>>>>>>>>> extensions are compatible with UDP Options. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 5, last paragraph: correct the citation (this was >>>>>>>>>>>>>> an error in the submitted draft). Note that RFC 6864 is >>>>>>>>>>>>>> already present in the list of Informative References. >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> Zero-length UDP packets have been used as "liveness" >>>>>>>>>>>>>> indicators (see Section 5 of [RFC8085]), but such use is >>>>>>>>>>>>>> dangerous because they lack unique identifiers (the IPv6 >>>>>>>>>>>>>> base header has none, and the IPv4 ID field is deprecated >>>>>>>>>>>>>> for such use [RFC6994]). >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> Zero-length UDP packets have been used as "liveness" >>>>>>>>>>>>>> indicators (see Section 5 of [RFC8085]), but such use is >>>>>>>>>>>>>> dangerous because they lack unique identifiers (the IPv6 >>>>>>>>>>>>>> base header has none, and the IPv4 ID field is deprecated >>>>>>>>>>>>>> for such use [RFC6864]). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 10, revise formatting of Figure 5: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> +--------+--------+------- >>>>>>>>>>>>>> | Kind | Length | (remainder of option...) >>>>>>>>>>>>>> +--------+--------+------- >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> +--------+--------+------------~~------------+ >>>>>>>>>>>>>> | Kind | Length | (remainder of option...) | >>>>>>>>>>>>>> +--------+--------+------------~~------------+ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 10, first paragraph following Table 1, repair a >>>>>>>>>>>>>> "that" which has no referent: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> Options indicated by Kind values in the range 0..191 are >>>>>>>>>>>>>> known as SAFE options because they do not interfere with >>>>>>>>>>>>>> use of that data by legacy endpoints or when the option is >>>>>>>>>>>>>> unsupported. >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> Options indicated by Kind values in the range 0..191 are >>>>>>>>>>>>>> known as SAFE options because they do not interfere with >>>>>>>>>>>>>> use of UDP user data by legacy endpoints or when the option >>>>>>>>>>>>>> is unsupported. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 11.4, shortly after Figure 12, correct the grammar: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The FRAG option MAY be used on a single fragment; in >>>>>>>>>>>>>>>> which case, the Frag. Offset would be zero and the option >>>>>>>>>>>>>>>> would have the 12-byte format. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The FRAG option MAY be used on a single fragment; in this >>>>>>>>>>>>>>>> case, the Frag. Offset would be zero and the option would >>>>>>>>>>>>>>>> have the 12-byte format. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 11.7, first sentence, correct the grammar: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> The echo Request (REQ, Kind=6) and echo Response (RES, >>>>>>>>>>>>>> Kind=7) options provides UDP packet-level acknowledgments >>>>>>>>>>>>>> as a capability for >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> The echo Request (REQ, Kind=6) and echo Response (RES, >>>>>>>>>>>>>> Kind=7) options provide UDP packet-level acknowledgments as >>>>>>>>>>>>>> a capability for >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 11.7, first paragraph after Figure 15, correct the >>>>>>>>>>>>>> grammar: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the implementation includes a layer/library that >>>>>>>>>>>>>>>> produces and consumes REQ/RES on behalf of the >>>>>>>>>>>>>>>> user/application, then that layer MUST be disabled by >>>>>>>>>>>>>>>> default; in which case, REQ/RES are simply sent upon >>>>>>>>>>>>>>>> request by the user/application and passed to it when >>>>>>>>>>>>>>>> received, as with most other UDP Options. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If the implementation includes a layer/library that >>>>>>>>>>>>>>>> produces and consumes REQ/RES on behalf of the >>>>>>>>>>>>>>>> user/application, then that layer MUST be disabled by >>>>>>>>>>>>>>>> default; in this case, REQ/RES are simply sent upon >>>>>>>>>>>>>>>> request by the user/application and passed to it when >>>>>>>>>>>>>>>> received, as with most other UDP Options. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 11.10, final paragraph, remove redundant word: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> Assigned UDP Experimental IDs (ExIDs) are assigned from a >>>>>>>>>>>>>> combined TCP/UDP ExID registry managed by IANA (see Section >>>>>>>>>>>>>> 26). Assigned ExIDs can be used in either the EXP or UEXP >>>>>>>>>>>>>> options (see Section 12.3 for the latter). >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> UDP Experimental IDs (ExIDs) are assigned from a combined >>>>>>>>>>>>>> TCP/UDP ExID registry managed by IANA (see Section 26). >>>>>>>>>>>>>> Assigned ExIDs can be used in either the EXP or UEXP >>>>>>>>>>>>>> options (see Section 12.3 for the latter). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 13, eighth paragraph, UNSAFE is no longer a single >>>>>>>>>>>>>> option (this change is modulo resolution of the option >>>>>>>>>>>>>> capitalization question discussed later): >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At the sender, new options MUST NOT modify UDP packet >>>>>>>>>>>>>>>> content anywhere outside their option field, excepting >>>>>>>>>>>>>>>> only those contained within the UNSAFE option; areas that >>>>>>>>>>>>>>>> need to remain unmodified include the IP header, IP >>>>>>>>>>>>>>>> options, UDP user data, and surplus area (i.e., other >>>>>>>>>>>>>>>> options). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At the sender, new options MUST NOT modify UDP packet >>>>>>>>>>>>>>>> content anywhere outside their option field, excepting >>>>>>>>>>>>>>>> only UNSAFE options; areas that need to remain unmodified >>>>>>>>>>>>>>>> include the IP header, IP options, UDP user data, and >>>>>>>>>>>>>>>> surplus area (i.e., other options). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 13, second-from-last paragraph, further edits from >>>>>>>>>>>>>> Mike, who apologizes for changing his mind after indicating >>>>>>>>>>>>>> concurrence (may require AD approval): >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All options MUST indicate whether they can be used per- >>>>>>>>>>>>>>>> fragment and, if so, MUST also indicate how their success >>>>>>>>>>>>>>>> or failure is reported to the user. It is RECOMMENDED to >>>>>>>>>>>>>>>> support UDP Options for each fragment; it is also >>>>>>>>>>>>>>>> RECOMMENDED that options used for each fragment be >>>>>>>>>>>>>>>> reported to the user as a finite aggregate (e.g., a sum, >>>>>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All options MUST indicate whether they can be used per- >>>>>>>>>>>>>>>> fragment and, if so, MUST also indicate how their success >>>>>>>>>>>>>>>> or failure is reported to the user. It is RECOMMENDED >>>>>>>>>>>>>>>> that new options be designed to support per-fragment use; >>>>>>>>>>>>>>>> it is also RECOMMENDED that options used per-fragment be >>>>>>>>>>>>>>>> reported to the user as a finite aggregate (e.g., a sum, >>>>>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 13, last two paragraphs, fix a formatting error >>>>>>>>>>>>>> (our apologies; this was in the submitted I-D): >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> With one exception, UNSAFE options are used when UDP user >>>>>>>>>>>>>> data needs to be modified: >>>>>>>>>>>>>> o >> The FRAG option modifies UDP user data, splitting it >>>>>>>>>>>>>> across multiple IP packets. UNSAFE options MAY modify the >>>>>>>>>>>>>> UDP user data, e.g., by encryption, compression, or other >>>>>>>>>>>>>> transformations. All other (SAFE) options MUST NOT modify >>>>>>>>>>>>>> the UDP user data. >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> With one exception, UNSAFE options are used when UDP user >>>>>>>>>>>>>> data needs to be modified: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The FRAG option modifies UDP user data, splitting it >>>>>>>>>>>>>>>> across multiple IP packets. UNSAFE options MAY modify the >>>>>>>>>>>>>>>> UDP user data, e.g., by encryption, compression, or other >>>>>>>>>>>>>>>> transformations. All other (SAFE) options MUST NOT modify >>>>>>>>>>>>>>>> the UDP user data. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 15, final paragraph, correct the grammar: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> Similarly, APIs are not intended to provide >>>>>>>>>>>>>> user/application control over UDP fragment boundaries on a >>>>>>>>>>>>>> per-packet basis; although, they are expected to allow >>>>>>>>>>>>>> control over which options, including fragmentation, are >>>>>>>>>>>>>> enabled (or disabled) on a per-packet basis. >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> Similarly, APIs are not intended to provide >>>>>>>>>>>>>> user/application control over UDP fragment boundaries on a >>>>>>>>>>>>>> per-packet basis; they are, however, expected to allow >>>>>>>>>>>>>> control over which options, including fragmentation, are >>>>>>>>>>>>>> enabled (or disabled) on a per-packet basis. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 18, first paragraph, move citation of UDP-Lite RFC >>>>>>>>>>>>>> to the sentence that discusses UDP-lite: >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> Such inconsistency has been utilized in UDP-Lite using a >>>>>>>>>>>>>> different transport number. There are no known systems that >>>>>>>>>>>>>> use this inconsistency for UDP [RFC3828]. >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> Such inconsistency has been utilized in UDP-Lite using a >>>>>>>>>>>>>> different transport number [RFC3828]. There are no known >>>>>>>>>>>>>> systems that use this inconsistency for UDP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 18, third paragraph, remove unintended paragraph >>>>>>>>>>>>>> break (this was a page break in the submitted draft; there >>>>>>>>>>>>>> was no break in the Word source): >>>>>>>>>>>>>> CURRENT >>>>>>>>>>>>>> One reported embedded device passes the entire IP datagram >>>>>>>>>>>>>> to the UDP application layer. Although this feature could >>>>>>>>>>>>>> enable application-layer UDP Option processing, it would >>>>>>>>>>>>>> require that conventional UDP user applications examine >>>>>>>>>>>>>> only the UDP user data. >>>>>>>>>>>>>> This feature is also inconsistent with the UDP application >>>>>>>>>>>>>> interface [RFC0768] [RFC1122]. >>>>>>>>>>>>>> NEW >>>>>>>>>>>>>> One reported embedded device passes the entire IP datagram >>>>>>>>>>>>>> to the UDP application layer. Although this feature could >>>>>>>>>>>>>> enable application-layer UDP Option processing, it would >>>>>>>>>>>>>> require that conventional UDP user applications examine >>>>>>>>>>>>>> only the UDP user data. This feature is also inconsistent >>>>>>>>>>>>>> with the UDP application interface [RFC0768] [RFC1122]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regarding the as-yet unaddressed follow-up question: >>>>>>>>>>>>>> We have one follow-up question. To reflect the >>>>>>>>>>>>>> capitalization of “UDP Option”, should “option” in the >>>>>>>>>>>>>> terms below also be capitalized? >>>>>>>>>>>>>> >>>>>>>>>>>>>> TCP option >>>>>>>>>>>>>> IP option >>>>>>>>>>>>>> SAFE option >>>>>>>>>>>>>> UNSAFE option >>>>>>>>>>>>>> FRAG option >>>>>>>>>>>>>> NOP option >>>>>>>>>>>>>> EOL option >>>>>>>>>>>>>> MRDS option >>>>>>>>>>>>>> MSS option >>>>>>>>>>>>>> MDS option >>>>>>>>>>>>>> RES option >>>>>>>>>>>>>> REQ option >>>>>>>>>>>>>> TIME option >>>>>>>>>>>>>> TS option >>>>>>>>>>>>>> EXP option >>>>>>>>>>>>>> UEXP option >>>>>>>>>>>>>> UENC option >>>>>>>>>>>>>> UCMP option >>>>>>>>>>>>>> AUTH option >>>>>>>>>>>>>> APC option >>>>>>>>>>>>>> JUNK option >>>>>>>>>>>>>> LITE option >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on the practices in RFC 9293, we would say NO to >>>>>>>>>>>>>> capitalizing "option" in the following specific >>>>>>>>>>>>>> expressions, which are outside the central subject matter >>>>>>>>>>>>>> of RFC-to-be 9868, >>>>>>>>>>>>>> >>>>>>>>>>>>>> TCP option >>>>>>>>>>>>>> IP option >>>>>>>>>>>>>> IPv4 option >>>>>>>>>>>>>> >>>>>>>>>>>>>> and YES for all the others listed above plus the following >>>>>>>>>>>>>> variants: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Option Checksum (OCS) option >>>>>>>>>>>>>> Additional Payload Checksum (APC, Kind=2) option >>>>>>>>>>>>>> Fragmentation (FRAG, Kind=3) option >>>>>>>>>>>>>> Maximum Datagram Size (MDS, Kind=4) option >>>>>>>>>>>>>> TCP Maximum Segment Size (MSS) option >>>>>>>>>>>>>> Maximum Reassembled Datagram Size (MRDS, Kind=5) option >>>>>>>>>>>>>> echo Request (REQ, Kind=6) and echo Response (RES, Kind=7) >>>>>>>>>>>>>> options >>>>>>>>>>>>>> Timestamp (TIME, Kind=8) option >>>>>>>>>>>>>> TCP's Timestamp (TS) option >>>>>>>>>>>>>> Authentication (AUTH, Kind=9) option >>>>>>>>>>>>>> Experimental (EXP, Kind=127) option >>>>>>>>>>>>>> The length of the Experimental option >>>>>>>>>>>>>> UNSAFE Compression (UCMP, Kind=192) option >>>>>>>>>>>>>> UNSAFE Encryption (UENC, Kind=193) option >>>>>>>>>>>>>> UNSAFE Experimental (UEXP, Kind=254) option >>>>>>>>>>>>>> Authentication (AUTH) option >>>>>>>>>>>>>> UNSAFE Encryption (UENC) option >>>>>>>>>>>>>> UDP EXP (Section 11.10) or UEXP (Section 12.3) options >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your patience and hard work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike Heard >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Sep 19, 2025 at 9:39 AM C. M. Heard >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I concur with the change below. I am presently doing a >>>>>>>>>>>>>> thorough reading of the document and will send updates >>>>>>>>>>>>>> after having cleared them with Joe. We will provide an >>>>>>>>>>>>>> answer to the outstanding follow up question at that time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Sep 19, 2025 at 9:30 AM Alanna Paloma >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> Hi Gorry, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your reply. We’ve noted your approval on the >>>>>>>>>>>>>> AUTH48 status page: >>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9868 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Per your suggestion, we have updated the text as follows. >>>>>>>>>>>>>> Please review and let us know if further updates are >>>>>>>>>>>>>> needed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Old: >>>>>>>>>>>>>> It is RECOMMENDED that options be useful per- >>>>>>>>>>>>>> fragment; it is also RECOMMENDED that options used per- >>>>>>>>>>>>>> fragment be >>>>>>>>>>>>>> reported to the user as a finite aggregate (e.g., a sum, a >>>>>>>>>>>>>> flag, >>>>>>>>>>>>>> etc.) rather than individually. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current: >>>>>>>>>>>>>> It is RECOMMENDED to support UDP Options for >>>>>>>>>>>>>> each fragment; it is also RECOMMENDED that options used for >>>>>>>>>>>>>> each >>>>>>>>>>>>>> fragment be reported to the user as a finite aggregate >>>>>>>>>>>>>> (e.g., a sum, >>>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>>>>>>> >>>>>>>>>>>>>> The relevant diff files have been posted here: >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-auth48diff.html >>>>>>>>>>>>>> (AUTH48 changes) >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868- >>>>>>>>>>>>>> auth48rfcdiff.html (AUTH48 changes side by side) >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastdiff.html >>>>>>>>>>>>>> (last version to this one) >>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-lastrfcdiff.html >>>>>>>>>>>>>> (rfcdiff between last version and this) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that we are awaiting response from the authors to our >>>>>>>>>>>>>> follow-up question. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> Alanna Paloma >>>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 18, 2025, at 12:32 AM, Gorry Fairhurst >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18/09/2025 00:02, Alanna Paloma wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Authors and Gorry (AD)*, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Gorry - As the AD, please review and approve of the >>>>>>>>>>>>>>>> following changes: >>>>>>>>>>>>>>>> - Section 11.4: added a 2119/8174 keyword >>>>>>>>>>>>>>>> - Section 13: updated usage of 2119/8174 keywords >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Section 11.4: added a 2119/8174 keyword >>>>>>>>>>>>>>> - Approved. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Section 13: updated usage of 2119/8174 keywords >>>>>>>>>>>>>>> - Usage is approved, but I have concerns about one phrase: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> UPDATED TEXT: “It is RECOMMENDED that options be useful >>>>>>>>>>>>>>> per-fragment” >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This reads oddly around a requirement to be “useful”. I >>>>>>>>>>>>>>> think the intended meaning is OK, but the phrasing is >>>>>>>>>>>>>>> wrong, and I think the recommendation is to support UDP >>>>>>>>>>>>>>> options for each fragment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> —— >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best wishes, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Gorry >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> See this diff file: >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868- >>>>>>>>>>>>>>>> auth48diff.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Authors - Thank you for your reply. We have updated as >>>>>>>>>>>>>>>> requested. Feel free to do a full content review and let >>>>>>>>>>>>>>>> us know if any further changes are needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have one follow-up question. To reflect the >>>>>>>>>>>>>>>> capitalization of “UDP Option”, should “option” in the >>>>>>>>>>>>>>>> terms below also be capitalized? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TCP option >>>>>>>>>>>>>>>> IP option >>>>>>>>>>>>>>>> SAFE option >>>>>>>>>>>>>>>> UNSAFE option >>>>>>>>>>>>>>>> FRAG option >>>>>>>>>>>>>>>> NOP option >>>>>>>>>>>>>>>> EOL option >>>>>>>>>>>>>>>> MRDS option >>>>>>>>>>>>>>>> MSS option >>>>>>>>>>>>>>>> MDS option >>>>>>>>>>>>>>>> RES option >>>>>>>>>>>>>>>> REQ option >>>>>>>>>>>>>>>> TIME option >>>>>>>>>>>>>>>> TS option >>>>>>>>>>>>>>>> EXP option >>>>>>>>>>>>>>>> UEXP option >>>>>>>>>>>>>>>> UENC option >>>>>>>>>>>>>>>> UCMP option >>>>>>>>>>>>>>>> AUTH option >>>>>>>>>>>>>>>> APC option >>>>>>>>>>>>>>>> JUNK option >>>>>>>>>>>>>>>> LITE option >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.xml >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The relevant diff files have been posted here: >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>>>>>>>>> (comprehensive diff) >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868- >>>>>>>>>>>>>>>> auth48diff.html (AUTH48 changes) >>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868- >>>>>>>>>>>>>>>> auth48rfcdiff.html (AUTH48 changes side by side) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the document carefully and contact us with >>>>>>>>>>>>>>>> any further updates you may have. Note that we do not >>>>>>>>>>>>>>>> make changes once a document is published as an RFC. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We will await any further changes you may have and >>>>>>>>>>>>>>>> approvals from each author and *Gorry prior to moving >>>>>>>>>>>>>>>> forward in the publication process. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9868 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>>>> Alanna Paloma >>>>>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 16, 2025, at 8:52 PM, C. M. Heard >>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Greetings, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Joe and I have discussed the questions posed by the RFC >>>>>>>>>>>>>>>>> Editor team; our responses are in-line below. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note that neither of us has done a full review of all of >>>>>>>>>>>>>>>>> the document content, and we still need to do that >>>>>>>>>>>>>>>>> before we clear the document for publication. We leave >>>>>>>>>>>>>>>>> it to the discretion of the RFC Editor team whether to >>>>>>>>>>>>>>>>> make updated review products with the changes below >>>>>>>>>>>>>>>>> before we do the full content review, or whether it is >>>>>>>>>>>>>>>>> better for us to do the full content review now and >>>>>>>>>>>>>>>>> provide a second list of changes. Please let us know. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> GORRY, please note the question below directed to you >>>>>>>>>>>>>>>>>>> concerning the stability of the proposed URL for >>>>>>>>>>>>>>>>>>> [Zu20]. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Mike Heard >>>>>>>>>>>>>>>>> (speaking for both Joe and myself) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Sep 11, 2025 at 9:57 AM <rfc-editor@rfc- >>>>>>>>>>>>>>>>> editor.org> wrote: >>>>>>>>>>>>>>>>> Authors, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please >>>>>>>>>>>>>>>>> resolve (as necessary) >>>>>>>>>>>>>>>>> the following questions, which are also in the source >>>>>>>>>>>>>>>>> file. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1) <!-- [rfced] Mike, we note that your name appears as >>>>>>>>>>>>>>>>> follows in the >>>>>>>>>>>>>>>>> Authors' Addresses section: >>>>>>>>>>>>>>>>> C. M. (Mike) Heard (editor) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is this how you prefer that it be displayed going >>>>>>>>>>>>>>>>> forward? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes please. >>>>>>>>>>>>>>>>> In your earlier RFCs, it has appeared as follows: >>>>>>>>>>>>>>>>> C. M. Heard >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In addition, we note that RFC 3637 displayed "C. M. >>>>>>>>>>>>>>>>> Heard" in the document >>>>>>>>>>>>>>>>> header, while RFCs 3638 and 4181 used "C. Heard". Please >>>>>>>>>>>>>>>>> let us know you >>>>>>>>>>>>>>>>> preference, and we will use that in this document and >>>>>>>>>>>>>>>>> any future RFCs. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Let's use C. Heard in the document header. That will >>>>>>>>>>>>>>>>> match RFCs 3638, 4181, and 4841. >>>>>>>>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those >>>>>>>>>>>>>>>>> that appear in >>>>>>>>>>>>>>>>> the title) for use on https://www.rfc-editor.org/search. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We believe that the title has all the keywords that are >>>>>>>>>>>>>>>>> needed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3) <!--[rfced] Text that is preceded with ">>" is not >>>>>>>>>>>>>>>>> indented. Would you >>>>>>>>>>>>>>>>> like each instance to be indented, or may we update this >>>>>>>>>>>>>>>>> text as follows? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> In this document, the characters ">>" preceding an >>>>>>>>>>>>>>>>> indented line(s) >>>>>>>>>>>>>>>>> indicates a statement using the key words listed above. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> In this document, the characters ">>" preceding text >>>>>>>>>>>>>>>>> indicate a statement using the key words listed above. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Since these always occur at the start of a paragraph, we >>>>>>>>>>>>>>>>> prefer: >>>>>>>>>>>>>>>>> In this document, the characters ">>" at the beginning >>>>>>>>>>>>>>>>> of a >>>>>>>>>>>>>>>>> paragraph indicate a statement using the key words >>>>>>>>>>>>>>>>> listed above. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 4) <!-- [rfced] Informative reference RFC 793 has been >>>>>>>>>>>>>>>>> obsoleted by RFC >>>>>>>>>>>>>>>>> 9293. We recommend replacing RFC 793 with RFC 9293. >>>>>>>>>>>>>>>>> However, if RFC 793 >>>>>>>>>>>>>>>>> must be referenced, we suggest mentioning RFC 9293 >>>>>>>>>>>>>>>>> (e.g., "most widely >>>>>>>>>>>>>>>>> known from TCP [RFC793], which has been obsoleted by >>>>>>>>>>>>>>>>> [RFC9293]"). See >>>>>>>>>>>>>>>>> Section 4.8.6 of RFC 7322 ("RFC Style Guide"). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> o Socket pair - a pair of sockets defining a UDP >>>>>>>>>>>>>>>>> exchange, defined >>>>>>>>>>>>>>>>> by a remote socket and a local socket, each composed of >>>>>>>>>>>>>>>>> an IP >>>>>>>>>>>>>>>>> address and UDP port number (most widely known from TCP >>>>>>>>>>>>>>>>> [RFC793]) >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree. The new text should be: >>>>>>>>>>>>>>>>> o Socket pair – a pair of sockets defining a UDP >>>>>>>>>>>>>>>>> exchange, defined >>>>>>>>>>>>>>>>> by a remote socket and a local socket, each composed of >>>>>>>>>>>>>>>>> an IP >>>>>>>>>>>>>>>>> address and UDP port number (most widely known from TCP >>>>>>>>>>>>>>>>> [RFC793], >>>>>>>>>>>>>>>>> which has been obsoleted by [RFC9293]) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 5) <!--[rfced] We are having some difficulty >>>>>>>>>>>>>>>>> understanding the intention >>>>>>>>>>>>>>>>> of "to ignore" in the sentence below. Should all UDP >>>>>>>>>>>>>>>>> options that a >>>>>>>>>>>>>>>>> receiver does not recognize be ignored? Please review >>>>>>>>>>>>>>>>> and let us know how >>>>>>>>>>>>>>>>> this sentence may be clarified. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> o UNSAFE options - UDP options that are not designed to >>>>>>>>>>>>>>>>> be safe for >>>>>>>>>>>>>>>>> a receiver that does not understand them to ignore. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We propose: >>>>>>>>>>>>>>>>> o UNSAFE options – UDP options that are not designed to >>>>>>>>>>>>>>>>> be safely >>>>>>>>>>>>>>>>> ignored by a receiver that does not understand them. 6) >>>>>>>>>>>>>>>>> <!--[rfced] To avoid use of "required" and "require" in >>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>> sentence to improve readability, may we update "require" >>>>>>>>>>>>>>>>> with "need"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Internet historians have suggested a number of possible >>>>>>>>>>>>>>>>> reasons why the design of UDP includes this field, e.g., >>>>>>>>>>>>>>>>> to support >>>>>>>>>>>>>>>>> multiple UDP packets within the same IP datagram or to >>>>>>>>>>>>>>>>> indicate the >>>>>>>>>>>>>>>>> length of the UDP user data as distinct from zero >>>>>>>>>>>>>>>>> padding required >>>>>>>>>>>>>>>>> for systems that require writes that are not byte- >>>>>>>>>>>>>>>>> aligned. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> Internet historians have suggested a number of possible >>>>>>>>>>>>>>>>> reasons why the design of UDP includes this field, e.g., >>>>>>>>>>>>>>>>> to support >>>>>>>>>>>>>>>>> multiple UDP packets within the same IP datagram or to >>>>>>>>>>>>>>>>> indicate the >>>>>>>>>>>>>>>>> length of the UDP user data as distinct from zero >>>>>>>>>>>>>>>>> padding required >>>>>>>>>>>>>>>>> for systems that need writes that are not byte-aligned. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> Internet historians have suggested a number of possible >>>>>>>>>>>>>>>>> reasons why the design of UDP includes this field, e.g., >>>>>>>>>>>>>>>>> to support multiple UDP packets within the same IP >>>>>>>>>>>>>>>>> datagram or to indicate the length of the UDP user data >>>>>>>>>>>>>>>>> as distinct from zero padding required for systems that >>>>>>>>>>>>>>>>> cannot write an arbitrary number of bytes of data. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 7) <!--[rfced] We are having difficulty parsing the >>>>>>>>>>>>>>>>> second sentence below. >>>>>>>>>>>>>>>>> In particular, the meaning of "in the absence of these >>>>>>>>>>>>>>>>> extensions" is >>>>>>>>>>>>>>>>> unclear. Please review and let us know how this text may >>>>>>>>>>>>>>>>> be updated for >>>>>>>>>>>>>>>>> clarity. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> UDP options have been designed based on the following >>>>>>>>>>>>>>>>> core >>>>>>>>>>>>>>>>> principles. Each is an observation about (preexisting) >>>>>>>>>>>>>>>>> UDP [RFC768] >>>>>>>>>>>>>>>>> in the absence of these extensions that this document >>>>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>>>> intend to change or a lesson learned from other protocol >>>>>>>>>>>>>>>>> designs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> UDP options have been designed based on the following >>>>>>>>>>>>>>>>> core >>>>>>>>>>>>>>>>> principles. Each is an (preexisting) observation about >>>>>>>>>>>>>>>>> UDP [RFC768] >>>>>>>>>>>>>>>>> that this document does not intend to change or is a >>>>>>>>>>>>>>>>> lesson learned >>>>>>>>>>>>>>>>> from other protocol designs. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> UDP options have been designed based on the following >>>>>>>>>>>>>>>>> core principles. Each is an observation about >>>>>>>>>>>>>>>>> preexisting behavior of UDP [RFC768] in the absence of >>>>>>>>>>>>>>>>> these extensions that this document does not intend to >>>>>>>>>>>>>>>>> change or a lesson learned from other protocol designs. >>>>>>>>>>>>>>>>> 8) <!--[rfced] In the Meaning column of Table 1, should >>>>>>>>>>>>>>>>> "UCMP", "UENC", >>>>>>>>>>>>>>>>> and "UEXP" be updated to include "UNSAFE" to reflect >>>>>>>>>>>>>>>>> their expansions in >>>>>>>>>>>>>>>>> Sections 12.1, 12.2, and 12.3, respectively? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> RESERVED for Compression (UCMP) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> RESERVED for Encryption (UENC) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> RFC 3692-style experiments (UEXP) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> RESERVED for UNSAFE Compression (UCMP) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> RESERVED for UNSAFE Encryption (UENC) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> RFC 3692-style UNSAFE experiments (UEXP) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note that "RFC 3692-style" has been updated to "RFC3692- >>>>>>>>>>>>>>>>> style" (no space) >>>>>>>>>>>>>>>>> to match use in other RFCs. We also updated some >>>>>>>>>>>>>>>>> capitalization in the >>>>>>>>>>>>>>>>> meaning column. If there are no objections, we will ask >>>>>>>>>>>>>>>>> IANA to update >>>>>>>>>>>>>>>>> their registry accordingly. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this suggestion. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 9) <!-- [rfced] The "UDP Option Kind Numbers" registry >>>>>>>>>>>>>>>>> does not include >>>>>>>>>>>>>>>>> the asterisks that appear in Table 1 (see >>>>>>>>>>>>>>>>> https://www.iana.org/assignments/udp/udp.xhtml#udp- >>>>>>>>>>>>>>>>> options). We believe this is an expected >>>>>>>>>>>>>>>>> difference between what appears in the RFC and the IANA >>>>>>>>>>>>>>>>> registry, as the >>>>>>>>>>>>>>>>> asterisks are defined in the RFC and the IANA registry >>>>>>>>>>>>>>>>> has a comparable >>>>>>>>>>>>>>>>> note about values 0-7. Please confirm that this is >>>>>>>>>>>>>>>>> correct. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, this is correct. >>>>>>>>>>>>>>>>> 10) <!--[rfced] Should "MUST be" also apply to "user >>>>>>>>>>>>>>>>> data received sent to >>>>>>>>>>>>>>>>> the user"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> If the >>>>>>>>>>>>>>>>> user data is not empty, all UDP options MUST be silently >>>>>>>>>>>>>>>>> ignored and >>>>>>>>>>>>>>>>> the user data received sent to the user. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> If the >>>>>>>>>>>>>>>>> user data is not empty, all UDP options MUST be silently >>>>>>>>>>>>>>>>> ignored and >>>>>>>>>>>>>>>>> the user data received MUST be sent to the user. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. >>>>>>>>>>>>>>>>> 11) <!--[rfced] As "RES" means "Response", should "RES >>>>>>>>>>>>>>>>> response" be >>>>>>>>>>>>>>>>> updated to "RES option"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> For example, an application needs to explicitly enable >>>>>>>>>>>>>>>>> the generation >>>>>>>>>>>>>>>>> of a RES response by DPLPMTUD when using UDP Options >>>>>>>>>>>>>>>>> [Fa25]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> For example, an application needs to explicitly enable >>>>>>>>>>>>>>>>> the generation >>>>>>>>>>>>>>>>> of a RES option by DPLPMTUD when using UDP Options >>>>>>>>>>>>>>>>> [Fa25]. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. >>>>>>>>>>>>>>>>> 12) <!--[rfced] Should "UKind" be updated to simply be >>>>>>>>>>>>>>>>> "Kind"? "UKind" >>>>>>>>>>>>>>>>> does not appear to be defined in this document. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Receivers supporting UDP options MUST silently drop >>>>>>>>>>>>>>>>>>> the UDP user >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> data of the reassembled datagram if any fragment or the >>>>>>>>>>>>>>>>> entire >>>>>>>>>>>>>>>>> datagram includes an UNSAFE option whose UKind is not >>>>>>>>>>>>>>>>> supported or >>>>>>>>>>>>>>>>> if an UNSAFE option appears outside the context of a >>>>>>>>>>>>>>>>> fragment or >>>>>>>>>>>>>>>>> reassembled fragments. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. "UKind" is a leftover from a >>>>>>>>>>>>>>>>> previous approach ☹️ >>>>>>>>>>>>>>>>> 13) <!--[rfced] To avoid repetition of "except" and >>>>>>>>>>>>>>>>> "excepting" in the >>>>>>>>>>>>>>>>> same sentence to improve readability, may be update >>>>>>>>>>>>>>>>> "excepting" to >>>>>>>>>>>>>>>>> "besides"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> At the sender, new options MUST NOT modify UDP packet >>>>>>>>>>>>>>>>>>> content >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> anywhere except within their option field, excepting >>>>>>>>>>>>>>>>> only those >>>>>>>>>>>>>>>>> contained within the UNSAFE option... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> At the sender, new options MUST NOT modify UDP packet >>>>>>>>>>>>>>>>>>> content >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> anywhere except within their option field, besides only >>>>>>>>>>>>>>>>> those >>>>>>>>>>>>>>>>> contained within the UNSAFE option... >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> At the sender, new options MUST NOT modify UDP packet >>>>>>>>>>>>>>>>>>> content anywhere outside their option field, excepting >>>>>>>>>>>>>>>>>>> only those contained within the UNSAFE option; areas >>>>>>>>>>>>>>>>>>> that need to remain unmodified include the IP header, >>>>>>>>>>>>>>>>>>> IP options, the UDP user data, and the surplus area >>>>>>>>>>>>>>>>>>> (i.e., other options). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 14) <!--[rfced] As "RECOMMENDS" is not a 2119/8174 >>>>>>>>>>>>>>>>> keyword, may we >>>>>>>>>>>>>>>>> rephrase this sentence to use "RECOMMENDED"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> This document RECOMMENDS that options be >>>>>>>>>>>>>>>>> useful per-fragment and also RECOMMENDS that options >>>>>>>>>>>>>>>>> used per- >>>>>>>>>>>>>>>>> fragment be reported to the user as a finite aggregate >>>>>>>>>>>>>>>>> (e.g., a sum, >>>>>>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps B: >>>>>>>>>>>>>>>>> It is RECOMMENDED that options be >>>>>>>>>>>>>>>>> useful per-fragment; it is also RECOMMENDED that options >>>>>>>>>>>>>>>>> used per- >>>>>>>>>>>>>>>>> fragment be reported to the user as a finite aggregate >>>>>>>>>>>>>>>>> (e.g., a sum, >>>>>>>>>>>>>>>>> a flag, etc.) rather than individually. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are OK with the proposed change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 15) <!--[rfced] For clarity, may we update "certain" >>>>>>>>>>>>>>>>> with "some"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Note that only certain of the initially defined options >>>>>>>>>>>>>>>>> violate >>>>>>>>>>>>>>>>> these rules: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> Note that only some of the initially defined options >>>>>>>>>>>>>>>>> violate >>>>>>>>>>>>>>>>> these rules: >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Given the context of the paragraph that follows, we >>>>>>>>>>>>>>>>> would prefer: >>>>>>>>>>>>>>>>> With one exception, UNSAFE options are used when UDP >>>>>>>>>>>>>>>>> user data needs to be modified: >>>>>>>>>>>>>>>>> 16) <!--[rfced] To avoid awkward hyphenation, may we >>>>>>>>>>>>>>>>> rephrase >>>>>>>>>>>>>>>>> "non-'must-support' options" as follows? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Non-"must-support" options MAY be ignored by >>>>>>>>>>>>>>>>>>> receivers, if >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> present, e.g., based on API settings. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Options that are not must-support options MAY be >>>>>>>>>>>>>>>>>>> ignored by >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> receivers, if present, e.g., based on API settings. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Options that are not “must-support” options MAY, if >>>>>>>>>>>>>>>>>>> present, be ignored by receivers, based, e.g., on API >>>>>>>>>>>>>>>>>>> settings. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 17) <!--[rfced] FYI - To improve readability, we have >>>>>>>>>>>>>>>>> rephrased this >>>>>>>>>>>>>>>>> sentence and added quotes. Please review and let us know >>>>>>>>>>>>>>>>> of any >>>>>>>>>>>>>>>>> objections. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> UDP options are no exception and here are >>>>>>>>>>>>>>>>> specified as MUST NOT be altered in transit. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>>> UDP options are no exception and are >>>>>>>>>>>>>>>>> specified here as "MUST NOT be altered in transit". >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. >>>>>>>>>>>>>>>>> 18) <!--[rfced] Would you like to add a citation for the >>>>>>>>>>>>>>>>> claimed report >>>>>>>>>>>>>>>>> below? If so, please provide us with the reference >>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Additionally, may we change the first instance of >>>>>>>>>>>>>>>>> "reported" to avoid "has >>>>>>>>>>>>>>>>> been reported ... to be reported"? Perhaps "has been >>>>>>>>>>>>>>>>> noted"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> It has been reported that Alcatel-Lucent's "Brick" >>>>>>>>>>>>>>>>> Intrusion >>>>>>>>>>>>>>>>> Detection System has a default configuration that >>>>>>>>>>>>>>>>> interprets >>>>>>>>>>>>>>>>> inconsistencies between UDP Length and IP Length as an >>>>>>>>>>>>>>>>> attack to be >>>>>>>>>>>>>>>>> reported. Note that other firewall systems, e.g., >>>>>>>>>>>>>>>>> CheckPoint, use a >>>>>>>>>>>>>>>>> default "relaxed UDP length verification" to avoid >>>>>>>>>>>>>>>>> falsely >>>>>>>>>>>>>>>>> interpreting this inconsistency as an attack. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are OK with the proposed change. Unfortunately, we do >>>>>>>>>>>>>>>>> not have a citation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 19) <!--[rfced] May we update "non-aware" to "unaware"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Some of the mechanisms in this document can generate >>>>>>>>>>>>>>>>> more zero- >>>>>>>>>>>>>>>>> length UDP packets for a UDP option aware endpoint than >>>>>>>>>>>>>>>>> for a legacy >>>>>>>>>>>>>>>>> (non-aware) endpoint (e.g., based some error conditions) >>>>>>>>>>>>>>>>> and some >>>>>>>>>>>>>>>>> can generate fewer (e.g., fragment reassembly). >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We prefer the phrase "(non-aware)" just be removed, as >>>>>>>>>>>>>>>>> "legacy" already implies "not UDP option aware." There >>>>>>>>>>>>>>>>> is also a typo to be fixed (s/based/based on/): >>>>>>>>>>>>>>>>> Some of the mechanisms in this document can generate >>>>>>>>>>>>>>>>> more zero-length UDP packets for a UDP Option aware >>>>>>>>>>>>>>>>> endpoint than for a legacy endpoint (e.g., based on some >>>>>>>>>>>>>>>>> error conditions) and some can generate fewer (e.g., >>>>>>>>>>>>>>>>> fragment reassembly). >>>>>>>>>>>>>>>>> 20) <!--[rfced] We note that "TCP Sharing" does not >>>>>>>>>>>>>>>>> occur in RFC 9040, but >>>>>>>>>>>>>>>>> it does use "TCB sharing". In the sentence below, should >>>>>>>>>>>>>>>>> "TCP Sharing" >>>>>>>>>>>>>>>>> be updated to "TCB sharing"? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Some TCP connection parameters, stored in the TCP >>>>>>>>>>>>>>>>> Control Block, can >>>>>>>>>>>>>>>>> be usefully shared either among concurrent connections >>>>>>>>>>>>>>>>> or between >>>>>>>>>>>>>>>>> connections in sequence, known as TCP Sharing [RFC9040]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> Some TCP connection parameters, stored in the TCP >>>>>>>>>>>>>>>>> Control Block (TCB), >>>>>>>>>>>>>>>>> can be usefully shared either among concurrent >>>>>>>>>>>>>>>>> connections or between >>>>>>>>>>>>>>>>> connections in sequence, known as TCB sharing [RFC9040]. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. "TCP Sharing" was a typo. >>>>>>>>>>>>>>>>> 21) <!--[rfced] We note that no other drafts, only RFCs, >>>>>>>>>>>>>>>>> are mentioned >>>>>>>>>>>>>>>>> in Section 22. Therefore, may we update the section >>>>>>>>>>>>>>>>> title as follows? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> 22. Interactions with other RFCs (and drafts) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> 22. Interactions with Other RFCs >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. >>>>>>>>>>>>>>>>> 22) <!--[rfced] FYI - To clarify the quoted text, we >>>>>>>>>>>>>>>>> have added the >>>>>>>>>>>>>>>>> following citation. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> TE defines the length >>>>>>>>>>>>>>>>> of an IPv6 payload inside UDP as pointing to less than >>>>>>>>>>>>>>>>> the end of >>>>>>>>>>>>>>>>> the UDP payload, enabling trailing options for that IPv6 >>>>>>>>>>>>>>>>> packet: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "..the IPv6 packet length (i.e., the Payload Length >>>>>>>>>>>>>>>>> value in >>>>>>>>>>>>>>>>> the IPv6 header plus the IPv6 header size) is less than >>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>> equal to the UDP payload length (i.e., the Length value >>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> the UDP header minus the UDP header size)" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Current (using blockquote): >>>>>>>>>>>>>>>>> In [RFC6081], TE defines the length >>>>>>>>>>>>>>>>> of an IPv6 payload inside UDP as pointing to less than >>>>>>>>>>>>>>>>> the end of >>>>>>>>>>>>>>>>> the UDP payload, enabling trailing options for that IPv6 >>>>>>>>>>>>>>>>> packet: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | ...the IPv6 packet length (i.e., the Payload Length >>>>>>>>>>>>>>>>> value in the >>>>>>>>>>>>>>>>> | IPv6 header plus the IPv6 header size) is less than or >>>>>>>>>>>>>>>>> equal to >>>>>>>>>>>>>>>>> | the UDP payload length (i.e., the Length value in the >>>>>>>>>>>>>>>>> UDP header >>>>>>>>>>>>>>>>> | minus the UDP header size) >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are fine with the addition of this reference; >>>>>>>>>>>>>>>>> however, upon reflection, we would prefer to eliminate >>>>>>>>>>>>>>>>> the acronym TE. How about: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> CURRENT: >>>>>>>>>>>>>>>>> Teredo extensions (TEs) define use of a similar >>>>>>>>>>>>>>>>> difference between these lengths for trailers [RFC4380] >>>>>>>>>>>>>>>>> [RFC6081]. In [RFC6081], TE defines the length of an >>>>>>>>>>>>>>>>> IPv6 payload inside UDP as pointing to less than the end >>>>>>>>>>>>>>>>> of the UDP payload, enabling trailing options for that >>>>>>>>>>>>>>>>> IPv6 packet: >>>>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>>>> Teredo extensions define use of a similar difference >>>>>>>>>>>>>>>>> between these lengths for trailers [RFC4380] [RFC6081]. >>>>>>>>>>>>>>>>> In [RFC6081], Teredo extensions define the length of an >>>>>>>>>>>>>>>>> IPv6 payload inside UDP as pointing to less than the end >>>>>>>>>>>>>>>>> of the UDP payload, enabling trailing options for that >>>>>>>>>>>>>>>>> IPv6 packet: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 23) <!-- [rfced] This text has been (mostly) updated to >>>>>>>>>>>>>>>>> match the note >>>>>>>>>>>>>>>>> that appears in the unified registry. We say "mostly" >>>>>>>>>>>>>>>>> because we will ask >>>>>>>>>>>>>>>>> IANA to update their registry to use "RFC 9896" instead >>>>>>>>>>>>>>>>> of "the >>>>>>>>>>>>>>>>> corresponding reference". Please review and let us know >>>>>>>>>>>>>>>>> if any updates >>>>>>>>>>>>>>>>> are needed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> IANA is also >>>>>>>>>>>>>>>>> hereby requested to update the unified TCP/UDP ExID >>>>>>>>>>>>>>>>> registry with >>>>>>>>>>>>>>>>> the direction that "16-bit ExIDs can be used with either >>>>>>>>>>>>>>>>> TCP or UDP; >>>>>>>>>>>>>>>>> 32-bit ExIDs can be used with TCP or their first 16 bits >>>>>>>>>>>>>>>>> can be used >>>>>>>>>>>>>>>>> with UDP", and with further detail provided below. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>>> IANA has added a note to the unified TCP/UDP >>>>>>>>>>>>>>>>> ExID registry specifying the following: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> | Note 16-bit ExIDs can be used with either TCP or UDP; >>>>>>>>>>>>>>>>> 32-bit ExIDs >>>>>>>>>>>>>>>>> | can be used with TCP or their first 16 bits can be >>>>>>>>>>>>>>>>> used with UDP. >>>>>>>>>>>>>>>>> | Use with each transport (TCP, UDP) is indicated in the >>>>>>>>>>>>>>>>> protocol >>>>>>>>>>>>>>>>> | column, as defined in RFC 9868. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The note to the registry looks good to us. >>>>>>>>>>>>>>>>> 24) <!-- [rfced] For clarity, may we update this >>>>>>>>>>>>>>>>> sentence as follows? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Values in the TCP/UDP ExID registry are to be assigned >>>>>>>>>>>>>>>>> by IANA using >>>>>>>>>>>>>>>>> first-come, first-served (FCFS) rules applied to both >>>>>>>>>>>>>>>>> the ExID value >>>>>>>>>>>>>>>>> and the acronym [RFC8126]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> Values in the TCP/UDP ExID registry are to be assigned >>>>>>>>>>>>>>>>> by IANA using >>>>>>>>>>>>>>>>> the First Come First Served (FCFS) policy [RFC8126], >>>>>>>>>>>>>>>>> which applies to >>>>>>>>>>>>>>>>> both the ExID value and the acronym. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We agree with this change. >>>>>>>>>>>>>>>>> 25) <!--[rfced] FYI - We've added a URL to this >>>>>>>>>>>>>>>>> reference. Please review >>>>>>>>>>>>>>>>> and let us know of any objections. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> [Zu20] Zullo, R., T. Jones, and G. Fairhurst, >>>>>>>>>>>>>>>>> "Overcoming the >>>>>>>>>>>>>>>>> Sorrows of the Young UDP Options," 2020 Network Traffic >>>>>>>>>>>>>>>>> Measurement and Analysis Conference (TMA), IEEE, 2020. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>>> [Zu20] Zullo, R., Jones, T., and G. Fairhurst, >>>>>>>>>>>>>>>>> "Overcoming the >>>>>>>>>>>>>>>>> Sorrows of the Young UDP Options", 4th Network Traffic >>>>>>>>>>>>>>>>> Measurement and Analysis Conference (TMA), 2020, >>>>>>>>>>>>>>>>> <https://dl.ifip.org/db/conf/tma/tma2020/tma2020-camera- >>>>>>>>>>>>>>>>> paper70.pdf>. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have no objections, but Joe has concerns about the >>>>>>>>>>>>>>>>> stability of this URL. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The responsible AD for this RFC-to-be, Gorry Fairhurst, >>>>>>>>>>>>>>>>> is a co-author of that document; perhaps he can speak to >>>>>>>>>>>>>>>>> that point. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 26) <!--[rfced] Terminology >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> a) Throughout the text, the following terminology >>>>>>>>>>>>>>>>> appears to be used >>>>>>>>>>>>>>>>> inconsistently. May we update to use the term on the >>>>>>>>>>>>>>>>> right to make it >>>>>>>>>>>>>>>>> consistent throughout the document? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> extended length > Extended Length >>>>>>>>>>>>>>>>> option length > Option Length >>>>>>>>>>>>>>>>> UDP length > UDP Length >>>>>>>>>>>>>>>>> UDP option > UPD Option >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We are OK with these changes. >>>>>>>>>>>>>>>>> b) 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> UDP Timestamp vs. UDP timestamp >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We believe that the usage is correct as is; the contexts >>>>>>>>>>>>>>>>> are different. Section 11.4 says: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> UDP fragmentation relies on a fragment expiration timer, >>>>>>>>>>>>>>>>> which can be preset or could use a value computed using >>>>>>>>>>>>>>>>> the UDP Timestamp option. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> whereas Section 11.8 says: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> UDP timestamps are modeled after TCP timestamps and have >>>>>>>>>>>>>>>>> similar expectations. In particular, they are expected >>>>>>>>>>>>>>>>> to follow these guidelines: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 27) <!--[rfced] Abbreviations >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> a) FYI - We have added expansions for the following >>>>>>>>>>>>>>>>> abbreviations >>>>>>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>>>>>>>>>>>>>>>> review each >>>>>>>>>>>>>>>>> expansion in the document carefully to ensure >>>>>>>>>>>>>>>>> correctness. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cyclic Redundancy Check (CRC) >>>>>>>>>>>>>>>>> Datagram Congestion Control Protocol (DCCP) >>>>>>>>>>>>>>>>> Effective MTU for Receiving (EMTU_R) >>>>>>>>>>>>>>>>> Internet Small Computer System Interface (iSCSI) >>>>>>>>>>>>>>>>> Path MTU (PMTU) >>>>>>>>>>>>>>>>> Stream Control Transmission Protocol (SCTP) >>>>>>>>>>>>>>>>> TCP Authentication Option Encryption (TCP-AO-ENC) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The following change is requested for the first use of >>>>>>>>>>>>>>>>> EMTU_R: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Section 11.4, CURRENT: >>>>>>>>>>>>>>>>> The Fragmentation (FRAG, Kind=3) option supports UDP >>>>>>>>>>>>>>>>> fragmentation and reassembly, which can be used to >>>>>>>>>>>>>>>>> transfer UDP messages larger than allowed by the IP >>>>>>>>>>>>>>>>> receive MTU (Effective MTU for Receiving (EMTU_R) >>>>>>>>>>>>>>>>> [RFC1122]). >>>>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>>>> The Fragmentation (FRAG, Kind=3) option supports UDP >>>>>>>>>>>>>>>>> fragmentation and reassembly, which can be used to >>>>>>>>>>>>>>>>> transfer UDP messages larger than allowed by the IP >>>>>>>>>>>>>>>>> Effective MTU for Receiving (EMTU_R) [RFC1122]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The following change is requested for the first (and >>>>>>>>>>>>>>>>> only) use TCP-AO-ENC: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Section 12.2, OLD: >>>>>>>>>>>>>>>>> UENC is expected to provide all of the services of the >>>>>>>>>>>>>>>>> AUTH option (Section 11.9) and in addition to encrypt >>>>>>>>>>>>>>>>> the UDP user data and some (e.g., later, in sequence) >>>>>>>>>>>>>>>>> UDP options, in a similar manner as TCP Authentication >>>>>>>>>>>>>>>>> Option Encryption (TCP-AO-ENC) [To18]. >>>>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>>>> UENC is expected to provide all of the services of the >>>>>>>>>>>>>>>>> AUTH option (Section 11.9) and in addition to encrypt >>>>>>>>>>>>>>>>> the UDP user data and some (e.g., later, in sequence) >>>>>>>>>>>>>>>>> UDP options, in a similar manner as TCP Authentication >>>>>>>>>>>>>>>>> Option Extension for Payload Encryption (TCP-AO-ENC) >>>>>>>>>>>>>>>>> [To18]. >>>>>>>>>>>>>>>>> b) How should "MMS_S" be expanded? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Suppose that MMS_S is the PMTU less the size of >>>>>>>>>>>>>>>>> the IP header and the UDP header, i.e., the maximum UDP >>>>>>>>>>>>>>>>> message size >>>>>>>>>>>>>>>>> that can be successfully sent in a single UDP datagram >>>>>>>>>>>>>>>>> if there are >>>>>>>>>>>>>>>>> no IP options or extension headers and no UDP per- >>>>>>>>>>>>>>>>> fragment options. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This was intended to be a local definition of the symbol >>>>>>>>>>>>>>>>> MMS_S for use in the equation that follows the above >>>>>>>>>>>>>>>>> paragraph, and it's used nowhere else. Just expanding it >>>>>>>>>>>>>>>>> in the obvious way as Maximum Message Size for Sending >>>>>>>>>>>>>>>>> (that's what it's mnemonic for) would result in some >>>>>>>>>>>>>>>>> really weird text. What about the following edits to >>>>>>>>>>>>>>>>> make it clear that we are defining a symbol, not using >>>>>>>>>>>>>>>>> an acronym? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Section 11.6, CURRENT: >>>>>>>>>>>>>>>>> These parameters plus the Path MTU (PMTU) allow a sender >>>>>>>>>>>>>>>>> to compute the size of the largest pre-fragmentation UDP >>>>>>>>>>>>>>>>> packet that a receiver will guarantee to accept. Suppose >>>>>>>>>>>>>>>>> that MMS_S is the PMTU less the size of the IP header >>>>>>>>>>>>>>>>> and the UDP header, i.e., the maximum UDP message size >>>>>>>>>>>>>>>>> that can be successfully sent in a single UDP datagram >>>>>>>>>>>>>>>>> if there are no IP options or extension headers and no >>>>>>>>>>>>>>>>> UDP per-fragment options. >>>>>>>>>>>>>>>>> Then, the size of the largest pre-fragmentation UDP >>>>>>>>>>>>>>>>> packet that the receiver will guarantee to accept is the >>>>>>>>>>>>>>>>> smaller of the MRDS size and >>>>>>>>>>>>>>>>> (MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP >>>>>>>>>>>>>>>>> Options) + 8 >>>>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>>>> These parameters plus the Path MTU (PMTU) allow a sender >>>>>>>>>>>>>>>>> to compute the size of the largest pre-fragmentation UDP >>>>>>>>>>>>>>>>> packet that a receiver will guarantee to accept. Define >>>>>>>>>>>>>>>>> MMS_S as the PMTU less the size of the IP header and the >>>>>>>>>>>>>>>>> UDP header, i.e., the maximum UDP message size that can >>>>>>>>>>>>>>>>> be successfully sent in a single UDP datagram if there >>>>>>>>>>>>>>>>> are no IP options or extension headers and no UDP per- >>>>>>>>>>>>>>>>> fragment options. Then the size of the largest pre- >>>>>>>>>>>>>>>>> fragmentation UDP packet that the receiver will >>>>>>>>>>>>>>>>> guarantee to accept is the smaller of the MRDS size and >>>>>>>>>>>>>>>>> (MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP >>>>>>>>>>>>>>>>> Options) + 8 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> c) We note that "TIME" is expanded as "Timestamps" and >>>>>>>>>>>>>>>>> "Timestamp" >>>>>>>>>>>>>>>>> (plural and singular). How should it be updated for >>>>>>>>>>>>>>>>> consistency? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> 11.8. Timestamps (TIME) >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> The Timestamp (TIME, Kind=8) option exchanges two four- >>>>>>>>>>>>>>>>> byte unsigned >>>>>>>>>>>>>>>>> timestamp fields. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Similarly, should "TS" be expanded as "Timestamp" or >>>>>>>>>>>>>>>>> "Timestamps" >>>>>>>>>>>>>>>>> (singular or plural)? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> It serves a similar purpose to TCP's TS option >>>>>>>>>>>>>>>>> [RFC7323], enabling UDP to estimate the round-trip time >>>>>>>>>>>>>>>>> (RTT) >>>>>>>>>>>>>>>>> between hosts. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It should be singular ("Timestamp"). >>>>>>>>>>>>>>>>> 28) <!--[rfced] To avoid redundant acronym expansions, >>>>>>>>>>>>>>>>> should the >>>>>>>>>>>>>>>>> following instances be updated for simplicity? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> a) APC checksums: If expanded, "APC checksum" would read >>>>>>>>>>>>>>>>> as "Additional >>>>>>>>>>>>>>>>> Payload Checksum checksum". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with incorrect APC checksums SHOULD be >>>>>>>>>>>>>>>>>>> passed to the >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> application with an indication of APC failure. >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with unrecognized APC lengths MUST receive >>>>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> treatment as UDP packets with incorrect APC checksums. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with incorrect APCs SHOULD be passed to >>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> application with an indication of APC failure. >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with unrecognized APC lengths MUST receive >>>>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> treatment as UDP packets with incorrect APCs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The option is called APC, but within the APC is a kind, >>>>>>>>>>>>>>>>> a length, and a checksum field. We would therefore >>>>>>>>>>>>>>>>> prefer: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with incorrect APC Option checksums fields >>>>>>>>>>>>>>>>>>> SHOULD be passed to the >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> application with an indication of APC Option checksum >>>>>>>>>>>>>>>>> failure. >>>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> UDP packets with unrecognized APC lengths MUST receive >>>>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> treatment as UDP packets with incorrect APC Option >>>>>>>>>>>>>>>>> checksum fields. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> b) MRDS size: If expanded, "MRDS size" would read >>>>>>>>>>>>>>>>> "Maximum Reassembled >>>>>>>>>>>>>>>>> Datagram Size size". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> MRDS size is the UDP equivalent of IP's EMTU_R but the >>>>>>>>>>>>>>>>> two are not related [RFC1122]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> MRDS is the UDP equivalent of IP's EMTU_R but the >>>>>>>>>>>>>>>>> two are not related [RFC1122]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> The MRDS size field is the UDP equivalent of IP’s >>>>>>>>>>>>>>>>> EMTU_R, but the two are not related [RFC1122]. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> c) TSval value: If expanded, "TSval value" would read as >>>>>>>>>>>>>>>>> "TS Value value". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>>> Received TSval and TSecr values are provided to the >>>>>>>>>>>>>>>>> application, which can pass the TSval value to be used >>>>>>>>>>>>>>>>> as TSecr on >>>>>>>>>>>>>>>>> UDP messages sent in response (i.e., to echo the >>>>>>>>>>>>>>>>> received TSval). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>>> Received TSval and TSecr values are provided to the >>>>>>>>>>>>>>>>> application, which can pass the TSval to be used as >>>>>>>>>>>>>>>>> TSecr on >>>>>>>>>>>>>>>>> UDP messages sent in response (i.e., to echo the >>>>>>>>>>>>>>>>> received TSval). >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would prefer: >>>>>>>>>>>>>>>>> Received TSval and TSecr field contents are provided to >>>>>>>>>>>>>>>>> the application, which can pass the received TSval to be >>>>>>>>>>>>>>>>> used as TSecr in UDP messages sent in response (i.e., to >>>>>>>>>>>>>>>>> echo the received TSval). >>>>>>>>>>>>>>>>> 29) <!-- [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. Updates of >>>>>>>>>>>>>>>>> this nature >>>>>>>>>>>>>>>>> typically result in more precise language, which is >>>>>>>>>>>>>>>>> helpful for readers. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note that our script did not flag any words in >>>>>>>>>>>>>>>>> particular, but this should >>>>>>>>>>>>>>>>> still be reviewed as a best practice. >>>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Alanna Paloma and Sandy Ginoza >>>>>>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sep 11, 2025, at 9:49 AM, [email protected] >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Updated 2025/09/11 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * [email protected] (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). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> * [email protected], 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, >>>>>>>>>>>>>>>>> [email protected] 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/rfc9868.xml >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.html >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.pdf >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868.txt >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-diff.html >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-rfcdiff.html >>>>>>>>>>>>>>>>> (side by side) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9868-xmldiff1.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are >>>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9868 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> RFC Editor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>>>>>> RFC 9868 (draft-ietf-tsvwg-udp-options-45) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Title : Transport Options for UDP >>>>>>>>>>>>>>>>> Author(s) : J. Touch, C. M. Heard, Ed. >>>>>>>>>>>>>>>>> WG Chair(s) : Martin Duke, Zaheduzzaman Sarker >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
