Hi Rob,
Regarding RFC Editor Processing (6.2.2 in latest github), I still believe we
should clarify that determining the correct version (and
rev:non-backwards-compatible) applies only to a -bis, i.e. to an already
published module.
Regards,Reshad.
On Monday, March 16, 2026 at 02:14:24 PM EDT, Rob Wilton (rwilton)
<[email protected]> wrote:
Hi Reshad,
Sorry for being slow to reply.
- I've changed the doc to just say that IETF and IANA modules won't use
theCOMPAT modifier. I think that this means that the IETF will probably limit
errata fixes to YANG modules to only the latest published versions. Perhaps
when the veloce work is finished they may decide to change this, but for the
time being we can probably keep it simple.
- As to whether we should restate the backwards compatibly rules or just
reference. I've kept this as an open issue because I think that it would be
good to get more feedback. I've tweaked the text to make it clear that these
are just examples, not a definition, and I've cut down the number of examples
for each section slightly.
- Re: "- 5.2.2. Step 2: RFC Editor Processing", I think that the existing
text is probably okay, although I intend to go through this section is more
detail.
- I've changed the must to MUST.
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 diff of the GitHub version to the previously published version (-00) 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 asking IANA & RFC
Editor to review again are:
- Go through and check the text in "6.YANG Modules in Documents Being
Published as RFCs",in particular taking on Sandy's comments/feedback.
- More work to update the tool examples (Appendix A), particularly related
to latest changes for comparing versions.
- Some tweaks to the tooling invocations in7. IANA-Maintained YANG Modules
Kind regards,Rob
From: Reshad Rahman <[email protected]>
Date: Wednesday, 31 December 2025 at 17:53
To: Jason Sterne <[email protected]>, Mahesh Jethanandani
<[email protected]>
Cc: Rob Wilton (rwilton) <[email protected]>, Sabrina Tanamal
<[email protected]>, Amanda Baber <[email protected]>, NETMOD WG
<[email protected]>, NETMOD Working Group <[email protected]>, Sandy Ginoza
<[email protected]>
Subject: Re: [netmod] Re: New Version Notification for
draft-verdt-iana-yang-guidance-00.txt
Hi all,
I (finally) went through -00 and here are some comments/questions.
- Section 4.1 * *_COMPAT* is used for branched development trees and is not
applicable to modules published by the RFC Editor in RFCs that are expected to
follow a linear development, (*TODO, but may be useful/needed if we allow
verified errata against YANG modules*) or maintained by IANA.
So if we allow verified errata against YANG modules, we will still have linear
development unless there's a bis? Couldn't we still do the linear and have the
bis on top of the errata?e.g. RFCXXXX has 1.0.0, an NBC errata -> 2.0.0 and
RFCXXXX-bis adds some extra functionality -> 2.1.0?
- Section 4.2 Section 3.1.1 of [I-D.ietf-netmod-yang-module-versioning] defines
backwards-compatible changes, which include:
Do we really want to have a copy of this list in this doc? IMO the reference to
module-versioning is sufficient.
- 5.2.2. Step 2: RFC Editor Processing * If more significant changes are needed
that might be backwards- compatible or non-backwards-compatible, consult with
the authors to determine the correct version number and whether the rev:non-
backwards-compatible extension is required
Should we mention that this applies to a -bis?
6.4.4. Step 4: Use Tooling to Determine the Version If the tool reports NBC
violations, the MAJOR version must be incremented and the
rev:non-backwards-compatible extension must be added.
must -> MUST?
Regards,Reshad.
On Wednesday, December 17, 2025 at 04:50:30 PM EST, Mahesh Jethanandani
<[email protected]> wrote:
Hi Jason,
I agree with you that the primary audience for this document is IANA and RFC
Editor.
There is one question I had that applies to I-D authors for a -bis version of
the document. See the inline highlighted text. If we can address that
somewhere, it would help.
Thanks.
On Dec 17, 2025, at 6:24 AM, Jason Sterne (Nokia) <[email protected]>
wrote:
Hi Mahesh and all, While Rob’s email was partially about adoption, I think the
main question we had was for the primary consumers/audience of the doc:
Sabrina, Amanda and Sandy. Are they happy with the basic structure, level of
detail (too much, too little)? Maybe try looking for the answer to a few of
your scenarios/questions that comes up in IANA modules and see how easy it is
to use the doc?(Of course opinions on that from other folks are welcome) We
wanted to know that before we start refining the text (don’t want to have to
then tear the document apart and re-org/re-structure it). Jason From: Mahesh
Jethanandani <[email protected]>
Sent: Wednesday, December 17, 2025 1:36 AM
To: Robert Wilton <[email protected]>
Cc: Sabrina Tanamal <[email protected]>; Amanda Baber
<[email protected]>; NETMOD WG <[email protected]>; NETMOD Working Group
<[email protected]>; Joe Clarke (jclarke) <[email protected]>; Jason
Sterne (Nokia) <[email protected]>; Reshad Rehman <[email protected]>;
Sandy Ginoza <[email protected]>
Subject: Re: New Version Notification for draft-verdt-iana-yang-guidance-00.txt
| | CAUTION: This is an external email. Please be very careful when clicking
links or opening attachments. See the URLnok.it/ext for additional information.
|
[Adding Sandy Ginoza] Hi Rob,
On Dec 16, 2025, at 9:32 AM, Rob Wilton (rwilton) <[email protected]> wrote:
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.
My general comment with the current version of the draft is that already does
a good job of capturing a lot of the guidance. I would be ok with adopting the
draft, even as we work to update the draft. Take as an example, Section 5.2.2,
Step 2, RFC Editor Processing. It calls for coordination with document authors
on any "substanive changes". But there is no definition of what are
“substantive changes”. Can that be articulated? Is it anything outside of the 4
bullet items listed in the section? The document refers to Section 4 to
determine version numbering, but there is no use of the term “substantive
changes” in that section. How should the RFC Editor manage the version number
for both the “substantive changes” and non-“substantive changes”? Also, thanks
for mentioning Appendix A.1.1. and that pyang can be used in determining BC or
NBC changes. The document assumes publication of a new YANG module. How about
a -bis version that is still an I-D? What version number should authors use?
Mahesh, you mentioned that the RFC Editor would also be interested, who would
be the best contact please, Alexis?
I have added Sandy to the thread. She and I discussed the changes the three
drafts will be bringing and she had a few questions. I will let her take a look
at the current version of the draft and compare it to her notes to see what
could be added to the draft. Thanks
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
Status: https://datatracker.ietf.org/doc/draft-verdt-iana-yang-guidance/
HTML: https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-verdt-iana-yang-guidance
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
Mahesh [email protected]
Mahesh [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
