I’ve been reviewing and found some issues, but I’m limited in my comms ability this week. I do think the new text here clarifies the need to check the next version, but I’ll do a more thorough check and review next week.
Joe — PGP Key : https://www.marcuscom.com/pgp.asc On Mar 18, 2026, at 02:17, Rob Wilton (rwilton) <[email protected]> wrote: Hi Reshad, Thanks. I've tweaked the text a bit further (not in -01, but in the latest on GitHub) to hopefully clarify this a bit further. https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-iana-yang-guidance&url_2=https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.txt Kind regards, Rob From: Reshad Rahman <[email protected]> Date: Tuesday, 17 March 2026 at 17:58 To: Jason Sterne <[email protected]>, Mahesh Jethanandani <[email protected]>, Rob Wilton (rwilton) <[email protected]> Cc: Sabrina Tanamal <[email protected]>, Amanda Baber <[email protected]>, NETMOD WG <[email protected]>, NETMOD Working Group <[email protected]>, Sandy Ginoza <[email protected]> Subject: Re: [netmod] Re: New Version Notification for draft-verdt-iana-yang-guidance-00.txt Hi Rob, Regarding RFC Editor Processing (6.2.2 in latest github), I still believe we should clarify that determining the correct version (and rev:non-backwards-compatible) applies only to a -bis, i.e. to an already published module. Regards, Reshad. On Monday, March 16, 2026 at 02:14:24 PM EDT, Rob Wilton (rwilton) <[email protected]> wrote: Hi Reshad, Sorry for being slow to reply. 1. I've changed the doc to just say that IETF and IANA modules won't use the COMPAT modifier. I think that this means that the IETF will probably limit errata fixes to YANG modules to only the latest published versions. Perhaps when the veloce work is finished they may decide to change this, but for the time being we can probably keep it simple. 2. As to whether we should restate the backwards compatibly rules or just reference. I've kept this as an open issue because I think that it would be good to get more feedback. I've tweaked the text to make it clear that these are just examples, not a definition, and I've cut down the number of examples for each section slightly. 3. Re: "- 5.2.2. Step 2: RFC Editor Processing", I think that the existing text is probably okay, although I intend to go through this section is more detail. 4. I've changed the must to MUST. I intend to publish an updated version of the draft shortly, hopefully before the NETMOD session on Wednesday. The latest GitHub version (HTML) can be found here: https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html The diff of the GitHub version to the previously published version (-00) can be found here: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-iana-yang-guidance&url_2=https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.txt I think that the key bits that I still need to work on before asking IANA & RFC Editor to review again are: 1. Go through and check the text in "6. <https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html#section-6> YANG Modules in Documents Being Published as RFCs<https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html#name-yang-modules-in-documents-b>", in particular taking on Sandy's comments/feedback. 1. More work to update the tool examples (Appendix A), particularly related to latest changes for comparing versions. 2. Some tweaks to the tooling invocations in 7<https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html#section-7>. IANA-Maintained YANG Modules<https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html#name-iana-maintained-yang-module> Kind regards, Rob From: Reshad Rahman <[email protected]> Date: Wednesday, 31 December 2025 at 17:53 To: Jason Sterne <[email protected]>, Mahesh Jethanandani <[email protected]> Cc: Rob Wilton (rwilton) <[email protected]>, Sabrina Tanamal <[email protected]>, Amanda Baber <[email protected]>, NETMOD WG <[email protected]>, NETMOD Working Group <[email protected]>, Sandy Ginoza <[email protected]> Subject: Re: [netmod] Re: New Version Notification for draft-verdt-iana-yang-guidance-00.txt Hi all, I (finally) went through -00 and here are some comments/questions. - Section 4.1 * *_COMPAT* is used for branched development trees and is not applicable to modules published by the RFC Editor in RFCs that are expected to follow a linear development, (*TODO, but may be useful/needed if we allow verified errata against YANG modules*) or maintained by IANA. So if we allow verified errata against YANG modules, we will still have linear development unless there's a bis? Couldn't we still do the linear and have the bis on top of the errata? e.g. RFCXXXX has 1.0.0, an NBC errata -> 2.0.0 and RFCXXXX-bis adds some extra functionality -> 2.1.0? - Section 4.2 Section 3.1.1 of [I-D.ietf-netmod-yang-module-versioning] defines backwards-compatible changes, which include: Do we really want to have a copy of this list in this doc? IMO the reference to module-versioning is sufficient. - 5.2.2. Step 2: RFC Editor Processing * If more significant changes are needed that might be backwards- compatible or non-backwards-compatible, consult with the authors to determine the correct version number and whether the rev:non- backwards-compatible extension is required Should we mention that this applies to a -bis? 6.4.4. Step 4: Use Tooling to Determine the Version If the tool reports NBC violations, the MAJOR version must be incremented and the rev:non-backwards-compatible extension must be added. must -> MUST? Regards, Reshad. On Wednesday, December 17, 2025 at 04:50:30 PM EST, Mahesh Jethanandani <[email protected]> wrote: Hi Jason, I agree with you that the primary audience for this document is IANA and RFC Editor. There is one question I had that applies to I-D authors for a -bis version of the document. See the inline highlighted text. If we can address that somewhere, it would help. Thanks. On Dec 17, 2025, at 6:24 AM, Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Mahesh and all, While Rob’s email was partially about adoption, I think the main question we had was for the primary consumers/audience of the doc: Sabrina, Amanda and Sandy. Are they happy with the basic structure, level of detail (too much, too little)? Maybe try looking for the answer to a few of your scenarios/questions that comes up in IANA modules and see how easy it is to use the doc? (Of course opinions on that from other folks are welcome) We wanted to know that before we start refining the text (don’t want to have to then tear the document apart and re-org/re-structure it). Jason From: Mahesh Jethanandani <[email protected]<mailto:[email protected]>> Sent: Wednesday, December 17, 2025 1:36 AM To: Robert Wilton <[email protected]<mailto:[email protected]>> Cc: Sabrina Tanamal <[email protected]<mailto:[email protected]>>; Amanda Baber <[email protected]<mailto:[email protected]>>; NETMOD WG <[email protected]<mailto:[email protected]>>; NETMOD Working Group <[email protected]<mailto:[email protected]>>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>; Reshad Rehman <[email protected]<mailto:[email protected]>>; Sandy Ginoza <[email protected]<mailto:[email protected]>> Subject: Re: New Version Notification for draft-verdt-iana-yang-guidance-00.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. [Adding Sandy Ginoza] Hi Rob, On Dec 16, 2025, at 9:32 AM, Rob Wilton (rwilton) <[email protected]<mailto:[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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Tuesday, 16 December 2025 at 16:42 To: Rob Wilton (rwilton) <[email protected]<mailto:[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]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
