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] Status: https://datatracker.ietf.org/doc/draft-verdt-iana-yang-guidance/ [datatracker.ietf.org] HTML: https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html [ietf.org] HTMLized: https://datatracker.ietf.org/doc/html/draft-verdt-iana-yang-guidance [datatracker.ietf.org] 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
