Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] We have updated the title of the document to expand "BFD". Also, note that RFCs containing YANG usually follow the pattern of "A YANG Data Model for <Foo>". Given this, please let us know if/how the title may be further updated. Original: Optimizing BFD Authentication Current: Optimizing Bidirectional Forwarding Detection (BFD) Authentication Perhaps: A YANG Data Model for Optimizing Bidirectional Forwarding Detection (BFD) Authentication --> 2) <!--[rfced] Jeffery, we updated your email address to "[email protected]". Your affiliation is listed "HPE"; please let us know if an update is needed or if this is okay as is. --> 3) <!-- [rfced] Would you like to use a definition list format for the terminology listed in Section 2 as opposed to a table? See one example entry below. Perhaps: significant change: A state change, demand mode change (to D bit), or poll sequence change (P or F bit). Changes to BFD control packets that do not require a poll sequence, such as bfd.DetectMult, are also considered a significant change. --> 4) <!-- [rfced] What does "it" refer to in the sentence below? Current: In addition, it states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD control packet. Perhaps: In addition, Section 6.7.1 of [RFC5800] states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD control packet. --> 5) <!-- [rfced] May we rephrase the third bullet point in this list for improved readability in relation to the lead-in sentence? Current: This pairing is advertised in a single Auth Type value in order to permit implementations to be aware that: * Optimized BFD procedures will be in use. * The pairing of the MCI and LCI authentication mechanisms will be used for that session. * The requirement to carry a Sequence Number. * The current MCI or LCI mode will be carried as described below: Perhaps: This pairing is advertised in a single Auth Type value in order to permit implementations to be aware that: * Optimized BFD procedures will be in use. * The pairing of the MCI and LCI authentication mechanisms will be used for that session. * There is a requirement to carry a Sequence Number. * The current MCI or LCI mode will be carried as described below. --> 6) <!-- [rfced] We are unable to parse the following text. May we rephrase for clarity? Original: The values of the Optimized Authentication Mode field are: 1. When using the more computationally intensive authentication type for optimized BFD Auth Types. 2. When using the less computationally intensive authentication type for optimized BFD Auth Types. Perhaps: The values of the Optimized Authentication Mode field are: 1. The MCI authentication type for optimized BFD Auth Types. 2. The LCI authentication type for optimized BFD Auth Types. --> 7) <!-- [rfced] Should the following text be formatted as a list as shown below? Original: The following common procedures apply to authenticating BFD Control packets utilizing Optimized Authentication: If the received BFD Control packet does not contain an Authentication Section ([RFC5880], Section 4.1), or the Auth Type is not a supported Optimized Authentication Auth Type, then the received packet MUST be discarded. If the received BFD Control packet contains an optimized authentication type using these procedures and the Optimized Authentication Mode field is not 1 or 2, then the received packet MUST be discarded. If bfd.SessionState is AdminDown, Down, or Init and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded. If bfd.SessionState is Up and there is a significant change as defined in Section 3.1, and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded. If the Auth Len field is not equal to a value appropriate for the Optimized Authentication Mode field, the packet MUST be discarded. If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. Perhaps: The following common procedures apply to authenticating BFD Control packets utilizing Optimized Authentication: * If the received BFD Control packet does not contain an Authentication Section ([RFC5880], Section 4.1), or the Auth Type is not a supported Optimized Authentication Auth Type, then the received packet MUST be discarded. * If the received BFD Control packet contains an optimized authentication type using these procedures and the Optimized Authentication Mode field is not 1 or 2, then the received packet MUST be discarded. * If bfd.SessionState is AdminDown, Down, or Init and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded. * If bfd.SessionState is Up and there is a significant change as defined in Section 3.1, and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded. * If the Auth Len field is not equal to a value appropriate for the Optimized Authentication Mode field, the packet MUST be discarded. * If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. --> 8) <!-- [rfced] May we rephrase the sentence below for clarity and easier readability? Original: If the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space) the received packet MUST be discarded. Perhaps: If the sequence number lies outside of the inclusive range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) when treated as an unsigned 32-bit circular number space, the received packet MUST be discarded. --> 9) <!-- [rfced] RFC 8177 doesn't appear to be referenced in the YANG Module. Please review and let us know if/how we should update the module or if this reference should be removed. Current: This YANG module imports modules defined in YANG Data Model for Key Chains [RFC8177], A YANG Data Model for Routing Management (NMDA Version) [RFC8349], and YANG Data Model for Bidirectional Forwarding Detection (BFD) [RFC9314]. --> 10) <!--[rfced] The YANG module (Section 8.3) has been updated as shown below per the formatting option of pyang. Please let us know of any concerns. - Removed the quote marks from prefixes "bfd-oa" and "rt". - Moved the plus signs and slashes to the beginning of the lines within in the augment blocks. --> 11) <!-- [rfced] May we rephrase the following sentence to avoid repetition of "contents"? Current: Since the procedures for changing BFD state require the more computationally intensive mechanism and the less computationally intensive mechanism requires that the contents of the Control Packet in the Up state not change its contents, the only thing that successfully spoofing such packets can do is keep the session Up. Perhaps: Since the procedures for changing BFD state require the MCI mechanism and the LCI mechanism requires that the contents of the Control Packet in the Up state remain unchanged, the only thing that successfully spoofing such packets can do is keep the session Up. --> 12) <!-- [rfced] FYI - We have updated the following text to point to Section 3.7.1 instead of Section 3.7 in order to match the Security Considerations Section Template as shown in RFC 9907. Original: This section is modeled after the template described in Section 3.7 of [I-D.ietf-netmod-rfc8407bis]. Current: This section is modeled after the template described in Section 3.7.1 of [RFC9907]. --> 13) <!-- [rfced] References a) For [SHA-1-attack1]: We found an open access version of this paper: https://link.springer.com/chapter/10.1007/11535218_2. May we update this reference to point to this version? Current: [SHA-1-attack1] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Full SHA-1", 2005. Perhaps: [SHA-1-attack1] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Full SHA-1", Advances in Cryptology - CRYPTO 2005, Lecture Notes in Computer Science, vol. 3621, pp. 17-36, DOI 10.1007/11535218_2, 2005, <https://doi.org/10.1007/11535218_2>. b) For [SHA-1-attack2]: We were unable to find a source that matched this reference's information. We did find a presentation for the NIST Cryptographic Hash Workshop from the authors listed in this reference: https://csrc.nist.gov/csrc/media/events/first-cryptographic-hash-workshop/documents/wang_sha1-new-result.pdf. Is there a specific paper this reference is supposed to be pointing to? Or is this presentation the correct source? --> 14) <!--[rfced] Appendix A a) FYI: We added the following sentence to Appendix A.1 with a corresponding reference entry for RFC 8792 in the Informative References section. Original: This example demonstrates how a Single Hop BFD session can be configured for optimized authentication. Current: This example demonstrates how a Single Hop BFD session can be configured for optimized authentication. Note that line wrapping is used per [RFC8792]. b) When running xmllint on the XML schema, we received the following error. Are any changes needed to the schema, or is it ok as is? Error: Extra content at the end of the document <interfaces ^ --> 15) <!-- [rfced] Is the following intended to be a list of 3 items? Please let us know how we may update for clarity. Current: Since then, there has been considerable changes to the document, e.g., the use of ISAAC, allowing for ISAAC bootstrapping when a BFD session comes up and use of a single Auth Type to indicate use of optimized authentication etc. Perhaps: Since then, there have been considerable changes to the document, such as the use of ISAAC, the allowance for ISAAC bootstrapping when a BFD session comes up, and the use of a single Auth Type to indicate optimized authentication. --> 16) <!-- [rfced] We updated <artwork> to <sourcecode> in several sections. Please review and confirm that this is correct. In addition, please consider whether the "type" attribute of any sourcecode element has been set correctly. The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 17) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> 18) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Additionally, some expansions in the document have been abbreviated after they are introduced. Please review each expansion in the document carefully to ensure correctness. --> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> 20) <!-- [rfced] Terminology a) We have received guidance from Benoit Claise and the YANG Doctors that "YANG module" and "YANG data model" are preferred. We have updated the text to use these forms. Please review. b) We note that the following terms are used inconsistently. Please review and let us know which form you prefer to use throughout the document for consistency. If there are no objections, we will use the form on the right. BFC Control Packet vs. BFD Control packet vs. BFD control packet BFD Authentication vs. BFD authentication Poll sequence vs. poll sequence Single Hop BFD vs. single hop BFD Detection Time vs. detection time c) Are the terms "Authentication Present (A) bit" and "Authentication Bit" referring to two different things? If they are used interchangeably, may we update as follows to match Section 4.1 of RFC 5880? Original (Authentication Present (A) bit): When the Authentication Present (A) bit is set and the Auth Type ([RFC5880], Section 4.1) is a type supporting Optimized BFD Authentication, the Auth Type signals a pairing of an MCI authentication type and an LCI authentication type. Original (Authentication Bit): Once enabled, every packet must have the Authentication Bit set and the associated Authentication Type appended (Section 4.1 of [RFC5880]). Perhaps (Authentication Bit): Once enabled, every packet must have the Authentication Present (A) bit set and the associated Authentication Type appended (Section 4.1 of [RFC5880]). --> Thank you. Madison Church and Karen Moore RFC Production Center On May 19, 2026, at 5:03 PM, RFC Editor via auth48archive <[email protected]> wrote: *****IMPORTANT***** Updated 2026/05/19 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9985.xml https://www.rfc-editor.org/authors/rfc9985.html https://www.rfc-editor.org/authors/rfc9985.pdf https://www.rfc-editor.org/authors/rfc9985.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9985-diff.html https://www.rfc-editor.org/authors/rfc9985-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9985-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9985 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9985 (draft-ietf-bfd-optimizing-authentication-36) Title : Optimizing BFD Authentication Author(s) : M. Jethanandani, A. Mishra, J. Haas, A. Saxena, M. Bhatia WG Chair(s) : Jeffrey Haas, Reshad Rahman Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
