Hi Jeff, Thank you for your response!
A) Regarding: > 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. A second response would be excellent! B) Regarding: >> 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? Sounds good -- we'll stick with XML, then. C) Regarding: >> 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. Understood! We'll stick with the usual email process so that the review process is simpler. Sincerely, Sarah Tarrant RFC Production Center > On Nov 13, 2025, at 11:12 AM, Jeff Haas <[email protected]> wrote: > > 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]
