Med, The comments here are addressed in this pending github pull request: https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/49
> On Sep 4, 2025, at 4:16 AM, [email protected] wrote: > Thanks for the follow-up and confirming that you will also take care of Ace's > comments. I'll respond to that one in its own thread. As best I can tell, Acee's review didn't make it outside of the yang-doctors list. If it did, I'm unable to find it in my inbox. > > This looks good to me. > > As the module will be kept here, please consider these comments as well: > > # Use a consistent prefix pattern as for already defined BFD modules: bfd-mka bfd-mki was chosen to address Acee's comment. > > The prefix is also better aligned with ietf-bfd-met-keyed-isaac > > # References in the module should be called in the narrative text > > CURRENT: > "RFC 8177: YANG Data Model for Key Chains."; > > You can consider adding this sentence right before the module: > > NEW: > The module imports the "ietf-key-chain" module [RFC8177]. I've chosen to go with: This YANG module adds two identities defined in this - document. One of them uses the Meticulous Keyed MD5 as the + document to the <xref target="RFC8177">IETF Keychain Model</xref>. + One of them uses the Meticulous Keyed MD5 as the > > # Tweak this description as we don't have the concept of "experimental yang > modules" > > OLD: > "This experimental YANG module provides identities derived from > the ietf-key-chain model for the BFD Meticulous Keyed ISAAC > authentication mechanism. > > NEW > "This YANG module provides identities derived from > the ietf-key-chain module for the experimental BFD Meticulous Keyed ISAAC > authentication mechanism. Done. > > # Delete this part from Section 13 > > CURRENT: > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', > 'MAY', and 'OPTIONAL' in this document are to be interpreted as > described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, > they appear in all capitals, as shown here. Done. > > # Update all reference to match the document title > > OLD: > "RFC XXXX: Meticulous Keyed ISAAC for BFD Authentication."; > > NEW: > "RFC XXXX: Meticulous Keyed ISAAC for BFD Optimized Authentication"; > Done. > # 14.3 > > OLD: > name: ietf-bfd-met-keyed-isaac > namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac > prefix: bfdmia > reference: RFC XXXX > > NEW: > name: ietf-bfd-met-keyed-isaac > namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac > prefix: bfd-mka > maintained by IANA? N > reference: RFC XXXX Done, but using the alternative prefix noted above. > > # Please add a new section to cover the security consideration of the module. > The template is provided in RFC8704bis. Done as part of addresing Acee's review. > > Cheers, > Med > >> -----Message d'origine----- >> De : Jeffrey Haas <[email protected]> >> Envoyé : mercredi 3 septembre 2025 20:13 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]> >> Cc : The IESG <[email protected]>; draft-ietf-bfd-secure-sequence- >> [email protected]; [email protected]; rtg-bfd@ietf. org <rtg- >> [email protected]>; Reshad Rahman <[email protected]>; Reshad Rahman >> <[email protected]> >> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-bfd-secure- >> sequence-numbers-24: (with DISCUSS) >> >> >> Med, >> >> Brief followup: >> >>> On Sep 3, 2025, at 10:19 AM, Mohamed Boucadair via Datatracker >> <[email protected]> wrote: >>> >>> # DISCUSS >>> >>> I don’t understand the need for the YANG module as these >> identities >>> are also defined in draft-ietf-bfd-optimizing-authentication. >>> >>> Any reason why this is defined? >> >> Its presence in the optimizing authentication document is an error >> and it should be removed from there. >> >> As the IESG has likely noted by now, the YANG considerations for >> these three documents have some dependencies that were challenging >> to untangle. The location of the contents of particular bits of >> YANG have moved around significantly during the development of >> these documents. >> >> Acee's other comments should be addressed soon. >> >> -- Jeff > > ____________________________________________________________________________________________________________ > 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.
