Here are answers to some of the questions I didn't answer in the previous reply. This is from our meeting today between IANA YANG folks, the YANG Versioning authors and the Ops AD (Mahesh).
There are some additional next steps identified: - NETMOD WG: a document that describes some of the process for IANA YANG module updates (wrt versioning rules). Maybe combine this with some notes Kent created with guidance on how/when to create new IANA YANG modules - IANA YANG team to provide a list of primary use-cases/scenarios for IANA YANG module changes - IANA considerations section may need updates (YANG doctors to discuss). - NETMOD WG: May create some simple dedicated tooling for IANA YANG authors to use (e.g. to identify NBC changes, help guide which YANG Semver to use, etc) Jason > -----Original Message----- > From: Jason Sterne (Nokia) > Sent: Thursday, October 9, 2025 3:40 PM > To: '[email protected]' <[email protected]>; > [email protected] > Cc: [email protected]; draft-ietf- > [email protected]; [email protected]; draft-ietf-netmod-yang- > [email protected] > Subject: RE: [netmod] [IANA #1429269] Heads-up! Changes coming in YANG > > Hi Amanda, > > Thanks for the clearly detailed look you took at the drafts. > > I'll start with some initial thoughts below but before I get too far, it may > be > good to see another person or two from NETMOD chime in to make sure I'm > on the right track 😊 > > Please see inline. > > Jason > > > -----Original Message----- > > From: Amanda Baber via RT <[email protected]> > > Sent: Friday, October 3, 2025 8:53 PM > > To: [email protected] > > Cc: [email protected]; draft-ietf- > netmod- > > [email protected]; [email protected]; draft-ietf-netmod-yang- > module- > > [email protected] > > Subject: [netmod] [IANA #1429269] Heads-up! Changes coming in YANG > > > > > > 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. > > > > > > > > Hi Mahesh, > > > > Unfortunately, I can't give anyone access to our drive, but I'm attaching a > > Word version that you're welcome to make available via someone else's. I > > think our level of inexpertise will be pretty clear. > > > > To wrap up our semver notes, this is a list of registry/YANG updates that we > > wouldn't be sure how to classify: > > > > Replacing reference (as in an obsoleted RFC) - BC? Editorial? > [>>JTS:] This is allowed in RFC7950 ("A "reference" statement may be added > or updated.") and Module Versioning mostly keeps the same rules as 7950 to > determine NBC vs BC (only a few exceptions). I'd propose this is simply > "editorial". > > > > > Listing additional (not replacement) reference for registration - BC? > Editorial? > [>>JTS:] BC and editorial. > (I'm assuming the net result in the YANG module vs the previously published > version is an additional or changed 'reference' statement right?) > > > > > For assignments made immediately after the IESG approved an I-D for > > publication: replacing draft string w/newly-assumed RFC number upon > > publication (also, this is assuming that we're only replacing the enum's > > reference, not the original revision statement's reference) - Editorial? > [>>JTS:] I'm not 100% certain what change to the YANG you're talking about > here (vs the previous version of the YANG). Can you give a concrete example > of a line(s) in the YANG before and after this change? [>>JTS:] This is basically a change in a reference statement between the two published versions of the IANA module. A change to a reference is BC and results in an editorial/patch digit bump. (note that the initial change to the IANA module where the new enum/identity was added, with a temporary reference statement, would have been BC and result in a bump of the MINOR version digit) > > > > > > Errata reports for YANG modules or underlying registries -- does > > NBC/BC/editorial status depend on the content of the errata reports? > [>>JTS:] No - I don't think so. The NBC vs BC categorization is purely based > on > the content of the module (before vs after). [>>JTS:] The *source/trigger* of the IANA module change isn't relevant (whether it came from an errata or a new RFC). What matters is the resulting change in the IANA YANG module (i.e. if that change itself is BC vs NBC, editorial vs minor, etc). > > > > > > Removing registration (similar to obsoleting, but no trace left behind) - > > NBC? > [>>JTS:] What change in the YANG does this result in? If it removes a line of > YANG then strictly speaking this isn't allowed in RFC7950 and hence we'd > consider it NBC. > > > > > Chairs decide to mark value as "deprecated" while removing the > > name/description of the registration - Still BC? Also, what's the status > > sub- > > statement in this scenario? (we might need to address approaches to > > deprecation in 8126bis, not sure) > [>>JTS:] Sorry - not positive what YANG change this results in? Same for the > next two. Can you give examples? [>>JTS:] If the change in the *registry* is to make it "deprecated" (which means no longer supported in a registry), then in the IANA YANG it would be marked "status deprecated" and the description updated to indicate that this value should not be used in new implementations. > > > > > Early allocation allowed to expire + chairs decide to leave the > > registration > as-is > > without removing or marking it "deprecated" - NBC? Not sure how we add a > > status sub-statement for this either. (These are rare, and once we were > asked > > to revive the expired allocation a couple of years later.) [>>JTS:] It comes down to what change occurs between published versions of the YANG module. If something is removed (or obsoleted) then it is NBC. > > > > Changes to the registration that won't be reflected in the module (for > example, > > if there are changes, substantive or otherwise, to other fields beyond > "name" > > and "description," or if we need to update a non-IETF reference) - no > change? [>>JTS:] Comes back to how the published versions of the IANA YANG module have changed (or not). > > > > thanks, > > Amanda > > > > On Tue Sep 30 17:54:43 2025, [email protected] wrote: > > > Hi Amanda, > > > > > > Thanks for sharing your thoughts on the upcoming changes w.r.t. YANG > > > semver. I am going to loop in the rest of the WG, but mainly the > > > authors of the three drafts, to help me here. > > > > > > Could you start by sharing a link to the Google document that has the > > > current set of instructions you follow to update an IANA YANG module? > > > I am going to suggest that the authors of the three drafts, but really > > > anyone from the WG, suggest edits to the document that identify the > > > steps that should be taken by IANA once a YANG document is approved. > > > Once folks have had a chance to review the document, we can meet in > > > 124 (or sooner) to finalize the instructions. > > > > > > Does that work? > > > > > > > On Sep 18, 2025, at 6:58 PM, Amanda Baber via RT <iana- > > > > [email protected]> wrote: > > > > > > > > Hi Mahesh, > > > > > > > > Thanks for the early warning. I looked at a couple of these several > > > > meetings ago, but thought we were just sort of condemned to have to > > > > muddle through. > > > > > > > > So we're going to put a table together that lists various > > > > registry/YANG module update scenarios (including reference updates, > > > > different kinds of errata, different types of registry updates, etc.) > > > > and whether we think the change counts as NBC, BC, or editorial. I'll > > > > send you that and some related questions next week. > > > > > > > > In general, this is pretty rough going for us. draft-ietf-netmod- > > > > yang-semver is the toughest. The IANA Considerations section directs > > > > us to Section 4 and particularly Section 4.5, but because we're not > > > > branching or (I think) using _compatible modifiers, we have to read > > > > around much of the text to find the instructions that we do need to > > > > use. > > > > > > > > I need to note again that our roles are really administrative, not > > > > technical, and our limited experience with scripting or programming > > > > classes (which future employees likely won't have coming in) isn't > > > > doing us much good here. > > > > > > > > In order to implement all this on an irregular basis, and to train > > > > future co-workers, we're going to have to distill this into clear > > > > instructions for ourselves, which we'll add to a lengthy internal > > > > "Special Instructions for YANG and MIB Files" document that currently > > > > includes topics like "don't rename files" and "how to run pyang." > > > > > > > > This isn't optimal. We'll have to run our instructions by an expert > > > > to make sure that we've captured everything correctly, and perhaps > > > > ask for another review later if a question comes up, and because > > > > we'll be storing this on Google drive or some wiki, there's always > > > > the danger that we'll accidentally delete something crucial. > > > > > > > > I didn't feel we could ask for this before, but it doesn't hurt to > > > > mention it, I suppose: our strong preference would be for the WG to > > > > produce a short document for IANA that doesn't reproduce all of the > > > > reasoning behind the changes, but simply tells us which rules apply > > > > to IANA-maintained YANG modules and what IANA needs to start > > > > doing/revising once the document's been approved. > > > > > > > > Our general takeaways: > > > > > > > > 1) we're going to be adding a "rev:non-backwards-compatible" sub- > > > > statement to revisions where necessary, which might require more > > > > editorial judgment than we're able to apply where description changes > > > > are concerned; > > > > > > > > 2) when a registry update requires it (or likely earlier, so we don't > > > > have pressure to publish), we're going to update the most recent > > > > versions of each existing IANA-maintained module to add an x.y.z > > > > [NBC.BC.editorial] version substatement to every (I think) existing > > > > revision statement (note: someone should review the updated modules > > > > before we post them); and > > > > > > > > 3) draft-ietf-netmod-yang-module-filename doesn't seem to tell/ask us > > > > to do anything. Should we use the new naming pattern when we add the > > > > new revision substatements, and stop using dates? > > > > > > > > This text at the end of Section 4.5 just registered: 'However, the > > > > reverse does not necessarily hold, i.e., if the MAJOR version has > > > > been incremented it does not necessarily mean that a "rev:non- > > > > backwards-compatible' statement would be present." Does this apply to > > > > IANA-maintained modules? How would we know that this needed to be > > > > done? Three of us have read these now, but I'm concerned that we may > > > > have missed other items like this that may/may not apply to us. > > > > > > > > If there's any general YANG training you could point us to that isn't > > > > in RFC format, I think that would be helpful! > > > > > > > > thanks, > > > > Amanda > > > > > > > > On Wed Sep 10 21:02:17 2025, [email protected] wrote: > > > >> Hi, > > > >> > > > >> I hope this is the right email address to send this information to. > > > >> > > > >> I am currently reviewing three documents that advocate how YANG > > > >> modules should be versioned and the new files that should be created > > > >> to support that new versioning method. They will be in front of the > > > >> IESG in the next few weeks. These three documents are: > > > >> > > > >> draft-ietf-netmod-yang-semver > > > >> draft-ietf-netmod-yang-module-filename > > > >> draft-ietf-netmod-yang-module-versioning > > > >> > > > >> We have had meetings with the IETF tools team and the RPC center to > > > >> explain the changes. Since these changes impact IANA, I would > > > >> suggest > > > >> that you take some time to read through the documents and let me > > > >> know > > > >> if you have questions. I can call out the experts to explain the > > > >> changes. > > > >> > > > >> Thanks. > > > >> > > > >> Mahesh Jethanandani > > > >> [email protected] > > > > > > > > > > > > > Mahesh Jethanandani > > > [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
