Hi Jeff,

Please check inline below for responses.


On Wed, Jun 4, 2025 at 9:04 PM Jeffrey Haas <[email protected]> wrote:

> Ketan,
>
>
> > On Jun 4, 2025, at 11:05 AM, Ketan Talaulikar <[email protected]>
> wrote:
> >
> > 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.
>
> As am I.
>
> >
> > Jeff (I guess?) is talking about the BFD YANG module from RFC 9127.
>
> The maintained module was defined in RFC 9127, §2.12.  Any content
> additions to that module maintained by IANA cover the fact that it was
> defined in RFC 9127 under one set of prior maintenance rules.  The fact
> that you're not understanding that point suggests you should review RFC
> 9127.
>
> The landscape has changed.  That's fine.  Participants in netmod will
> likely recall I raised issues about how maintenance works some time ago.  I
> find the updates in 8407-bis to be reasonable for new modules.  Their
> homework for how those rules are enforced on previously created modules is
> not done. Their procedures for what a maintenance request needs to look
> like needs improvement.  Ideally Med and Mahesh will proxy those points
> toward their last call inputs.
>

KT> Well, it is on the IESG telechat for tomorrow.  You are welcome to
check my ballot on that here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ballot/ ...
and I am copying this specific point that I already raised below. So, when
I suggest you bring this up on netmod, it is because that is the right
forum to discuss/debate this and similar points.

3196 4.30.3.  Guidance for Writing the IANA Considerations for RFCs Defining
3197         IANA-Maintained Modules

<major> What is missing is guidance for future documents (i.e. not RFC IIII)
that allocate code points from a registry that is associated with an
IANA-maintained YANG module. I guess the instruction for such a document is
to
not give any specific instruction related to such a module (e.g., don't try
to
repeat the updated module in appendix or such?) - all of this should be
taken
care of by IANA automatically based on instructions provided in RFC IIII ?


>
> > However, Jeff, if you are talking about the following from my email, then
> > please take it to the netmod list :-)
>
> Not if I can help it.  My personal goal here is "tell us what text to
> paste in the drafts to make the YANG issues go away at the IESG level".
> I'm telling you that your requests are not sufficiently clear or traceable
> to what you're trying to RFC in netmod as the new requirements.
>
> Frankly, send patches.  All drafts are in github.
>

KT> I have already shared here (
https://mailarchive.ietf.org/arch/msg/rtg-bfd/i1azBBa5dfkZhn14myORsWDMF7o/)
at the start of this thread on what needs to be done. I believe that is
clear enough.

Thanks,
Ketan


>
> Alternatively, if we're hung up in YANG process hell, simply deleting the
> YANG modules in these drafts remains an option.  However, the issues
> identified in this thread remain ones that need to be dealt with and will
> impact other IANA maintained modules that are operating under prior
> boilerplate.  BFD just has had the misfortune to trip across those issues.
>
> -- Jeff
>
>

Reply via email to