Hi Sandy & Mahesh, Sorry for the delayed response, I've now just updated the draft (mainly section 6) which I hope will address and clarify these comments.
Please see inline [Rob] (sorry, Outlook won't properly indent) From: Sandy Ginoza <[email protected]> Date: Tuesday, 6 January 2026 at 23:44 To: Joe Clarke (jclarke) <[email protected]> Cc: Mahesh Jethanandani <[email protected]>, Jason Sterne <[email protected]>, Rob Wilton (rwilton) <[email protected]>, Sabrina Tanamal <[email protected]>, Amanda Baber <[email protected]>, NETMOD WG <[email protected]>, NETMOD WG Chairs <[email protected]> Subject: Re: [netmod] New Version Notification for draft-verdt-iana-yang-guidance-00.txt Hi all, Thanks for including us in this discussion and thank you for the guidance in draft-verdt-iana-yang-guidance. Apologies in advance, as I’m rehashing much of what is in the docs to ensure we understand the expected updates. 1) Is it correct that this is what we might see in the I-D: > [JMC] We simplified this a bit so that once the draft is adopted as a WG > document, it can be 1.1.0-01, -02, -03 (for BC) or 2.0.0-01, -02, -03 (for > NBC). The point being each version MUST be unique. BC model in draft - 1.1.0-01, 02, 03 NBC model in draft 2.0.0-01, 02, 03 And, in most cases, the RPC would simply remove -0X so we end up with the following in the RFC? BC model on publication - 1.1.0 NBC model on publication - 2.0.0 [Rob] Yes, that is correct. Ultimately, we need to ensure that the version in the YANG module that the IETF publishes is right. In the workflow that I have provided in the documentI have asked the RFC Editor to run a tooling script to perform that check, and ask for extra help from the authors (who won't necessarily be YANG experts) and YANG Doctors. Does that sounds right? 2) From https://www.ietf.org/archive/id/draft-verdt-iana-yang-guidance-00.html#section-4.4: - Modules in Internet-Drafts SHOULD use pre-release versions (e.g., 0.1.0 or 2.0.0-draft) to indicate that the content may still change - Once a document is approved by the IESG, the module version MUST be updated to a release version (e.g., 1.0.0, or 2.0.0) before publication as an RFC. Would these be the correct updates? I-D: 0.1.0 RFC: 1.0.0 I-D: 2.0.0-draft RFC: 2.0.0 In one case the major version number changes; in the other, we simply remove -draft. [Rob] Yes, that looks right. 3) Looking at the examples in Section 7 of https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-13 a) For the yang-version and the version noted in the description, what would appear in the draft? Is it correct that we’d see some form of “yang-version 1.1-X” and the RPC should ensure the version in the description (if present) matches? <CODE BEGINS> file "[email protected]" module ietf-yang-revisions { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions"; prefix rev; … description "This YANG 1.1 module contains definitions and extensions to support updated YANG revision handling. … // RFC Ed.: update the date below with the date of RFC publication // and remove this note. // RFC Ed.: replace XXXX (inc above) with actual RFC number and // remove this note. // RFC Ed.: replace YYYY-draft-ietf-netmod-rfc6991-bis (inc above) with actual RFC number and // remove this note. [Rob] Note, the "yang-version" statement is something completely different. It is referring to the version of the YANG language that describes the module. For new or updated IETF modules, they should always be "yang-version 1.1" to indicate that they conform to RFC 7950. Without that statement (or "yang-version 1") would indicate that the module conforms to RFC 6020. b) Is it correct that the version number is not required in the description? [Rob] Correct. I think that the description above would be better to just read: "This YANG module ..." c) Is it correct that the description says “Initial version” because it’s still major version 1? That is, will the description be “Initial version” until it becomes version 2.0.0? [Rob] The first externally published version by the IETF on IANA should "Initial version" and have version "1.0.0". All subsequent versions higher than "1.0.0", i.e., "2.0.0", "1.1.0", "1.0.1" should have a brief description that summarises the changes or reason for the module update. revision 2025-01-28 { description "Initial version."; reference "RFC XXXX: Updated YANG Module Revision Handling"; 4) For NBC updates, is it correct that the RPC can expect this info to already be present in the module/document? rev:non-backwards-compatible; … extension non-backwards-compatible { … [Rob] Yes, if it is non-backwards compatible version change, i.e., the major version number has been incremented, then the module should have "rev:non-backwards-compatible;", but it won't have or need extension non-backwards-compatible since that is only in the module that defines the extension statement. The tooling that checks the version number will also point out if the "rev:non-backwards-compatible;" statement is missing and is needed. 5) Does major.minor.patch get selected according to the biggest change? For example, if there are minor and patch updates, would the version number be as follows (i.e., no change to the patch number)? 1.0.0 —> 1.1.0 [Rob] Yes, that is correct. The draft should be clearer on this point now. The tooling that recommends the new version (or checks that it is right) will also get this right (I hope ;-). 6) The RPC usually updates the RFC number, date, IANA assignments, and references, in addition to description clauses. We also sometimes make formatting updates based on the output of pyang's formatting option and add the 2119 keywords paragraph if they capitalized form is used within the module. Is it correct that the RPC would not need to increment the version number for these in the common case because the updates are taking place before publication? [Rob] Yes, that is correct. When the YANG module is part of a draft, i.e., before it is properly "published" it has the -XX suffix to indicate that it is a "pre-release" version. The Semantic version numbers are only comparisons against the previous published version by the RFC Editor and on the IANA website. 7) Is it possible for a version number to change between drafts? Or would only the -0X change? [Rob] Yes, it is possible, if the scope/type of changes that have been made change. E.g., it is possible that the authors started with only backwards compatible changes and hence were using "1.1.0-01", "1.1.0-02", and then realised that they needs to make breaking changes (perhaps even just to incorporate a bugfix) and hence the next version would be "2.0.0-03". I.e., the version number indicates what the target version is. Less likely, but possible would be to go the other way, i.e., starting by targeting a major version change, but then remove any non-backwards-compatible changes and end up with a minor version change. E.g., if the previous published version was "2.1.0" then the drafts could be "3.0.0-01", "3.0.0-02", "2.2.0-03", "2.2.0-04", ... 8) In general, the authors and reviewers will consider whether the changes are major, minor, or patch as the module is developed, so in the typical case, the RPC would be expected to: a) for new modules, update 0.X.X to 1.0.0 b) remove -0X (but don’t increment the version number) c) discuss/raise questions as needed [Rob] Yes. I think that is correct, but I think that this also needs the AD to weigh in. Currently in the workflow steps for section 6, I am asking the RFC Editor to use tooling to ensure that the right version has been selected. I think that we need to ensure that there is a check somewhere in the publication pipeline after all updates to the module have been performed to ensure that the version is right. Kind regards, Rob Thanks for your help!! Sandy Ginoza RFC Production Center > On Dec 19, 2025, at 8:01 AM, Joe Clarke (jclarke) <[email protected]> wrote: > > [mj] Thanks for those pointers. In the case of a draft-ietf-netmod-foo-bis, > what I understand is this. Assuming the initial model has been published, > this is what the revision number(s) would look like > > Initial published model - 1.0.0 > draft-ietf-netmod-foo-bis I-D that is intended to be BC - > 1.1.0-draft-ietf-netmod-foo-bis-01, 02, 03 etc. > draft-ietf-netmod-foo-bis I-D that is intended to be NBC - > 2.0.0-draft-ietf-netmod-foo-bis-01, 02, 03 etc. > BC model on publication - 1.1.0 > NBC model on publication 2.0.0 > > Does that sound correct? > > [JMC] We simplified this a bit so that once the draft is adopted as a WG > document, it can be 1.1.0-01, -02, -03 (for BC) or 2.0.0-01, -02, -03 (for > NBC). The point being each version MUST be unique. > > Joe
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
