I think this misses the important point. Yes, working out a YANG RFC takes time. Doing it as an I-D does introduce some obstacles. But...
We need to actually get community engagement and agreement. Otherwise, they are just individual YANG modules, not standards. Getting community engagement and agreement takes time and effort. If you don't want to do that, then post your individual YANG module wherever you want, with whatever non-IETF process you want. [JMC] Adrian Farrell raised similar points at the mic. In addition to the technical community support, the RFC Editor provides reviews are readability, which are valuable when it comes to both document prose and YANG module descriptions. I don’t think doing work in GitHub precludes community discussion and involvement. It is a different modality, though. Yours, Joel PS: No, I am not claiming that the IETF process is perfect. But treating standards as if they are code we can revise at the drop of a hat, and everyone will just end up using it, doesn't work. [JMC] Somehow this works for Open Source. And if a standard takes so long to ratify that no one uses it anyway, how workable is that? Joe On 11/12/2025 2:42 PM, Jeffrey Haas wrote: > >> 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]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
