Hi again, One additional note on this - our understanding is that the goal is to implement versioning upon approval of the documents (as opposed to upon publication of the RFCs). If this is correct, it would be helpful if there is a public announcement about that somewhere, so we can point authors to it when we’re discussing updates needed for the YANG modules that are already in our queue when approval occurs.
Thanks, Sandy Ginoza RFC Production Center > On Jan 6, 2026, at 3:43 PM, Sandy Ginoza <[email protected]> wrote: > > 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 > > > 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. > > > 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. > > > b) Is it correct that the version number is not required in the description? > > > 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? > > 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 { > … > > > 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 > > > 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? > > > 7) Is it possible for a version number to change between drafts? Or would > only the -0X change? > > > 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 > > > 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]
