[Speaking as an author]
> On May 19, 2026, at 20:05, [email protected] wrote: > > 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 This works. > > Perhaps: > A YANG Data Model for Optimizing Bidirectional Forwarding > Detection (BFD) Authentication > --> As Reshad already noted, it's not appropriate. If there's some standing pattern for RFC naming that indicate "... and includes YANG!" we could consider that. > > > 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. > --> Please revert to [email protected]. I work primarily from my personal account for IETF purposes because O365/Exchange/Outlook suck for IETF work. :-) However, my primary contact for drafts will be my sponsor's email. > > > 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. > --> DL format is acceptable. > > > 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. > --> The clarification of the pronoun is correct. The pronoun was used because the long citation became repetitive. I'm fine with your expert opinion about how to best remove the ambiguity, if any. > 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. > --> This works. > 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. > --> Your update is clearer. The Original format in numbered list format doesn't clearly reflect the intent that would have been clearer if it had been "1, when..." > 7) <!-- [rfced] Should the following text be formatted as a list as shown > below? In general, this is acceptable. However, it varies in style from the one mimicked in RFC 5880 section 6.1. I leave the decision as to whether preserving style across the related documents to your discretion. > 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. > --> I agree this is better English. > > 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]. > --> This is a stale reference from prior document changes and can be removed. > 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. > --> Mahesh will have better commentary on the format. > 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. > --> This is still a bit of a word salad (and my fault). Providing the entire paragraph for context with edits (and requires approval from at least one other coauthor for logic review): When the BFD state machine is in the Up state, the LCI authentication mechanism is intended to provide resistance to keeping a BFD session in the Up state inappropriately. Since the procedures for changing BFD state require utilizing 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. "Utilizing", along with splitting the conjunctive phrases, is the intended clarification. > > 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]. > --> That's fine. > > > 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? > --> For these references, my suggestion would be to query the security ADs for their preferred citations. > 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 > ^ > --> Mahesh should comment on these. My guess for the xmllint issue is that a set of dependent modules is not supplied for validation. > > > 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. > --> This is better, thanks. > > > 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. > --> This looks fine to me. I'd appreciate a second set of eyes to review this. > 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. > --> The author comments may be removed. > 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. > --> I see nothing in the diff that looks wrong. > > 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. > --> I believe there is nothing applicable here. > 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. Mahesh should review the uses here. > 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 I see no BFC? > BFD Authentication vs. BFD authentication > Poll sequence vs. poll sequence > Single Hop BFD vs. single hop BFD > Detection Time vs. detection time The general preference is for style consistency vs. RFC 5880. Unfortunately even that document doesn't offer a high level of consistency for capitalization. Would you please provide your assessment of what you think the most consistent form would be with that as the criteria? > > 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]). > --> The Perhaps is more correct. -- Jeff
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
