Hi Thomas, Thanks for the quick reply! All of our questions have now been addressed. We’ll leave the current references to [RFC8446] and [RFC8447] as is.
Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. FILES (please refresh): Updated XML file: https://www.rfc-editor.org/authors/rfc9853.xml Updated output files: https://www.rfc-editor.org/authors/rfc9853.txt https://www.rfc-editor.org/authors/rfc9853.pdf https://www.rfc-editor.org/authors/rfc9853.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9853-auth48diff.html https://www.rfc-editor.org/authors/rfc9853-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9853-diff.html https://www.rfc-editor.org/authors/rfc9853-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9853-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9853 Thank you, Rebecca VanRheenen RFC Production Center > On Feb 23, 2026, at 1:43 PM, Thomas Fossati <[email protected]> wrote: > > Hi Rebecca, > > On Mon, 23 Feb 2026 at 21:13, Rebecca VanRheenen > <[email protected]> wrote: >> >> Hi Thomas and other authors, >> >> Thank you for responding to all of our questions! We have updated the >> document accordingly. > > Thanks! > >> Note that we updated Figure 5 per your response to our question #10; please >> review the TXT output (ascii-art) and the HTML/PDF outputs (svg) to make >> sure that the figure appears as desired. > > All three renderings look good. > >> Also, regarding these questions: >> >>> We hava couple of questions re: RFC8446bis and RFC8447bis references. >>> >>> We make normative references to RFC8446 and RFC8447. >>> >>> Their "bis" documents are: >>> - draft-ietf-tls-rfc8447bis (PUB as RFC 9847) >>> - draft-ietf-tls-rfc8446bis (currently in AUTH48, to become RFC 9846) >>> >>> These documents are in the same publication cluster (C430) as RRC, and >>> respectively update and obsolete their counterparts. >>> >>> Two questions: >>> 1. Should the references in RRC be updated (at least, RFC8447 to RFC9847)? >>> 2. Should RRC wait for RFC-to-be 9846 to be published? >> >> For #1, we did update instances of [I-D.ietf-tls-rfc8447bis] in the original >> to [RFC9847]. The only instance of [RFC8447] is in following sentence. Would >> you like to remove the reference to RFC 8447 here and only cite RFC 9847? >> >> Current: >> Recommended: >> Indication of whether the message is recommended for >> implementations to support. The semantics for this field is >> defined in Section 5 of [RFC8447] and updated in Section 3 of >> [RFC9847]. >> >> Perhaps: >> Recommended: >> Indication of whether the message is recommended for >> implementations to support. The semantics for this field is >> defined in Section 3 of [RFC9847]. > > "Current" works fine, thank you! > >> For #2, note that RFC-to-be 9846 has been in AUTH48 for over two months, and >> the author is working through some issues that may take additional time (see >> https://www.rfc-editor.org/auth48/rfc9846). The decision to either 1) keep >> the reference to [RFC8446] in this document or 2) update to [RFC9846] and >> wait to publish together is up to you as authors. The document shepherd and >> AD may also provide input. Please let us know how you would like to proceed. > > We refer to RFC 8446 for the presentation language (§4), some of the > terminology (§1.1), and the requirement for a CSPRNG (Appendix C.1). > As all of these are stable, referencing either document is essentially > equivalent. > There is no need to queue behind 8446bis, IMHO. > > cheers! -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
