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]
