Hi Michael, It was IANA (one of the two main consumers of the document, the other being the RFC editor) who requested that we write this document in the first place. We suggested a wiki, but they stated that they would prefer to see it as an RFC to have more stability, so that is what we did. The initial review from IANA, prior to adoption, is that they find this document very helpful. Is also, IMHO, helps everyone understand and agree on exactly what the actual process is, or should be.
Most of the formal requirements, perhaps except when to publish, are specified in various other YANG RFCs and drafts. The aim of this document was to informatively bring those requirements together into a simple workflow for IANA, who are not, and I don't think have any wish to become YANG experts. You are right that we could ask/tell RFC editor and IANA to follow and piece together the bits of guidance in the existing RFCs and drafts, but the feedback was that it wasn't easy (e.g., for a new person) to pull all that information together. Kind regards, Rob On 17/04/2026, 15:27, "Michael Richardson" <[email protected]> wrote: TL;DR> This document should be folded into existing WG IDs. Maybe some of section 6 goes on the wiki. Mahesh Jethanandani <[email protected]<mailto:[email protected]>> wrote: > Thank you, first of all, for putting this document together. I have > found that both IANA and the RFC Editors are always challenged on how > to handle YANG modules, and this document goes a long way to answer > some of the questions they have. > My uber level comment is, is this an Informational document? Owing to > the extensive use of BCP 14 words, and if this language is intended to > be binding, this document sounds more like a BCP than Informational. If > that is not the intended, and you want to keep this informational, If it's worth publishing it at all, vs just calling WG Consensus on the contents, then it's worth publishing as a BCP, as it establishes a process. Even if the process is voluntary. It seems that this document probably should just inform updates to yang-module-versioning, yang-semver, yang-module-filename and VELOCE. Like, why does section 4 and 5 and examples exist? semver and module-versioning should have this text, no? On specific content: } * OPS ADs & IESG (if needed) that they agree that the IETF should } delay publishing YANG modules in approved internet drafts until } after the RFC Editor has had the opportunity to review and amend } the text. It seems to me like the module can't be public until AUTH48 is over. I suggest that maybe what we really want is a *patch* revision of the YANG module to be created at that point. There shouldn't be semantic changes, but there could be useful/significant updates to descriptions, etc. Section 5.2.3 says as much. Section 5.2.4: who runs pyang/yanglint again? If it's the RPC, where do they get support, and to whom do they file bugs? } If the tools return any warnings or errors then the authors should } help fix them, potentially seeking additional guidance if required, } as per Section 7. This seems to turn authors into pyang code hackers, if it turns out that the warning or error is incorrect. I.e., it's not just a YANG problem. Section 7 says it's YANG-DOCTORS problem though. Section 7.2, and Appendix A (A.2!!!) definitely tells me that this belongs in the wiki. We have challenges where the wiki is where information goes to die. Perhaps an answer to this is that every WG ought to have a recurring work-item/deliverable which is to review the content of their wiki. Ten minutes every 3rd or 5th plenary meeting, or something like that. -- Michael Richardson <[email protected]<mailto:[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
