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? Listing additional (not replacement) reference for registration - BC? Editorial? 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? Errata reports for YANG modules or underlying registries -- does NBC/BC/editorial status depend on the content of the errata reports? Removing registration (similar to obsoleting, but no trace left behind) - 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) 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]
IANA YANG Instructions.docx
Description: MS-Word 2007 document
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
