Hi Stephen, Thank you for your reply!
Sincerely, Sarah Tarrant RFC Production Center > On Jan 28, 2026, at 3:05 AM, Stephen Farrell <[email protected]> > wrote: > > > Hiya, > > On 26/01/2026 22:59, Sarah Tarrant wrote: >> * If you need/want to make updates to your document, we encourage you to >> make those >> changes and resubmit to the Datatracker. This allows for the easy creation >> of diffs, >> which facilitates review by interested parties (e.g., authors, ADs, doc >> shepherds). > > I have no planned updates as of now. This is a pretty simple > document. > >> * If you feel no updates to the document are necessary, please reply with any >> applicable rationale/comments. > > Huh? Asking that seems odd. I've replied below to the relevant points > and don't know what else you might want/need, nor why. > >> 1) As there may have been multiple updates made to the document during Last >> Call, >> please review the current version of the document: >> * Is the text in the Abstract still accurate? >> * Are the Authors' Addresses, Contributors, and Acknowledgments >> sections current? > > All good. > >> 2) Please share any style information that could help us with editing your >> document. For example: >> * Is your document's format or its terminology based on another document? >> If so, please provide a pointer to that document (e.g., this document's >> terminology should match DNS terminology in RFC 9499). >> * Is there a pattern of capitalization or formatting of terms? (e.g., field >> names >> should have initial capitalization; parameter names should be in double >> quotes; >> <tt/> should be used for token names; etc.) > > I think that's ok. > >> 3) Please review the entries in the References section carefully with >> the following in mind. Note that we will update as follows unless we >> hear otherwise at this time: >> * References to obsoleted RFCs will be updated to point to the current >> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >> (RFC Style Guide). >> * References to I-Ds that have been replaced by another I-D will be >> updated to point to the replacement I-D. >> * References to documents from other organizations that have been >> superseded will be updated to their superseding version. > > Typical processing is fine here, there are no refs to e.g. expired > drafts or similar. > >> Note: To check for outdated RFC and I-D references, you can use >> idnits <https://author-tools.ietf.org/idnits>. You can also help the >> IETF Tools Team by testing idnits3 <https://author-tools.ietf.org/idnits3/> >> with your document and reporting any issues to them. >> 4) Is there any text that requires special handling? For example: >> *Are there any sections that were contentious when the document was drafted? >> *Are any sections that need to be removed before publication marked as such >> (e.g., Implementation Status sections (per RFC 7942)). >> *Are there any instances of repeated text/sections that should be edited >> the same way? > > There's a change-control section to remove that is marked as such. > Otherwise all's well. > >> 5) This document is part of Cluster 430: >> www.rfc-editor.org/cluster_info.php?cid=C430 > > I really hope draft-ietf-tls-esni is published soon. Not having that > done is a barrier to releasing a version of OpenSSL supporting ECH as > that project has a policy that the RFC must've been published before > they ship a feature like ECH. I know it's not the RPC's fault, but if > there's any way people on here can speed that up, that'd be great. > (The next OpenSSL release is planned for April so we're getting close > to when it'll be too late for that one.) > >> * To help the reader understand the content of the cluster, is there a >> document in the cluster that should be read first? Next? > > This document is more-or-less an implementation detail related to > draft-ietf-tls-esni (ECH) so that's the primary reference needed to > understand this. None of the other references are highly important. > >> If so, please provide >> the order and we will provide RFC numbers for the documents accordingly. >> If order is not important, please let us know. >> * Is there any text that has been repeated within the cluster document that >> should be edited in the same way (for instance, parallel introductory text or >> Security Considerations)? > > No. > >> * For more information about clusters, see >> https://www.rfc-editor.org/about/clusters/ >> * For a list of all current clusters, see: >> http://www.rfc-editor.org/all_clusters.php >> 6) Is there anything else that the RPC should be aware of while editing this >> document? > > Nope. > > Cheers, > S. > >>> On Jan 26, 2026, at 4:57 PM, [email protected] wrote: >>> >>> Author(s), >>> >>> Your document draft-farrell-tls-pemesni-13, which has been approved for >>> publication as >>> an RFC, has been added to the RFC Editor queue >>> <https://www.rfc-editor.org/current_queue.php>. >>> >>> If your XML file was submitted using the I-D submission tool >>> <https://datatracker.ietf.org/submit/>, we have already retrieved it >>> and have started working on it. >>> >>> If you did not submit the file via the I-D submission tool, or >>> if you have an updated version (e.g., updated contact information), >>> please send us the file at this time by attaching it >>> in your reply to this message and specifying any differences >>> between the approved I-D and the file that you are providing. >>> >>> You will receive a separate message from us asking for style input. >>> Please respond to that message. When we have received your response, >>> your document will then move through the queue. The first step that >>> we take as your document moves through the queue is converting it to >>> RFCXML (if it is not already in RFCXML) and applying the formatting >>> steps listed at <https://www.rfc-editor.org/pubprocess/how-we-update/>. >>> Next, we will edit for clarity and apply the style guide >>> (<https://www.rfc-editor.org/styleguide/>). >>> >>> You can check the status of your document at >>> <https://www.rfc-editor.org/current_queue.php>. >>> >>> You will receive automatic notifications as your document changes >>> queue state (for more information about these states, please see >>> <https://www.rfc-editor.org/about/queue/>). When we have completed >>> our edits, we will move your document to AUTH48 state and ask you >>> to perform a final review of the document. >>> >>> Please let us know if you have any questions. >>> >>> Thank you. >>> >>> The RFC Editor Team >>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
