Hi Rob, all, Thank you for the follow-up and for the changes. Look good to me.
Noted the other thread with IANA. Will monitor that part. Cheers, Med De : Rob Wilton (rwilton) <[email protected]> Envoyé : vendredi 17 avril 2026 15:51 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Sandy Ginoza <[email protected]>; [email protected]; [email protected]; Mahesh Jethanandani <[email protected]>; Joe Clarke (jclarke) <[email protected]>; NETMOD Working Group <[email protected]> Cc : NETMOD WG <[email protected]> Objet : Re: draft-ietf-iana-yang-guidance-01 Hi Med, Thanks for the review. Ideally, I think that we want to try and avoid this document formally defining any aspects of process or rules. That would be best left to other documents and instead the purpose of this document is to informatively give guidance of what steps the current process is. Regarding your comments: 1. I've done a bit more a check that the document indicates that it refers to normative YANG modules appropriately. 1. Regarding when to publish, I think that this is a change in the process, or at least IANA indicated that it would be. I've given a suggest to Mahesh in my reply to him on his review (which I cc'ed you on). Also tracked at (https://github.com/rgwilton/iana-yang-guidance/issues/11). 1. I've deleted the sentence containing "it is not already registered"and tweaked the previous sentence: IANA publishes the module version to the IANA YANG Parameters "YANG Module Names" registry at approximately the same time, as per [RFC6020<http://127.0.0.1:3000/draft-ietf-netmod-iana-yang-guidance.html?serverWindowId=77e910d1-25e9-42c8-bc7c-6eb2f8c897bc#RFC6020>][RFC9890<http://127.0.0.1:3000/draft-ietf-netmod-iana-yang-guidance.html?serverWindowId=77e910d1-25e9-42c8-bc7c-6eb2f8c897bc#RFC9890>] 4. I agree about not wanting normative dependencies on tooling and hence have changed the offending text to: After all updates are completed, or as updates are made, and after any formatting, then appropriate YANG validation tools MUST be run over the resultant module to ensure that there are no warnings or errors. At time of publication, it is suggested that both pyang validation (Appendix A.1.1.1<http://127.0.0.1:3000/draft-ietf-netmod-iana-yang-guidance.html?serverWindowId=77e910d1-25e9-42c8-bc7c-6eb2f8c897bc#pyang-validation>) and yanglint validation (Appendix A.1.2<http://127.0.0.1:3000/draft-ietf-netmod-iana-yang-guidance.html?serverWindowId=77e910d1-25e9-42c8-bc7c-6eb2f8c897bc#yang-lint-validation>) be performed. 5. I've added the reference to RFC9907. 6. I'm not convinced that we need to delete "Are updated more frequently than IETF-defined modules", since the list is introduced as "IANA-maintained YANG modules typically:", so I think that in the typical case this statement still stands, at the same time, not really a hill I would choose to die on 😊. Latest version (incorporating comments) is here: https://rgwilton.github.io/iana-yang-guidance/post-ietf-125/draft-ietf-netmod-iana-yang-guidance.html Kind regards, Rob From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Tuesday, 14 April 2026 at 17:16 To: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>>; 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]>>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; NETMOD Working Group <[email protected]<mailto:[email protected]>> Cc: NETMOD WG <[email protected]<mailto:[email protected]>> Subject: RE: draft-ietf-iana-yang-guidance-01 Hi Rob, all, Thank you for taking care of the comments. I think that we have now appropriate language in the draft that we are not changing publication process but build upon it. Likewise, we have now text that the guidance applies for normative modules, although that a full check is needed through the doc. For example, consider fixing this one as this covers also example modules: CURRENT: * 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. Some few comments below on -02: # I’m not sure this part is actually new: CURRENT: * OPS ADs & IESG (if needed) that they agree that the IETF should delay publishing YANG modules in approved internet drafts until after the RFC Editor has had the opportunity to review and amend the text. … IANA SHOULD delay publishing a normative YANG module to the IANA YANG Parameters registry until the RFC Editor has completed editing the module. # Current registration practices CURRENT: … * IANA registers the module in the "YANG Module Names" registry if it is not already registered ## The current practice is to proceed with registration but with a pointer to the RFC-to-draft. The reference is updated once the RFC is published. Shouldn’t that practice be reflected here? ## I have a doubt about “it is not already registered” as we need to also take into account RFC 9890. # There is one aspect that I think may be “problematic” to be frozen in an RFC: the language about specific tools (MUST pyang, etc.). I think that part can be reworded not to be an integral part of the process but an illustration or an implementation example. CURRENT: After all updates are completed, or as updates are made, and after any formatting, then validation tools MUST be run over the resultant module to ensure that there are no warnings or errors. pyang validation (Appendix A.1.1.1) MUST be performed, and it is RECOMMENDED that yanglint (Appendix A.1.2) validation is also performed. # IANA-maintained modules: should complement what is already in 9907 as it has default actions + customization OLD: When these registries are updated, the corresponding YANG modules MUST be updated accordingly by IANA, following the same versioning rules described in Section 4. NEW: When these registries are updated, the corresponding YANG modules MUST be updated accordingly by IANA, following the same versioning rules described in Section 4. These considerations MUST be followed in addition to the guidance in Section 5.3 of [RFC9907]. # I think we can delete this one as there might be registries that never be updated CURRENT: * Are updated more frequently than IETF-defined modules Cheers, Med De : Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Envoyé : mardi 14 avril 2026 17:06 À : Sandy Ginoza <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Mahesh Jethanandani <[email protected]<mailto:[email protected]>>; BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; NETMOD Working Group <[email protected]<mailto:[email protected]>> Cc : NETMOD WG <[email protected]<mailto:[email protected]>> Objet : 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
