On Fri, 20 Feb 2026, Sarah Tarrant wrote: > Author(s), > > Congratulations, your document has been successfully added to the RFC Editor > queue! > The team at the RFC Production Center (RPC) is looking forward to working > with you > as your document moves forward toward publication. To help reduce processing > time > and improve editing accuracy, please respond to the questions below. Please > confer > with your coauthors (or authors of other documents if your document is in a > cluster) as necessary prior to taking action in order to streamline > communication. > If your document has multiple authors, only one author needs to reply to this > message.
Thanks Sarah - answers 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 still accurate? Yes. > * 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? > If so, please provide a pointer to that document (e.g., this document's > terminology should match DNS terminology in RFC 9499). This is a RFC for the SSH protocol. It should be roughly consistent with the terminology used in RFC4251. Stylistically, I've roughly followed the message formatting convention used in RFC4252. IMO clarity is more important than strict consistency with these old RFCs. > * 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.) Standard capitalisation of MUST/MUST NOT/SHOULD/etc per BCP 14 Literal strings that appear in protocol messages should be in double quotes both in protocol message definitions and in descriptive text. Protocol message field names should be in double quotes when they appear in descriptive text, but not in the protocol message definition. Section 3.2.1 is a good example of what I mean here. > 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. Note that the reference FIPS.186-4 is withdrawn and superseded by FIPS.186-5. It's important to retain both references here, as a cryptographic algorithm mentioned is only defined in FIPS.186-4. > 4) Is there any text that requires special handling? For example: > * Are there any sections that were contentious when the document was drafted? > * Are any sections that need to be removed before publication marked as such > (e.g., Implementation Status sections (per RFC 7942)). > * Are there any instances of repeated text/sections that should be edited > the same way? There are some sections marked with removeInRFC=true. There was some discussion about retaining sections 1.1 and 2.1, which are among those marked with removeInRFC, but no strong opinions either way. Section 9 is marked removeInRFC and doing so will require cleanup of an orphaned reference to RFC7942. > 5) This document contains 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 > types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) There is no source code in this document. > 6) Is there anything else that the RPC should be aware of while editing this > document? Not that I'm aware of - please email me if you have any further questions, Thanks, Damien -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
