> * 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). > * If you feel no updates to the document are necessary, please reply with any > applicable rationale/comments.
No further updates are ncessary from my point of view. > Please note that the RPC team will not work on your document until we hear > from you > (that is, your document will remain in AUTH state until we receive a reply). > Even > if you don't have guidance or don't feel that you need to make any updates to > the > document, you need to let us know. After we hear from you, your document will > start > moving through the queue. You will be able to review and approve our updates > during AUTH48. Great, thanks. > 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? Yes. > 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, > WG style guide, etc.? If so, please provide a pointer to that information > (e.g., "This document's terminology should match DNS terminology in > RFC 9499." or "This document uses the style info at > <https://httpwg.org/admin/editors/style-guide>."). > * Is there a general pattern of capitalization or formatting of terms that > editors can follow (e.g., "Field names should have initial capitalization." > or "Parameter names should be in double quotes." or "<tt/> should be used > for token names." etc.)? Make the document consistent with the foundational LISP documents RFC9300 and RFC9301. > 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). Okay. > * References to I-Ds that have been replaced by another I-D will be > updated to point to the replacement I-D. Sure, thanks. > * References to documents from other organizations that have been > superseded will be updated to their superseding version. Okay. > 4) Is there any text that requires special handling? For example: > * Are there any sections that were contentious when the document was drafted? Yes, but they have been removed. > * Are any sections that need to be removed before publication marked as such > (e.g., Implementation Status sections (per RFC 7942)). I don't think so. > * Are there any instances of repeated text/sections that should be edited > the same way? No. > 5) Because this document updates RFC 8060, please review > the reported errata and confirm whether they have been addressed in this > document or are not relevant: > > * RFC 8060 (https://www.rfc-editor.org/errata/rfc8060) Done. > 6) Is there anything else that the RPC should be aware of while editing this > document? I don't thinks so. Thanks, Dino -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
