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 > >
