> On Nov 12, 2025, at 1:13 PM, Joe Clarke (jclarke) > <[email protected]> wrote: > NO HATS.
Warren Kumari may consider this a personal attack. :-) > 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. Echoing some of my in-room and in-chat comments, portions of what we accomplish between YANG and I-D could almost be done via in-line markup in the YANG module. Think about this as Doxygen (or your favorite in-code markup mechanism) where the object is tagged with stuff that is removed for module publication but generates inside the I-D text. This isn't a strong proposal, but it's mostly nodding to the fact that good portions of what we stick in I-Ds are driven more by the YANG than the I-D text explains the YANG. > 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. semver is more of a general nod toward "if we do our work not in the data-tracker, when do we consider it published to the IETF?" This is really a release-engineering discussion. When we consider modules that have inter-dependent fates, the package of associated modules is the item of discussion. Such a thing might be "develop the module wherever, but you eventually click publish on your draft and the semver for that is published on an IETF site". The nice YANG/I-D environment that Mahesh maintains could readily support such a thing, and I'm sure github itself could get such plumbing as part of CI/CD. > 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 invite everyone to heckle the stale BGP YANG module. It suffers for all of the things highlighted here, particularly due to its size. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-18 and the associated github and build environment for the I-D and module unit tests. https://github.com/mjethanandani/ietf-bgp-yang -- Jeff _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
