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 <[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]
