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]
