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. Joe Cisco Confidential
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
