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]
