Hi Jeff,
Per 8407bis, it is recommended that this note is used when an IANA-maintained
module is associated with a registry:
==
IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry.
==
The key point is that once we initialized such a module, registration actions
will be automatically mirrored in the module. Registrants do not even need to
know that such module exist.
So, I'm supportive of Ketan's comment below.
Cheers,
Med
De : Jeffrey Haas <[email protected]>
Envoyé : mercredi 4 juin 2025 15:53
À : Ketan Talaulikar <[email protected]>
Cc : [email protected];
[email protected];
[email protected]; rtg-bfd@ietf. org <[email protected]>;
ops-ads <[email protected]>
Objet : Re: AD review follow-up for YANG organization related aspects for the 3
BFD documents
Ketan,
On Jun 4, 2025, at 3:12 AM, Ketan Talaulikar
<[email protected]<mailto:[email protected]>> wrote:
I got myself educated (a little bit) on the YANG modeling guidelines as part of
the IESG review of
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/
:-)
Following are some YANG organization specific comments on each of the 3
documents.
1) For draft-ietf-bfd-secure-sequence-numbers
a)
https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-24.html#section-6.1
has to be moved from that document into the IANA considerations of this
document. This IANA registry feeds into an IANA maintained YANG module that
needs to be self-contained in this document where those two types are actually
specified.
That's "fine". In prior iterations of the secure sequence number docs, the
references to how ISAAC required the optimized procedures was less clear and
thus ownership of the things supporting optimized made sense in the parent
document rather than the child documents.
2) For draft-ietf-bfd-optimizing-authentication
a) The following sections need to be deleted (i.e., they have no place in any
of these documents) because they refer to an IANA maintained YANG module
https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-24.html#section-6.4
https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-24.html#name-updated-bfd-iana-module
b) For the YANG Model in
https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-24.html#section-5.3
there are two options:
i) It can be split so the main part related to optimized auth remains in this
document and the part specific to the two ISAAC auth types is moved into
draft-ietf-bfd-secure-sequence-numbers. IMHO this would be the correct and
modular way to develop YANG modules.
Sorry, go check with your ops ADs again. Have we developed a procedure by
which more than one document pre-publication can update the same IANA module?
If so, please supply a reference to the current draft/RFC that details how to
do so.
OR
ii) It can be moved entirely into draft-ietf-bfd-secure-sequence-numbers to
avoid the circular normative reference between these two drafts. This will also
better align with (1) (a). I believe this is what Reshad was suggesting.
That would be acceptable, but largely because 1 works out well enough today.
3) For draft-ietf-bfd-stability - all seems good to me from YANG perspective
Please let me know your thoughts and if you agree, it would be great to get
some draft updates posted so we can start closing off review comments.
Patches addressing the YANG points will be trivial to do.
You have a large backlog of items covering the optimized procedures already
pending to comment on. Since the remaining authors for the optimized draft are
their usual silent selves, I'm tempted to just push the queued items in the
github branch for broader IETF review.
-- 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.
