On Wed, Nov 12, 2025 at 10:13 AM Joe Clarke (jclarke) <jclarke= [email protected]> wrote:
> NO HATS. > > For those that tuned in to the IETF 124 opsawg meeting, you know I made > the bold statement during Mahesh’s VELOCE presentation, why do we need an > I-D for a YANG module? My point was that the I-D — and by extension, the > IETF process — slows down the development of YANG modules, which has led to > other efforts like OpenConfig being more prevalent in the industry. > Additionally, I find in many cases the I-D attracts text that would better > be put into the YANG module itself (e.g., extra implementation details in > leaf descriptions). This means someone implementing or using the YANG > module can’t simply rely on it as the sole documentation for implementation. > > Jeff Haas and Rob Wilton addressed my “devil’s advocate” boldness by > explaining that an I-D is what the IETF works on and that some text is best > left to the I-D. Valid points. It was also mentioned that maybe only > the initial YANG module needs a draft, whereas minor updates could just > happen in GitHub and vendors could state that they implement a given YANG > Semver version of those YANG modules. > > Still, with all the boiler plating and tools we have for YANG (considering > 8407bis, pyang for trees, yanglint for instance data validation, yangson > and the nascent work on example coverage) I don’t see why a module — even a > net-new module — couldn’t be initially developed in GitHub with an I-D > being auto-generated from artifacts in that repo. That is, if the > expectation is one would create a YANG module and various example instance > data, the I-D could be generated with examples, trees, security > considerations, IANA considerations, etc. It won't be perfect, but it > would give the authors a strong starting point. Dare I say, fold > generative AI into this, and examples and template sections can be roughed > out automatically. > > I admit this doesn't work for all YANG modules. Certainly, the YANG > modules in the YANG versioning work need more surrounding prose. This > approach would be more suited to device-centric YANG data models. I cooked > up an experiment in my own GH > <https://github.com/xorrkaz/ietf-syslog-experiment> using the recently > standardized ietf-syslog module. It was quick. Took about 20 minutes or > so, and it did *okay.* > > But would more rapid I-D generation (or no I-D at all) really speed up the > YANG process? Not if the full IETF process still must happen for vendors > to implement modules. Not if vendors don’t like the piecemeal nature of > IETF YANG modules. However, if (ideally, when) YANG Packages is > standardized, publishing packages in GitHub along with rapid prose work > around any I-Ds that may be required might be the best answer to > holistically improving the process. > > As a YANG Doctor, I like having the I-D text to help me understand the module I have to review. It would be great if tooling could help generate most of this text somehow. The published RFC is still very important for standards conformance. Removing the I-Ds from the process might make it hard to produce an RFC, unless the tooling is good enough. I understand that too much text outside the YANG module creates duplication and ambiguity. Cut-and-paste to avoid ambiguity is not a good solution. It would be really great if Verified Errata were applied to YANG modules (and all RFCs) instead of requiring readers to manually figure out the edits. Now that we have YANG Semver, it should be easy to publish errata as patch releases. The RFC is published as X.Y.0 and any later release X.Y.* is considered to be the official RFC module. The full process should be eliminated for patch updates. Maybe minor release updates could also be streamlined, but I am just suggesting this for a patch update. Joe > Andy > > Cisco Confidential > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
