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? > > 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). > > 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? > > 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.) > > 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? > > 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]
