[Adding Sandy Ginoza]

Hi Rob,

> On Dec 16, 2025, at 9:32 AM, Rob Wilton (rwilton) <[email protected]> wrote:
> 
> Hi,
> 
> One of the outcomes of the meeting between the folks doing YANG versioning 
> and IANA was a request to have clearer long-term guidance for IANA's 
> processing of YANG modules.  In some of the feedback from Mahesh the 
> suggestion was that this should also incorporate guidelines for the RFC 
> Editor when processing YANG modules as well.
> 
> Hence this document.  At this stage, still document is still somewhat 
> rough/early (but verbose because an LLM helped produce most of the initial 
> text based on my guidance), and hasn't had that much review yet.
> 
> So, I think that the key questions are whether this is the sort of 
> information//guidance/format that you are looking for?  Does the rough 
> structure and level of detail seem right, or too much or too little?  If we 
> can please get some early feedback on whether this doc is on the right track 
> or if we should be making some larger restructuring before the next version.

My general comment with the current version of the draft is that already does a 
good job of capturing a lot of the guidance. I would be ok with adopting the 
draft, even as we work to update the draft.

Take as an example, Section 5.2.2, Step 2, RFC Editor Processing. It calls for 
coordination with document authors on any "substanive changes". But there is no 
definition of what are “substantive changes”. Can that be articulated? Is it 
anything outside of the 4 bullet items listed in the section? The document 
refers to Section 4 to determine version numbering, but there is no use of the 
term “substantive changes” in that section.  How should the RFC Editor manage 
the version number for both the “substantive changes” and non-“substantive 
changes”?

Also, thanks for mentioning Appendix A.1.1.  and that pyang can be used in 
determining BC or NBC changes. 

The document assumes publication of a new YANG module. How about a -bis version 
that is still an I-D? What version number should authors use?

> 
> Mahesh, you mentioned that the RFC Editor would also be interested, who would 
> be the best contact please, Alexis?

I have added Sandy to the thread. She and I discussed the changes the three 
drafts will be bringing and she had a few questions. I will let her take a look 
at the current version of the draft and compare it to her notes to see what 
could be added to the draft.

Thanks

> 
> NETMOD chairs, I think that you mentioned adopting this directly.  Let me 
> know whether you think that this doc is ready to be adopted, or I should get 
> a round of reviews first, or ...
> 
> Just for the formal record:  I’m not aware of any IPR that applies to this 
> draft.
> 
> Kind regards,
> Rob
> 
> 
> 
> From: [email protected] <[email protected]>
> Date: Tuesday, 16 December 2025 at 16:42
> To: Rob Wilton (rwilton) <[email protected]>
> Subject: New Version Notification for draft-verdt-iana-yang-guidance-00.txt
> 
> A new version of Internet-Draft draft-verdt-iana-yang-guidance-00.txt has been
> successfully submitted by Robert Wilton and posted to the
> IETF repository.
> 
> Name:     draft-verdt-iana-yang-guidance
> Revision: 00
> Title:    Guidance for Managing YANG Modules in RFCs and IANA Registries
> Date:     2025-12-16
> Group:    Individual Submission
> Pages:    40
> URL:      
> https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-verdt-iana-yang-guidance/
> HTML:     
> https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-verdt-iana-yang-guidance
> 
> 
> Abstract:
> 
>    This document provides guidance to the RFC Editor and IANA on
>    managing YANG modules in RFCs and IANA registries, ensuring
>    consistent application of YANG Semantic Versioning rules.
> 
> 
> 
> The IETF Secretariat
> 
> 


Mahesh Jethanandani
[email protected]






_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to