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