Hi Scott and Douglas, Thank you for the feedback!
Just to clarify, based on the response about artwork/sourcecode, we will leave the artwork as artwork since it's not strictly code to be used literally. Sincerely, Sarah Tarrant RFC Production Center > On Nov 16, 2025, at 3:42 PM, Douglas Stebila <[email protected]> wrote: > > 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]
