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]
