Hi,
I read the slides and draft....
Just 2 observations:
1) First para, first sentence:
RFCs are not suited for documenting and maintaining YANG modules.
No mention in the draft or slides why this assertion is true.
rfcstrip takes 1 second to run, so not a problem for me.
Is the intent that no line-wrapping at all will be done, and this new
process is to get around
the 72-char line length limit?
2) nowhere
No mention of YANG SID files.
Does the IETF have any plan at all to quickly produce and publish an
official YANG SID file
for every existing YANG module? This is actually an asset that is not
suited for the RFC format.
This is needed for YANG/CBOR encoding of YANG Push data.
Andy
On Wed, Nov 12, 2025 at 10:13 AM Joe Clarke (jclarke) <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]
>
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
