Re-, Why should only a subset of us have to pay that netmod penalty? Sharing the pain ;-)
More seriously, thanks for the suggestions. Some of them are work-in-progress, while there are already tools for automatically generate a YANG module from a registry. I still don't think that you need to supply the updated IANA module in your specific case. Adding entries to the registry would suffice as I said. You have already all in place to reflect the new values in the module: Note Updates to this registry must be mirrored in YANG module [iana-bfd-types]. See [RFC9127]. Cheers, Med De : Jeffrey Haas <jh...@pfrc.org> Envoyé : mercredi 4 juin 2025 16:48 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Ketan Talaulikar <ketant.i...@gmail.com>; draft-ietf-bfd-secure-sequence-numb...@ietf.org; draft-ietf-bfd-optimizing-authenticat...@ietf.org; draft-ietf-bfd-stabil...@ietf.org; rtg-bfd@ietf. org <rtg-bfd@ietf.org>; ops-ads <ops-...@ietf.org> Objet : Re: AD review follow-up for YANG organization related aspects for the 3 BFD documents 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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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 <jh...@pfrc.org<mailto:jh...@pfrc.org>> Envoyé : mercredi 4 juin 2025 15:53 À : Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Cc : draft-ietf-bfd-secure-sequence-numb...@ietf.org<mailto:draft-ietf-bfd-secure-sequence-numb...@ietf.org>; draft-ietf-bfd-optimizing-authenticat...@ietf.org<mailto:draft-ietf-bfd-optimizing-authenticat...@ietf.org>; draft-ietf-bfd-stabil...@ietf.org<mailto:draft-ietf-bfd-stabil...@ietf.org>; rtg-bfd@ietf. org <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>; ops-ads <ops-...@ietf.org<mailto:ops-...@ietf.org>> 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 <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 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. ____________________________________________________________________________________________________________ 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.
