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 <[email protected]> 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]
