Issues in this mail are addressed in this github pull request: https://github.com/bfd-wg/optimized-auth/pull/74
-- Jeff > On Sep 3, 2025, at 9:59 AM, Mohamed Boucadair via Datatracker > <nore...@ietf.org> wrote: > # Confusing note > > CURRENT: > RFC XXXX, where XXXX is the number assigned to this document at the > time of publication. > > Please note that you are using RFC XXXX to refer to two distinct documents: > > "RFC XXXX: Optimizing BFD Authentication."; > > and > > "RFC XXXX: Meticulous Keyed ISAAC for BFD Authentication."; This was cleared by removing the errant identities that now only live in the secure sequence numbers document. > # Redundant behavior > > Section 3 > The contents of an Up packet MUST NOT change aside from the > Authentication Section without strong authentication. > > Vs. > > Section 6: > In this specification, the contents of an Up packet MUST NOT change > aside from the Authentication Section without strong authentication. > > Keep the normative language in one place. The text serves as an emphasis on the procedures and I suggest keeping each of the instances. > > # Not only for configuration but also for state reporting > > Section 8.1 > > OLD: > The YANG 1.1 [RFC7950] model defined in this document augments the > "ietf-bfd" module to configuration relevant to the management of > the feature defined in this document. > > NEW: > The YANG 1.1 [RFC7950] model defined in this document augments the > "ietf-bfd" module to add data nodes relevant to the management of > the feature defined in this document. Accepted. > > # Add identities, not algos per se > > Section 8.1 > > OLD: > In particular, it adds crypto > algorithms that are described in this model, and in Meticulous Keyed > ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers]. > > NEW: > In particular, it adds identities for crypto > algorithms that are described in this model, and in Meticulous Keyed > ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers]. > Accepted. > # Feature > > Consider this change in Section 8.1 > > OLD: > It adds a feature statement to enable optimized authentication. > > NEW: > It adds a feature to indicate optimized authentication. Accepted. > > # YANG terminology > > CURRENT: > This YANG module imports YANG Key Chain [RFC8177], A YANG Data Model > for Routing Management (NMDA version) [RFC8349], and YANG Data Model > for Bidirectional Forwarding Detection (BFD) [RFC9314]. > > This should reason about importing the various modules, not data models. > Please > refer to 8407bis which says: > > “Likewise, "YANG module" should be used when using terms related to YANG > module > specifications (e.g., augmentation or deviation).“ > I suspect this comment is incorrect. Each of the points of complaint are the title of the RFC in question. :-) > # Consistency > > Section 8.3 has: > > CURRENT: prefix "bfdoa"; > > I suggest to be consistent with the pattern used so far for BFD (bfd-ip-mh, > bfd-ip-sh, bfd-lag, etc.). > > NEW: prefix bfd-oa; Changed in prior push. > > # Feature Description > > OLD: > description > "When enabled, this implementation supports optimized > authentication as described in this document."; > > NEW: > description > "Indicates that the implementation supportkkks optimized > authentication."; Accepted. > > Please note also that the module will live outside the document. You may add a > reference statement. Accepted. However, this seems deeply redundant since it's a feature statement that is scoped to a module that already contains this reference. > > # Redundant default statement > > OLD: > default "60"; > description > "Interval of time after which strong authentication > should be utilized to prevent an on-path-attacker attack. > Default is 1 minute. > > NEW: > default "60"; > description > "Interval of time after which strong authentication > should be utilized to prevent an on-path-attacker attack. Accepted. > > # Not maintained by IANA > > OLD: > name: ietf-bfd-opt-auth > namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth > prefix: bfdoa > reference: RFC XXXX > > NEW: > name: ietf-bfd-opt-auth > namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth > prefix: bfd-oa > maintained by IANA? N > reference: RFC XXXX Ah, shifting sands for templates. I've done "maintained by IANA: No". See diff. > > # Security template > > Please update 10.2 to follow the template in RFC8407bis. I've done so. Given that the template isn't fully genericized, please check the implemented.
