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 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/
> <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
>
> <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#section-6.4>
> https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-24.html#name-updated-bfd-iana-module
>
> <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
>
> <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.
