Hi! Just checking in to see if you’d seen this. spt
> On Feb 13, 2026, at 12:56, [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] Because this document updates RFC 9147, please > review the errata reported for RFC 9147 > (https://www.rfc-editor.org/errata/rfc9147) > and let us know if you confirm our opinion that none of them > are relevant to the content of this document. > --> > > > 2) <!-- [rfced] Please note that the title of the document has been updated > as follows. > > Original: > Return Routability Check for DTLS 1.2 and DTLS 1.3 > > Current: > Return Routability Check for DTLS 1.2 and 1.3 > --> > > > 3) <!-- [rfced] Is this sentence in the abstract correct as is, or should > it include the word "subprotocol" (which is used in a similar sentence in > the Introduction)? > > Original: > This document specifies a return routability check for use in context > of the Connection ID (CID) construct for the Datagram Transport Layer > Security (DTLS) protocol versions 1.2 and 1.3. > > Current: > This document specifies a Return Routability Check (RRC) for use in > the context of the Connection ID (CID) construct for the Datagram > Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. > > Perhaps: > This document specifies a Return Routability Check (RRC) subprotocol for > use in the context of the Connection ID (CID) construct for the Datagram > Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. > --> > > > 4) <!-- [rfced] Should "return routability check" here be updated to "basic > return routability check" in these instances in Section 5.2? > > Original: > * When a return_routability_check message of type path_drop was > received, the initiator MUST perform a return routability > check on the observed new address, as described in > Section 5.1. > ... > 5. If T expires the peer address binding is not updated. In this > case, the initiator MUST perform a return routability check on > the observed new address, as described in Section 5.1. > > Perhaps: > * When a return_routability_check message of type path_drop was > received, the initiator MUST perform a basic return routability > check on the observed new address, as described in > Section 5.1. > ... > 5. If T expires the peer address binding is not updated. In this > case, the initiator MUST perform a basic return routability check on > the observed new address, as described in Section 5.1. > --> > > > 5) <!-- [rfced] For clarity, may we update "cater for"? > > Original: > * The initiator MAY send multiple return_routability_check messages > of type path_challenge to cater for packet loss on the probed > path. > > ... > > Note that RRC does not cater for PMTU discovery on the reverse path. > > > Perhaps: > * The initiator MAY send multiple return_routability_check messages > of type path_challenge to account for packet loss on the probed > path. > > ... > > Note that RRC does not account for PMTU discovery on the reverse path. > --> > > > 6) <!-- [rfced] We see the following phrasing with the message types > defined in this document (i.e., path_challenge, path_response, and > path_drop). Please review and let us know if any updates are needed for > consistency. > > return_routability_check message of type path_response > return_routability_check message of type path_challenge > return_routability_check message of type path_drop > > path_challenge message > path_response message > path_drop message > > path_challenge > path_response > path_drop > > Some examples: > 3. The peer (i.e., the responder) cryptographically verifies the > received return_routability_check message of type path_challenge > and responds by echoing the cookie value in a > return_routability_check message of type path_response. > ... > Each path_challenge message MUST contain random data. > ... > * The responder MUST send the path_response or the path_drop to the > address from which the corresponding path_challenge was received. > ... > --> > > > 7) <!-- [rfced] Please review "use padding using...up to". Would updating > as follows improve readability of this sentence? > > Original: > * The initiator MAY use padding using the record padding mechanism > available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the > sending direction) up to the anti-amplification limit to probe if > the path MTU (PMTU) for the new path is still acceptable. > > Perhaps: > * The initiator MAY use the record padding mechanism > available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the > sending direction) to add padding up to the anti-amplification limit > to probe if the Path MTU (PMTU) for the new path is still acceptable. > --> > > > 8) <!-- [rfced] FYI - We updated "1s" to "1 second" for clarity. > > Original: > If an implementation has no way to obtain information regarding the > RTT of the active path, T SHOULD be set to 1s. > > Perhaps: > If an implementation has no way to obtain information regarding the > RTT of the active path, T SHOULD be set to 1 second. > --> > > > 9) <!-- [rfced] How may we clarify this sentence, especially "increasing > capabilities" and the text starting with "partly following > terminology..."? > > Original: > Two classes of attackers are considered, off-path and on-path, with > increasing capabilities (see Figure 4) partly following terminology > introduced in QUIC (Section 21.1 of [RFC9000]): > > Perhaps: > This model includes two classes of attackers, off-path and on-path, with > various capabilities (see Figure 4). The following > descriptions of these attackers are based on those > introduced in QUIC (Section 21.1 of [RFC9000]): > --> > > > 10) <!-- [rfced] Please review the use of "(1)" in the sentences below. > Figure 5 does not include a "1". Should "1" be removed from these sentences > or added to Figure 5? Or does "(1)" in these sentences refer to Figure 6? > Let us know how to clarify. Also, should "timeout of (1)" be updated to > "timeout of the path_challenge message (1)"? > > Original: > Figure 5 illustrates the case where a receiver receives a packet with > a new source address. In order to determine that this path change > was not triggered by an off-path attacker, the receiver will send an > RRC message of type path_challenge (1) on the old path. > > <Figure 5> > > Case 1: The old path is dead (e.g., due to a NAT rebinding), which > leads to a timeout of (1). > > As shown in Figure 6, a path_challenge (2) needs to be sent on the > new path. If the sender replies with a path_response on the new path > (3), the switch to the new path is considered legitimate. > > <Figure 6> > --> > > > 11) <!-- [rfced] Would it be helpful to update "path_challenge" here to > "path_challenge (1)"? > > Original: > The receiver sends a path_challenge on the old > path and the sender replies with a path_response (2) on the old path. > The interaction is shown in Figure 8. > > Perhaps: > As shown in Figure 8, the receiver sends a > path_challenge (1) on the old path, and the sender replies with a > path_response (2) on the old path. > --> > > > 12) <!-- [rfced] Font styling > > a) The terms enclosed in <tt> in this document are listed below. Please > review to ensure the usage of <tt> is correct and consistent. Let us know > if any updates are needed. Note that <tt> produces fixed-width font in the > HTML and PDF outputs but no changes in the TXT output. > > <tt>connection_id</tt> > <tt>extension_data</tt> > <tt>extension_type</tt> > <tt>msg_type</tt> > <tt>path_challenge</tt> > <tt>path_drop</tt> > <tt>path_response</tt> > <tt>return_routability_check</tt> > <tt>rrc</tt> > <tt>tls12_cid</tt> > > > b) The following sentence includes <em>, which produces underscores in the > TXT output and italics in the HTML and PDF outputs. Please review to ensure > that this is a correct use of <em>. > > Original: > To prevent this, RRC cookies > must be _freshly_ generated using a reliable source of entropy > [RFC4086]. > --> > > > 13) <!-- [rfced] Please review the "type" attribute of the sourcecode > element in Section 4, as "tls-msg" is not part of the current list of > preferred values > (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types). > > Perhaps "tls-presentation" would be acceptable? This was used for similar > sourcecode in RFCs 9420 and 9458. > > If the current list of preferred values for "type" does not contain an > applicable type, then feel free to suggest a new one. Also, it is > acceptable to leave the "type" attribute not set. > --> > > > 14) <!-- [rfced] Terminology > > a) We see both "Cookie" and "cookie" used in this document. Should these be > uniform? If so, please let us know which form is preferred. > > > b) We see the following forms used in the document? Please review and let > us know if any updates are needed for correctness and consistency. > > Return Routability Check message > RRC message > return_routability_check message > > > c) Is "CID-address binding" correct, or should this be updated to "CID > address binding" (no hyphen)? > > > d) We see that "return routability check" and its acronym "RRC" are used > throughout the document. Would you like to expand the first instance and > then use the acronym in the remainder of the document? Or do you prefer the > current arrangement? > --> > > > 15) <!-- [rfced] 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. > > Constrained Application Protocol (CoAP) > cryptographically secure pseudorandom number generator (CSPRNG) > --> > > > 16) <!-- [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. > > Rebecca VanRheenen and Sandy Ginoza > RFC Production Center > > > > On Feb 13, 2026, at 9:52 AM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2026/02/13 > > 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/rfc9853.xml > https://www.rfc-editor.org/authors/rfc9853.html > https://www.rfc-editor.org/authors/rfc9853.pdf > https://www.rfc-editor.org/authors/rfc9853.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9853-diff.html > https://www.rfc-editor.org/authors/rfc9853-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9853-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9853 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9853 (draft-ietf-tls-dtls-rrc-20) > > Title : Return Routability Check for DTLS 1.2 and DTLS 1.3 > Author(s) : H. Tschofenig, Ed., A. Kraus, T. Fossati > WG Chair(s) : Joseph A. Salowey, Sean Turner, Deirdre Connolly > > Area Director(s) : Deb Cooley, Paul Wouters > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
