Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] References a) Regarding [WHATWG-IPV4], this reference's date is May 2021. The URL provided resolves to a page with "Last Updated 12 May 2025". Note that WHATWG provides "commit snapshots" of their living standards and there are several commit snapshots from May 2021 with the latest being from 20 May 2021. For example: 20 May 2021 (https://url.spec.whatwg.org/commit-snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-ipv4-parser) We recommend updating this reference to the most current version of the WHATWG Living Standard, replacing the URL with the more general URL to the standard (https://url.spec.whatwg.org/), and adding a "commit snapshot" URL to the reference. Current: [WHATWG-IPV4] WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>. b) RFC 6125 has been obsoleted by RFC 9525. May we replace RFC 6125 with RFC 9525? c) Informative Reference RFC 5077 has been obsoleted by RFC 8446. We recommend replacing RFC 5077 with RFC 8446. However, if RFC 5077 must be referenced, we suggest mentioning RFC 8446 (e.g., RFC 5077 has been obsoleted by RFC 8446). See Section 4.8.6 in the RFC Style Guide (RFC 7322). d) FYI, RFCYYY1 (draft-ietf-tls-svcb-ech) will be updated during the XML stage. --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] In the following sentence, does "length other than 8" refer to bytes? If yes, may we update as follows? Current: Otherwise, if it has a length other than 8, the client aborts the handshake with a "decode_error" alert. Perhaps: Otherwise, if it has a length other than 8 bytes, the client aborts the handshake with a "decode_error" alert. --> 4) <!-- [rfced] It seems that "client" was intended to be "clients" (plural) in the sentence below and updated as follows. Please let us know if that is not accurate. Original: Correctly-implemented client will ignore those extensions. Current: Correctly implemented clients will ignore those extensions. --> 5) <!-- [rfced] May we rephrase the following text for an improved sentence flow? Original: The backend server embeds in ServerHello.random a string derived from the inner handshake. Perhaps: A string derived from the inner handshake is embedded into ServerHello.random by the backend server. --> 6) <!--[rfced] How may we update this sentence to make it clear whether all the requirements or only some of the requirements require proxies to act as conforming TLS client and server? For background, in general, the RPC recommends using nonrestrictive "which" and restrictive "that". (More details are on https://www.rfc-editor.org/styleguide/tips/) However, edits to that usage have not been made in this document. In this specific sentence, we are asking about the usage because it can affect the understanding of the statement. Original: The requirements in [RFC8446], Section 9.3 which require proxies to act as conforming TLS client and server provide interoperability with TLS-terminating proxies even in cases where the server supports ECH but the proxy does not, as detailed below. Option A (all requirements require it): The requirements in [RFC8446], Section 9.3, which require proxies to act as conforming TLS client and server, provide interoperability with TLS-terminating proxies even in cases where the server supports ECH but the proxy does not, as detailed below. Option B (some requirements require it): The requirements in [RFC8446], Section 9.3 that require proxies to act as conforming TLS client and server provide interoperability with TLS-terminating proxies even in cases where the server supports ECH but the proxy does not, as detailed below. --> 7) <!-- [rfced] We note that the following terms use fixed-width font inconsistently. Please review these terms and let us know how we should update or if there are any specific patterns that should be followed (e.g., fixed-width font used for field names, variants, etc.). accept_confirmation cipher_suite ClientHello ClientHelloInner ClientHelloOuter ClientHelloOuterAAD config_id ECHClientHello ECHConfig ECHConfig.contents.public_name ECHConfigContents ECHConfigList EncodedClientHelloInner inner maximum_name_length outer payload public_key ServerHello.random zeros --> 8) <!-- [rfced] We note that these terms are used inconsistently. Please let us know which form you prefer. split-mode vs. Split Mode GREASE vs. Grease (IANA Section) --> 9) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. --> 10) <!-- [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. Madison Church and Alice Russo RFC Production Center On Nov 14, 2025, [email protected] wrote: *****IMPORTANT***** Updated 2025/11/14 RFC Author(s): Your document has now entered AUTH48. The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). Please review the procedures for AUTH48 using kramdown-rfc: https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown Once your document has completed AUTH48, it will be published as an RFC. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9849.md https://www.rfc-editor.org/authors/rfc9849.html https://www.rfc-editor.org/authors/rfc9849.pdf https://www.rfc-editor.org/authors/rfc9849.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9849-diff.html https://www.rfc-editor.org/authors/rfc9849-rfcdiff.html (side by side) Diff of the kramdown: https://www.rfc-editor.org/authors/rfc9849-md-diff.html https://www.rfc-editor.org/authors/rfc9849-md-rfcdiff.html (side by side) Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9849 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
