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 URL nok.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]
