É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
