Hi Sandy, That is a good point. We can make that announcement when IESG approves the three semver documents.
Thanks. p.s. I am going to add that as a checklist item for YANG doctors also. > On Jan 23, 2026, at 2:37 PM, Sandy Ginoza <[email protected]> > wrote: > > 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 >> > Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
