Answers inline below. > 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 is still accurate?
Yes. > * Are the References, 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? > If so, please provide a pointer to that document (e.g., this document's > terminology should match DNS terminology in RFC 9499). Should match TLS terminology in RFC 8446. > * 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.) Field names should follow TLS conventions and are we believe already formatted this way. > 3) Is there any text that should be handled extra cautiously? For example, > are > there any sections that were contentious when the document was drafted? The paragraph titled "Failures" in section 4 should be removed as per https://mailarchive.ietf.org/arch/msg/tls/qdW6qWeOQMfyQ8bMZkfwulKq3rE/ > 4) Is there anything else that the RPC should be aware of while editing this > document? Not that I'm aware of. > 5) This document uses one or more of the following text styles. > Are these elements used consistently? > > * fixed width font (<tt/> or `) > * italics (<em/> or *) > * bold (<strong/> or **) I think so. > 6) This document contains artwork that might be sourcecode: > > * Please identify which (if any) artwork elements are sourcecode > * Does the sourcecode validate? > * Some sourcecode types (e.g., YANG) require certain references and/or text > in the Security Considerations section. Is this information correct? > * Is the sourcecode type indicated in the XML? (see information about > sourcecode types). No artwork is strictly source code. - The first two pieces of artwork in Section 3.2 are TLS data structures. - The next two pieces of artwork in Section 3.2 are a mix of pseudocode in no particular language and a representation of a TLS data structure. - The first piece of artwork in Section 3.3 is pseudocode in no particular language. - The second piece of artwork in Section 3.3 is based on the figure in Section 7.1 of RFC 8446 > 7) This document is part of Cluster 553. > > * To help the reader understand the content of the cluster, is there a > document in the cluster that should be read first? Next? 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. Although related by the topic of post-quantum cryptography, they are independent and need no connection. > >> On Nov 5, 2025, at 12:05 PM, [email protected] wrote: >> >> The document draft-ietf-tls-hybrid-design-16 has >> changed from EDIT state to AUTH state. We thought you'd like to know. >> You can also follow your document's state at >> <https://www.rfc-editor.org/current_queue.php>. >> For definitions of state names, please see >> <https://www.rfc-editor.org/about/queue/#state_def>. >> >> If you have questions, please send mail to [email protected]. >> >> Best regards, >> The RFC Editor Team >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
