Hi Tobias, Thank you for your reply!
Sincerely, Sarah Tarrant RFC Production Center > On Feb 22, 2026, at 7:38 AM, Tobias Fiebig <[email protected]> wrote: > > Dear Sarah, >> Congratulations, your document has been successfully added to the RFC >> Editor queue! > > Thank you. > > -- > >> 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? > > We kept these sections up-to-date during the LC/IESG process and no > updates are necessary. > >> >> 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). > > 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.) > > This document should be at least internally consistent, and otherwise > consistent with patterns found in other DNS documents. > >> 3) Please carefully review the entries and their URLs in the >> References section 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. >> >> 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. > > The proposed procedure works fine. > >> 4) Is there any text that requires special handling? For example: >> *Are there any sections that were contentious when the document was >> drafted? > > Most parts of the document saw discussions, but I would argue that no > one section specifically stuck out. > >> *Are any sections that need to be removed before publication marked >> as such (e.g., Implementation Status sections (per RFC 7942)). > > There are no sections that need to be removed. > >> *Are there any instances of repeated text/sections that should be >> edited the same way? > > - 3.2 partially internally (TCP vs. UDP) > - IPv4/IPv6 wording in Section 4 > >> 5) Is there anything else that the RPC should be aware of while >> editing this document? > > Not to our knowledge. > > -- > > Thank you again for taking up the task of editing the document for > publication. Please feel free to reach out if any additional questions > come up. > > With best regards, > Tobias > > -- > My working day may not be your working day. Please do not feel obliged > to reply to my email outside of your normal working hours. > ----------------------------------------------------------------- > Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) > Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken > E1 4 - Raum 517 mobil: +31 616 80 98 99 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
