Sarah, This response should hold for all documents in the BFD authentication cluster. If you need individual responses I'll reply for the second document when you get to that.
Juniper Business Use Only On 11/13/25, 10:47, "Sarah Tarrant" <[email protected] <mailto:[email protected]>> wrote: > 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? It should be. > * Are the Authors' Addresses, Contributors, and Acknowledgments > sections current? Juniper was recently acquired by HPE. While my affiliation shows HPE in the current document, the email address currently refers to Juniper. This bit of IT change is in flux as we speak. It is likely that the postal address and email address will need to be updated prior to RFC publication. Once I have the new information I'll update our editor ASAP. > 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). For this cluster of three BFD authentication documents, they will primarily inherit from RFC 5880 as the base BFD specification. RFC 5881/5882 will also have some overlap. > * 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.) Consistency vs. RFC 5880 will be our primary style goal. However, as we know, capitalization is inconsitent in our documentation. > 3) Please review the entries in the References section carefully 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. As best we know, the references are current and correctly categorized as normative/informative. > 4) Is there any text that should be handled extra cautiously? For example, are > there any sections that were contentious when the document was drafted? Two items worth highlighting as sensitive are items surrounding the definition and use of "meticulous" for the sequence number and the more/less computationally intensive authentication. In particular, the strong/less didn't have consistent support from security review during IESG evaluation. The current wording is the best we could do at the time. Alternative suggestions from the editor can be considered, but may require review by the WG and the IESG if we are suggesting changes. Bringing consistency to the use of abbreviation in the text for this overly long strong/less strong terminology would be helpful. > 5) Is there anything else that the RPC should be aware of while editing this > document? That's it. > 6) 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 > sourcecode types.) The YANG validates. The RFC editor should have access to our xml. A github repository for our documents is also available, if helpful > 7) This document is part of Cluster 562. Note that it may be helpful to include draft-ietf-bfd-optimizing-authentication in the same cluster. The secure sequence numbers draft implements procedures covered in that draft. > * 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. I would recommend that the editor be familiar with the draft-ietf-bfd-stability draft, and that editor may wish to be familiar with optimizing authentication and secure sequence numbers. However, aside from familiarity for editorial consistency, there's no technical requirement that the stability draft be part of this cluster. > * 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)? Usage of "meticulous authentication" should be reviewed for consistency. Document review has suggested that this terminology that originated in RFC 5880 was not clearly specified and was causing confusion in the documents for this cluster. > 8) Would you like to participate in the RPC Pilot Test for editing in > kramdown-rfc? The documents are in XML format so I suspect this isn't applicable to us? > 9) Would you like to participate in the RPC Pilot Test for completing AUTH48 > in > GitHub? If so, please let us know. For more information about this experiment, The primary editors for these documents already leverage github and would probably be fine with driving review via github. However, some of the authors have drifted away from IETF as their primary work and may not be as responsive there. I leave it to the RPC's discretion as to how this mix of author interaction should motivate github review. -- Jeff -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
