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? 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. --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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. --> 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]) --> 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. --> 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. --> 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. --> 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. --> 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. --> 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. --> 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]. --> 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. --> 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... --> 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. --> 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: --> 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. --> 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". --> 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. --> 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). --> 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]. --> 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 --> 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) --> 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. --> 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. --> 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>. --> 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 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 --> 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) 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. 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. --> 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. 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]. 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). --> 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]
