As a lot of ‘controversial’ text has been removed (notably in section 7), I will shortly clear my DISCUSS.
Regards -éric From: Ketan Talaulikar <[email protected]> Date: Tuesday, 14 October 2025 at 10:29 To: Eric Vyncke (evyncke) <[email protected]> Cc: Jeffrey Haas <[email protected]>, The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, rtg-bfd@ietf. org <[email protected]>, Reshad Rahman <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-optimizing-authentication-29: (with DISCUSS and COMMENT) 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]<mailto:[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]<mailto:[email protected]>> wrote: Éric, > On Aug 26, 2025, at 8:42 AM, Eric Vyncke (evyncke) > <[email protected]<mailto:[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
