Hi Eric, On the same lines as your concern on the draft-ietf-bfd-secure-sequence-numbers, I am assuming that your concerns in this document are related to the Appendix B. I have the following suggestions for the authors:
OLD: This document describes an experiment that presents a candidate solution to update BFD Authentication that is currently specified in [RFC5880 <https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-35.html#RFC5880> ]. NEW: This document describes an experiment that presents a candidate solution to extend BFD Authentication that is currently specified in [RFC5880 <https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-35.html#RFC5880> ]. Please let us know if there is anything else that is missed. I hope this helps progress the document. Thanks, Ketan On Tue, Oct 14, 2025 at 11:20 AM Ketan Talaulikar <[email protected]> wrote: > Hi Eric, > > The authors have pushed the v35 of this document with several updates > including those that should clarify your DISCUSS and comments. Could you > please check the same and we can progress the discussion? > > Thanks, > Ketan > > > On Tue, Aug 26, 2025 at 7:09 PM Jeffrey Haas <[email protected]> wrote: > >> Éric, >> >> >> > On Aug 26, 2025, at 8:42 AM, Eric Vyncke (evyncke) <[email protected]> >> wrote: >> > EV> while I welcome reusing code & procedure, I would err on the >> “update” side (even for an experimental draft updating a PS one). To be >> discussed at the IESG telechat next week. >> > >> As a final attempt to nudge you that this is not an update, the >> "reserved" field is left intact and unaltered for existing code points. >> > > ### Section 7.1 >> > >> > > >> > > The text is about OptMode being 1 or 2 while the previous section >> introduced >> > > these values with "For example" and restricting it to MD-5-related >> > > authentication. It is either an example (like section 7) or normative >> (like >> > > section 7.1). >> > >> > Was this sentence unclear in the procedure? >> > "The following common procedures apply to authenticating BFD Control >> packets utilizing Optimized Authentication:" >> > >> > >> > EV> actually, after re-re-reading sections 7 & 7.1, I would suggest: s/ >> For example, for Auth Type "Optimized MD5 Meticulous Keyed ISAAC >> Authentication" (type TBD):/ For example, for Auth Type "Optimized MD5 >> Meticulous Keyed ISAAC Authentication" (section 7.1 of this document):/ >> > >> > EV> and consider this point as a non-blocking COMMENT >> > >> >> The comments here and immediately afterword from you regarding what's >> intended to be an example rather than normative behavior suggest the >> simplest answer is to completely delete the example. The procedures are >> adequately covered in the secure sequence numbers document. I believe this >> reduces clarity of the motivation of the procedures in this document, but >> am unwilling to waste more cycles resolving the circular dependencies these >> documents have had. >> >> I have deleted this in the staged changes. >> >> > >> > > ### Section 9 >> > > >> > > Even more critical, there is no request to the IANA to allocate the >> `TBD` >> > > authentication type in >> > > >> https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2 >> > >> > As Ketan notes, the request is in the secure sequence numbers >> document. The need here is for the RFC Editor to keep the two document >> synchronized. >> > >> > EV> we disagree 😊 >> > >> > EV> rather than using “TBD” you need to add a RFC Editor note to >> replace all “TBD” by the actual value once known >> > >> > EV> *AND* add a normative reference to the secure-seq-number I-D the >> first time this TBD is used. >> >> See above. >> >> > >> > EV> I agree with you, let’s simply remove the sentence about future >> crypto algos >> >> I find it heavy-handed, but will do so as a pragma to silence the IESG >> warning. >> >> > EV> after reading your comment above, I dig further and indeed ISAAC >> does not seem to be an acronym. It also makes me wonder about the choice of >> this algo. Curious to read the SEC ADs views. >> >> That's where the real fun for these documents will be no matter what. >> >> >> -- Jeff >> >>
