Hi Jeff,
Thanks for the follow-up and confirming that you will also take care of Ace's
comments.
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
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].
# 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.
# 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.
# 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";
# 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
# Please add a new section to cover the security consideration of the module.
The template is provided in RFC8704bis.
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.
