Same here. — Dr. Joe Touch, temporal epistemologist www.strayalpha.com
> On 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] > <mailto:[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] >> > <mailto:[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] >> >>> <mailto:[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] >> >>> <mailto:[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] >> >>> <mailto:[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] <mailto:[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] >> >>> <mailto:[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] >> >>> <mailto:[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]
