Hi Jeff, Thanks for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Jeffrey Haas <[email protected]> > Envoyé : jeudi 4 septembre 2025 19:18 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : The IESG <[email protected]>; draft-ietf-bfd-optimizing- > [email protected]; [email protected]; rtg-bfd@ietf. org > <[email protected]>; Reshad Rahman <[email protected]>; Reshad > Rahman <[email protected]> > Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-bfd- > optimizing-authentication-30: (with COMMENT) > > > Issues in this mail are addressed in this github pull request: > https://github.com/bfd-wg/optimized-auth/pull/74 [Med] I would make proposals directly in your PR but I see that one already merged. Consistent with other changes in this doc set, we need to highlight that this is for an experimental feature: OLD: "This YANG module augments the base BFD YANG model to add attributes related to BFD Optimized Authentication. NEW: "This YANG module augments the base BFD YANG model to add attributes related to the experimental BFD Optimized Authentication. > -- Jeff > > > > On Sep 3, 2025, at 9:59 AM, Mohamed Boucadair via Datatracker > <[email protected]> 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. > [Med] ACK > > # 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. [Med] You can keep the instances, but my suggestion was to keep the normative language only once. > > > > > # 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. [Med] ACK > > > > > # 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. [Med] ACK > > > # 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. [Med] ACK. > > > > > # 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. :-) [Med] You can keep the titles but the point is that we don't import RFCs but modules. You can fix this by saying "This YANG module imports modules defined in ...". Thanks. > > > > # 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. [Med] ACK > > > > > # 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. [Med] ACK > > > > > 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. [Med] ACK. > > > > > # 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. [Med] ACK > > > > > # 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. [Med] Thanks. > > > > > # 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. [Med] I suggest we make this change: OLD: Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities: There are no read-only data nodes defined in this model. NEW: There are no particularly sensitive readable data nodes. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
