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.
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.
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]
