Hi, Rob: Thanks for the update to draft-ietf-iana-yang-guidance, I take some time to review the latest version and have the following comments and input, hope it helps:
1. Section 2 said: “This document provides informational guidance to both the RFC Editor and IANA for managing YANG modules in two distinct scenarios:” [QW]: This document provide guidance for both RFC Editor and IANA? I am wondering whether YANG module authors need to pay attention to this informational guidance? Or the principle is If YANG module author don’t follow this guidance or don’t need to worry about this guidance before IESG review, RFC Editor and IANA has right to block publication of this documents after IESG review until Module version gets corrected? Section 4.1 said: “_COMPAT is used for branched development trees and is not applicable to normative modules published by the IETF or IANA-maintained modules. ” [QW]:Look at the definition of _COMPACT: ” _COMPAT is used for branched development trees and is not applicable to normative modules published by the IETF or IANA-maintained modules. ” It is not clear to me how to understand normative module? Do we emphasize _COMPACT is optional parameter instead of mandatory parameter? Or Is _COMPAT designed for pre-release version? Section 4.1 also said: “ …. e.g., as per the second example below. ” [QW]:Where the second example below is documented? In which section? Section 4.1 said: “ Pre-release versions (versions with MAJOR = 0, e.g., "0.2.0", or with a pre-release suffix, e.g., "1.3.0-04") ” [QW]: I understand -04 is internet-draft-number and is used to compatible with semver and can be seen as version label, however such pre-release suffix used in many place not consistent, e.g., Section 5.2,1 said: “any normative YANG modules it contains typically have pre-release version numbers (e.g., 0.4.0, 1.1.0-03, or 2.0.0-07)” Section 4.4 said: “ Modules in Internet-Drafts MUST use pre-release versions (e.g., 0.1.0 or 2.0.0-draft-name) to indicate that the content may still change. ” Here draft-name is referred to full draft name or draft number, I think such inconsistency needs to be addressed. Section 5.2.2 said: “ consult with the authors to determine the correct version number and whether the rev:non-backwards-compatible extension is required. ” [QW]: Who should be consulted to determine the correct version number and whether the rev:non-backwards-compatible extension is required. Section 5.2.2 said at the RFC Editor Processing stage, the draft authors should be consulted. Section 7 said, YANG Doctor should be consulted At the RFC Editor Processing stage combine together with other circumstances such as: 1. Classification Uncertainty 2. Tool Disagreement 3. Description Changes 4. Unusual Situations 5. Registry Restructuring Section 6.4.4 said: “ 6.4.4. <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-iana-yang-guidance-02#section-6.4.4> Step 4: Use Pyang Tooling to Check/Recommend Next Version<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-iana-yang-guidance-02#name-step-4-use-pyang-tooling-to> ” [QW]: Do we need to separate guidance from specific tooling recommendation? Usually YANG Guidance doesn’t tie closely with specific YANG tools. I search pyang, it has occurred for 27 times. -Qin 发件人: Rob Wilton (rwilton) [mailto:[email protected]] 发送时间: 2026年4月14日 23:06 收件人: Sandy Ginoza <[email protected]>; [email protected]; [email protected]; Mahesh Jethanandani <[email protected]>; Mohamed Boucadair <[email protected]>; Joe Clarke (jclarke) <[email protected]>; NETMOD Working Group <[email protected]> 抄送: NETMOD WG <[email protected]> 主题: [netmod] Re: draft-ietf-iana-yang-guidance-01 Hi Amanda, Sabrina, Sandy, OPS ADs, NETMOD WG chairs, & Joe, I've now just published draft-ietf-iana-yang-guidance-02, https://www.ietf.org/archive/id/draft-ietf-netmod-iana-yang-guidance-02.html This incorporates the changes from the NETMOD discussion at IETF 125, and merges in review comments from Reshad, Joe, & Med. Thanks Med! There are no open issues against this document, and as such I am thinking about whether we should try and take this to WG LC already to flush out any further reviews! Ideally, it would be nice if this draft could catch up with the other three post WG LC YANG versioning drafts (some of which will have an informative reference to this document) and hence get published at the same time - but we don't want to rush it if it is not complete/ready. Note, there is still an open discussion point in https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/, that could change which character is used to identify a YANG file using a YANG Semver, which would require this doc to be updated with a small editorial change. Hence, in our meeting today, we would like to request that IANA and the RFC Editor both review the document for readability/guidance and also check the workflow steps proposed in this document and workable and make sense. Perhaps going through a sample workflow of trying a few imaginary registry changes and checking if you hit any issues with the workflow or need further clarification. When using pyang to do the version comparison, then you will currently need to use the version in Joe's GitHub repository here (on the master branch): https://github.com/xorrkaz/pyang Joe (or I, or one of the tools team) can probably help you get this setup if you need guidance. But the basic steps are to pull a local copy of this github repository and then run "env.sh" from within the directory that git/GitHub copies the repository into. Then your pyang invocations would pick up the new checks. Alternatively, we could arrange a call and give a demo of how the tool would work if you think that would be helpful. Please let me know if you would like me to try and set this up. Finally, Mahesh, Med, is there anything that needs done from your side? E.g., do you need to check with the IESG at all on what is proposed here, or can I assume that is either all in-hand, or will be dealt with during AD review or IESG review? Kind regards, Rob From: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Date: Tuesday, 17 March 2026 at 21:26 To: Sandy Ginoza <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Mahesh Jethanandani <[email protected]<mailto:[email protected]>>, NETMOD WG <[email protected]<mailto:[email protected]>>, NETMOD Working Group <[email protected]<mailto:[email protected]>> Subject: [netmod] draft-ietf-iana-yang-guidance-01 Hi all, I've just published the -01 version of this draft that has quite a lot of updates and fixes and should hopefully incorporate the comments that I have received. There is already a later version on GitHub (https://github.com/rgwilton/iana-yang-guidance?tab=readme-ov-file) that contains a couple more tweaks from Reshad and some spelling corrections. As a reminder this is an informational draft, for which the abstract is: 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. I'll be presenting this draft in the NETMOD session on Wednesday morning. I think that there are 4 open issues that need to be addressed: 1. Do we need guidance to IANA in this document to list modules both by revision date and version? I.e., following the filename convention. 2. This document is informational, is it appropriate to use RFC 2119 language? 3. For the RFC Editor and ADs, do we want to allow the RFC Editor to apply errata to IETF YANG modules? 4. For Section 5<https://rgwilton.github.io/iana-yang-guidance/draft-ietf-netmod-iana-yang-guidance.html#sec-background>, should we give examples of the rules, or just reference the module versioning draft [Reshad]? Depending on the feedback received it may be that we can get these addressed quickly, and then I'm wondering whether we will want [another] round of reviews, of whether it would make sense to go directly to WG LC? On the one hand this document hasn't had that much in the way of reviews (it is quite new), but on the other hand it is only informational guidance and we are wanting to move it through the process quickly. Kind regards, Rob
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
