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]
