Hi Chongfeng, I don't see all vendors aligning their internal data models with an external model family for a few reasons:
1. There are two competing external model solutions (OpenConfig vs IETF + other SDOs). It is unclear exactly where the long-term market will end up, but currently OpenConfig seems to have a big head start. 2. Most internal YANG models are tied to the internal management infrastructure within devices, and unless you are building a whole new OS, migrating this to an external model would be incredibly expensive, particularly when it is unclear as to which long term model the industry will end up using. 3. If you are building a new NOS, that aligning to a model family makes more sense, but even companies which have done that have hit issues as the external models churn, and they don't necessary want to churn all other customers, or internal models. 4. Neither IETF not OpenConfig offer complete coverage of features, or different config options/settings for protocols. This could be handled as vendor augmentations/deviations on to the open models, but otherwise, device native models are expected to have much better coverage of the devices supported features/options. Of which makes me think that we have at least one mapping layer somewhere in the stack: * This mapping may be done on the devices (e.g., from OpenConfig to device native models, and a separate mapping from IETF to device native models). * Or this mapping might be done on a controller (e.g., NSO), mapping from an open (e.g., IETF) service or network wide model onto device native models. * Or possibly even mappings at both layers (controller and device) will be used. I still think that there is a benefit to having a cohesive set of IETF YANG models that are shown to work together, particularly, if they can be illustrated to meet common operation deployments and requirements. Kind regards, Rob From: Chongfeng Xie <[email protected]> Date: Sunday, 16 November 2025 at 08:12 To: Joe Clarke (jclarke) <[email protected]> Cc: opsawg <[email protected]> Subject: [OPSAWG]Re: Thoughts on VELOCE Hi folks, I raise my questions from the standpoint of an operator, To meet customer needs more quickly, vendors have long been unable to wait for IETF standards to be finalized. As a result, their equipment widely adopts self-developed YANG models. In such cases, operators must use controllers to adapt YANG models from multiple vendors — a challenge widely faced in the industry. If the approach tested in this experiment is adopted in the future — that is, developing YANG modules outside the traditional Internet Draftprocess — it is expected to accelerate the development of YANG modules. Could this approach help alleviate the challenges currently faced by the industry? Also, if YANG model development diverges from the IETF RFC process, can existing vendor-specific YANG modules be "normalized" and become actual standards in GitHub repo? If so, will there be any threshold required for such a process? Thanks. Best regards Chongfeng From: Joe Clarke \(jclarke\)<mailto:[email protected]> Date: 2025-11-13 04:44 To: Joel Halpern<mailto:[email protected]>; Jeffrey Haas<mailto:[email protected]> CC: opsawg<mailto:[email protected]> Subject: [OPSAWG]Re: Thoughts on VELOCE 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<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]
