No hats here either! Thanks, Joe, for kicking off the discussion on VELOCE. I was going to kick off several different threads, each of them focusing on one of the questions I brought up in the presentation. This particular discussion refers to the question of “How many assets are we talking about?” and how it affects the standards process.
I identified two assets, the I-D and the YANG module. As Jeff has articulated, the discussion in VELOCE is how to review and update YANG modules, something I-D is clumsy about. Imagine reading 250 pages of a YANG module (yes, BGP YANG module is that big) in a text file. My rationale for suggesting keeping the I-D as is, including description of the module, tree diagrams, and any prose, and moving the YANG module into GitHub has mainly to do with keeping the standards process as much as possible, including what gets adopted, where it is adopted, etc.? Reading and providing comments on YANG modules in GitHub makes more sense not only from a developer's perspective but also in how the modules are consumed. Not to mention the ability to run a CI/CD pipeline on the YANG modules. I would go as far as suggesting that instance data examples should similarly not be included in the I-D. At the same time, I agree that once a YANG module is defined, any bis updates should not have to touch the I-D, as Joe refers to below. The stable link in the I-D should point to the latest version (master/main branch?) of the module, with the idea that those updates in GitHub can be made faster. No part of identifying a rough consensus or approving changes, as the modality of it changes. In addition, the changes will still be reflected back on the mailing list. My next thread will be on how the WG stays engaged in this updated process. Feel free to poke holes in and find issues with this process so we can iron it out. Cheers. > On Nov 12, 2025, at 10:13 AM, Joe Clarke (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. > > Joe > > Cisco Confidential > > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
