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]>
Envoyé : mardi 14 avril 2026 17:06
À : Sandy Ginoza <[email protected]>; [email protected];
[email protected]; Mahesh Jethanandani <[email protected]>;
BOUCADAIR Mohamed INNOV/NET <[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 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.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
