On Tue, Sep 12, 2023 at 01:42:57PM +0000, Rob Wilton (rwilton) wrote: > > I think that for this first poll this is the question that we should > initially focus on. I.e., at a starting point, do you agree to updating RFC > 6020, RFC 7950, to allow changing the MUST to a SHOULD without a new YANG 1.2? >
There are many options, one is to just change a single sentence. But the poll fails to sort the options out. > If we can get consensus on this part, then I think that we can try and tackle > getting consensus on the other updates in > draft-ietf-netmod-yang-module-versioning to decide whether to include those > in a document that updates existing versions of YANG without a change in the > YANG versioning number, or whether those changes should be deferred to a new > version of YANG (which I hope that the WG starts after this versioning work > completes - but I'll no longer be an AD at that stage). This work is going on for years, the WG has failed so far to enumerate the options and come to a conclusion. > > There are features in draft-ietf-netmod-yang-module-versioning that > > you can use only with new tools that implement the features. I am not > > sure why tools that support different variants of YANG 1 and YANG 1.1 > > are any easier in practice than a tool that says clearly what it > > implements. > [Rob Wilton (rwilton)] > > I hear two concerns: > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC > changes anyway because they see them in the wild and that won't change. > E.g., it is 99% likely that OpenConfig will still continue to use Yang 1 > modules. > (2) All existing tooling won't be able to handle YANG 1.2 without tooling > changes. If you do not need YANG 1.2 features, YANG 1 just works fine. The assumption that once can use YANG 1.2 features with YANG 1 modules by simply not calling the features YANG 1.2 is what puts me off. > > I continue to believe the questions are badly phrased. Instead of > > discussing properties and trade-offs of solutions, we discuss the > > version number. And we accept that bumping the version number is > > considered too costly but at the same time the entire work is about > > introducing version numbers to data models (where the same logic will > > sooner of later apply). Yes, for me, this is real-world irony. > [Rob Wilton (rwilton)] > > I see this as: What are we able to do now without changing the YANG > versioning number, and without breaking existing tools, to help solve real > world issues today? I.e., the aim is to bound our solution by what we are > pragmatically able to support in YANG 1/YANG 1.1 without breaking existing > tooling (which should already ignore existing statements that they don't > understand). > > Yang 1.2/2 should be worked on, but that will probably include other changes > as well and involve some level of effort from tool vendors to support. It > will also probably also take many years. > A one line sentence change replacing MUST with SHOULD Not is one thing, the ID on the table a different thing. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
