Hi Amanda, and Sabrina, Sorry for being a bit slow to get back to you. I failed to update the document before the submission deadline, but I have spent some time post submission to go over the doc, which should also include addressing your comments below, along with many other updates to hopefully improve the document.
For 6.4.1, I've changed the wording so that it doesn't talk about contacting experts (which I can appreciate will be confusing in the context of IANA registries) and instead the section is now titled "Seeking Additional Guidance". I.e., the intention is that this would be used if the result, e.g., provided by the instructions or tooling is not clear. For 6.4.7, I've changed that to give guidance in the document for this case, i.e., select the version associated with the most impactful change (which is also what the tooling will automatically recommend). Regarding reusing entries - I think that it okay, again, it seems better to mark them as obsolete, but as you say, it just depends on what the change is to the registry. From the new YANG versioning perspective this is allowed if the version is updated appropriately. I've updated/removed the text that was explicitly discouraging this. For the description statements, I have updated them to what I think they should look like in the examples and expanded the examples to cover other cases. As per my reply to Reshad that I have just sent: 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 text diff of the GitHub version to the previously published version (-00, that you previously reviewed) 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 properly asking you to properly 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>", taking on Sandy's comments/feedback. 1. More work to update the tool usage guidelines (Appendix A), particularly related to latest changes for comparing versions. We will want to check what invocations for the tooling you are using today to ensure that the guidance that I am giving is consistent with what you and the RFC editor are currently doing. 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>, updated to align with the tool usage guidelines in the appendix. There are still some open issues listed at the beginning of the doc. I plan on presenting this draft in Netmod during the first session on Wednesday (https://datatracker.ietf.org/doc/agenda-125-netmod/). It is the first item on the agenda after the chairs slides so should be near the beginning of the session (i.e., first 20 mins). If either or both of you are able to please attend, or listen to the recording, then that may be helpful. I would come over and go over this draft in person with you, but alas I'm not in Shenzhen this week ... Kind regards, Rob From: Amanda Baber <[email protected]> Date: Saturday, 10 January 2026 at 02:01 To: Rob Wilton (rwilton) <[email protected]>, Sabrina Tanamal <[email protected]>, Mahesh Jethanandani <[email protected]> Cc: NETMOD WG <[email protected]>, NETMOD Working Group <[email protected]>, Joe Clarke (jclarke) <[email protected]>, Jason Sterne (Nokia) <[email protected]>, Reshad Rehman <[email protected]> Subject: Re: [Ext] FW: New Version Notification for draft-verdt-iana-yang-guidance-00.txt Hi Rob, all, Sabrina, David and I went through this document, and it’s extremely helpful. Just a few notes: * Section 6.4.1 says that the registry may specify “contact information for experts.” This threw us for a minute, as designated experts shouldn’t be named in an RFC. Is this referring to expert mailing lists? If so, would it be possible to indicate that this refers to something like a list? We’ve seen a couple of I-Ds name the expert. * Section 6.4.7 says that for multiple changes of different types (major/minor/patch), we should consult experts. Should this document provide advice to experts, or is that located elsewhere? * Section 7.1, B.2.5, and B.2.7 include statements indicating that previously assigned value numbers shouldn’t be reused and removing (as opposed to obsoleting) registrations/values without a trace is discouraged. There’s a slight awkwardness to this, as these decisions are likely to be made by chairs and ADs rather than IANA. 8126bis will include text noting that deprecated and obsoleted values won’t be re-used until all other values have been exhausted, but doesn’t cover removals. We can try to point out that there are YANG module considerations when we’re, e.g., asking chairs how to treat expired early allocations, but I wonder if this is a note that should be added to registries or included in another document or something. (We could also point out in 8126bis that chairs and ADs making decisions of this kind should consider YANG/MIB/other modules that might be affected.) * The examples are terrific, but could the revision statement examples in Appendix B and C be updated at some point to use a description substatement format that people would like us to use in the modules? I know that isn’t the purpose of this document, but we haven’t received much instruction in this area, and B.2.1., for example, suggests that we'd write a kind of summary we wouldn’t be able to write ourselves for every registration (if any), and future IANA staff might eventually take this as the approach we’re meant to apply. (This is assuming that these are in fact made-up examples and not direct quotes from existing modules, in which case I guess the ask is to make up examples instead.) Thanks very much for this. Amanda From: "Rob Wilton (rwilton)" <[email protected]> Date: Tuesday, December 16, 2025 at 9:32 AM To: Sabrina Tanamal <[email protected]>, Amanda Baber <[email protected]>, Mahesh Jethanandani <[email protected]> Cc: NETMOD WG <[email protected]>, NETMOD Working Group <[email protected]>, "Joe Clarke (jclarke)" <[email protected]>, "Jason Sterne (Nokia)" <[email protected]>, Reshad Rehman <[email protected]> Subject: [Ext] FW: New Version Notification for draft-verdt-iana-yang-guidance-00.txt 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. Mahesh, you mentioned that the RFC Editor would also be interested, who would be the best contact please, Alexis? 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 [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.txt__;!!PtGJab4!_ZbiTDiwZoZr26EVTbeW5KcwkyXDf46b3djHcRIvSALmFZKLvtUzk6ZPeElBa8xJVx7Bx5LblutiGRa7s2p8g04$> Status: https://datatracker.ietf.org/doc/draft-verdt-iana-yang-guidance/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-verdt-iana-yang-guidance/__;!!PtGJab4!_ZbiTDiwZoZr26EVTbeW5KcwkyXDf46b3djHcRIvSALmFZKLvtUzk6ZPeElBa8xJVx7Bx5LblutiGRa7R0AkzEs$> HTML: https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html__;!!PtGJab4!_ZbiTDiwZoZr26EVTbeW5KcwkyXDf46b3djHcRIvSALmFZKLvtUzk6ZPeElBa8xJVx7Bx5LblutiGRa7PCq6o9Y$> HTMLized: https://datatracker.ietf.org/doc/html/draft-verdt-iana-yang-guidance [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-verdt-iana-yang-guidance__;!!PtGJab4!_ZbiTDiwZoZr26EVTbeW5KcwkyXDf46b3djHcRIvSALmFZKLvtUzk6ZPeElBa8xJVx7Bx5LblutiGRa7IzrE37Y$> 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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
