Allow me to step in to ensure that Med and Jeff are talking about the same thing.
Med is talking only about the IANA maintained module for ietf-bfd-types. Jeff (I guess?) is talking about the BFD YANG module from RFC 9127. However, Jeff, if you are talking about the following from my email, then please take it to the netmod list :-) *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 Thanks, Ketan On Wed, Jun 4, 2025 at 8:17 PM Jeffrey Haas <[email protected]> wrote: > Med, > > And here I was hoping that I could ignore netmod for the rest of the > year. Oh well. The squirming sea of ever changing "how to do YANG in the > IETF" costs me another hour of my life. > > > > On Jun 4, 2025, at 9:58 AM, [email protected] wrote: > > 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. > > > While your intent is to say "see, section 4.30.x.y.z covers the details", > I think this isn't correct. The items here are describing how you author a > new module. We are in the situation that we have a previously registered > module defined in RFC 9127 that doesn't include all of this stuff. > > Certainly one way to address that is to force a -bis on that RFC or at > least something that updates the entirety of the module to include the the > proposed boilerplate in the -bis and thus capture the long term new > maintenance regime. > > That seems like a rather steep penalty for our attempts at small > incremental maintenance. Is that what you're suggesting? > > Failing that, what's needed is acceptable text for the IESG that either > upgrades the existing module, or at the very least permits patching it. I > don't believe any of the text in 8407bis 4.30.* covers such an upgrade > procedure. What are you proposing? And did you want that in one of these > three BFD documents or were you going to require the working group to do > more work to deal with the YANG technical debt the prior procedures have > created? > > It's also worth flagging that 8407-bis section 4.30.3 doesn't really > provide a good example of how to request maintenance. As written, it > effectively requests you supply in plain-text the contents of numerous YANG > fields. A companion to the templates (e.g. 4.30.3.2) for creating the > modules should be an example maintenance request. > > One could observe that the cleanest way to supply all of the inputs is to > simply supply the subset of the module itself in YANG syntax. Using > explicit examples, draft-ietf-bfd-optimizing-authentication Appendix A's > YANG module could simply have excerpted the revision statement the two > additional enums in an appropriate skeleton typedef diagnostic { type > enumeration. > > I do see that 8407bis is providing for mechanisms where code maintains the > registry, such as XSLT. It'd be appropriate for netmod/IANA to put > together a generic script for such maintenance such that the organization > of an IANA registry for the protocol maintains the YANG generically. I.e., > don't create this work for every person you're asking to do YANG. > > -- Jeff > > > > 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]> > 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. > > >
