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]
