Hi Mahesh, Rob, all, About IANA's module publication processes:
When the IESG approves a document that creates a YANG module, we add an entry to the YANG Module Names registry, but don't post the module file (to be extracted via rfcstrip) until the RFC Editor notifies us that the document has been published. In the meantime, we leave a note in the registration's "Notes" field that says, e.g., "[RFC-ietf-netconf-http-client-server-31]'s module file will be posted upon the document's publication as an RFC." Per our MoU with the IETF, unless we have questions for the authors/chairs/ADs/RFC Editor, we complete the document's post-publication registry actions (which includes posting YANG modules) within seven calendar days of receiving the RFC Editor's publication announcement. (We have 14 days to complete most actions, like creating/updating registries upon document approval, but when this SLE was established, the assumption was that at RFC publication, we would only need to update references and confirm for ourselves that we were notified of any late registry changes during AUTH48. This is still true for most RFC.) It looks like we worked out the details of the module-posting procedure with the ADs in person and over email around 2018 (and with help from the RFC Editor, who initially had to supply the module files). I'm not sure it's been documented at all outside of our internal notes. This also brings up a couple of questions we have about posting the initial versions of IANA-maintained modules. The guidance document talks about updating IANA-maintained modules that have already been published, but perhaps not about creating those modules. One issue: Section 5 of draft-ietf-netmod-iana-yang-guidance has several subsections for the RFC Editor that deal with formatting and checking IETF-maintained modules. Are similar checks required for the initial versions of IANA-maintained modules? If so, who's responsible for performing them? We understand that the RFC Editor won't be checking these. Is that correct? In, I think, Madrid, we were asked to start creating these modules by copying them from the last version of the I-D that was available before publication as an RFC, so that they wouldn't have to be included in the RFC. We would then need to manually add or edit any entries (identities/enums?) to reflect any changes made to the underlying registry after the authors last updated that module. Will the script(s) used to generate these modules take care of the processing/validating that would ordinarily be required of the RFC Editor in Sections 5.2.2-5.2.4? If IANA needs to check the registry, create new identities/enums, and and check for and potentially perform processing not guaranteed by the script, this could be a heavy ask for a seven-day SLE window, especially given the possibility that we'll be posting more than one new module at a time. Another question: if authors publish an initial version of an IANA-maintained module in version -00, is there any requirement/prompt that tells them to run the script again before the IESG approves the document? I should add here that changes to the registry might not be obvious. Instead of adding a new registration, for example, IANA could have changed the name of an existing registration or added a field. Some info concerning IANA's history with module-generating scripts: we did once run a set of Python scripts that generated modules. These worked correctly aside from the fact that they didn't catch an unexpected form of reference that had been added to the registry after the script had been written (also, David reminds me, there may have been formatting/indentation issues). We applied an author-provided XSLT document to the DNS RR TYPE registry, but that might need heavy customization to work for other registries with different sets of fields. We've also had to refuse to run a script on the grounds that the I-D was asking to retrieve a portion of it from an individual's Github, rather than the document itself. If it were left to IANA to run a script in the future, we would need some path for getting the results validated. Not just via pyang/yanglint, but confirmation that the module captured everything it was intended to include (not sure who would be reviewing this). And, again, we do have that service-level expectation window that could potentially make creating/checking/troubleshooting/revising multiple IANA-maintained YANG modules an "all hands on deck" situation, or a reason to talk to the IAB's IETF-IANA group about revising our MoU. thanks, Amanda On Tue Apr 21 16:00:04 2026, [email protected] wrote: > [Including IANA and RFC Editor in this part of the discussion] > > Hi IANA/RFC Editors, > > Some background for IANA and RFC Editors. > > The above draft suggests that: > > > IANA SHOULD delay publishing a normative YANG module to the IANA YANG > > Parameters registry until the RFC Editor has completed editing the > > module. This coordination ensures that: > > > > The IANA-published version matches the RFC-published version exactly > > No discrepancies exist between the two authoritative sources > > The module reference to the RFC (if present) is correct > > This is believed to be a process change, and I wanted to get your take > on it. > > > On Apr 17, 2026, at 4:30 AM, Rob Wilton (rwilton) <[email protected]> > > wrote: > > > > Regarding the timing of when YANG modules are published by IANA. > > Yes, I agree that this is a deliberate process change that I'm trying > > to introduce. Basically, I think that IETF/IANA should delay > > publishing the YANG module after IESG approval until any markups > > (e.g., from the RFC Editor) to the YANG module have been completed > > and the final version of the module (with the final version label) is > > ready, otherwise IANA will end up publishing a pre-release version. > > I doubt that the existing process of when IANA should publish is > > specified anywhere, and I'm not sure that we want this document to be > > defining the process. Hence, I propose is that it would be better > > for IANA + RFC Editor + OPS ADs + IESG to agree on whether the > > process should change and then we can ensure it is documented > > correctly (informationally rather than normatively) in this document. > > (open issue tracked withhttps://github.com/rgwilton/iana-yang- > > guidance/issues/11) > > I also wanted to understand the current process. Does IANA start > updating the IANA registry for drafts that carry an IANA YANG module > soon after IESG approval? What happens if the RFC Editor needs to make > changes to the module? > > How would this process change with semver? > > Cheers. > > p.s. I am not sure the process changes. The document arrives with a > pre-release version like 0.1.11, IANA and RFC Editors make the changes > they need to make, and publish it as 1.0.0, but I could be completely > wrong. > > > Mahesh Jethanandani > [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
