Gorry Fairhurst has entered the following ballot position for draft-ietf-bfd-optimizing-authentication-35: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for preparing this I-D, and amending the abstract. I have the following comments which I hope will help revise this I-D. ### 1. Thank you to Marcus Ihlar for his TSV-ART review, see: https://datatracker.ietf.org/doc/review-ietf-bfd-optimizing-authentication-28-tsvart-lc-ihlar-2025-08-18/ As noted in the reviwe, could the editors please add a short discussion on loss and reauthentication in Section 5, or in an Operational Considerations section? ### 2. The I-D text ought to say why the document is experimental, please could you add to the Introduction by citing the Appendix that explains this. ### 3. The I-D currently states: "All BFD Control Packets with the states AdminDown, Down, and Init require strong authentication." - could this be a RFC-2119 requirement? Please consider making this a nomative case for this I-D , i.e. make this "REQUIRES", or the REQUIRES in the following: "In addition to these requirements, BFD "significant changes" require strong authentication." ### 5. The I-D currently states: "When using the less computationally intensive authentication mechanism, BFD should periodically test the session using the strong authentication mechanism." - I'd agree, but I do think the text needs to explain why this is desirable, i.e. to justify why people SHOULD think seriously about enabling this test. ### 6. The I-D currently states: "Once enabled, every packet must have Authentication Bit set and the associated Authentication Type appended." - Please cit the section here, I could not be sure what was cited? ### 7. The I-D currently states: "As a security precaution, it mentions that authentication state be allowed to change at most once" Whereas, RFC 5880 use RFC-2119 text: "In order to avoid security risks, implementations using this method SHOULD only allow the authentication state to be changed at most once without some form of intervention." - Could this RFC 5880 text be quoted as-is, in the current I-D (with a reference?) ### NiTs ==== /It provides procedure where BFD state/It provides a procedure where BFD state/ /describes enabling and disabling/describe enabling and disabling/ /authentication state be allowed to change at most once/the authentication state be allowed to change at most once/
