I think it has been mentioned, but maybe worth repeating: this poll is *NOT* about accepting the entire Module Versioning + YANG Semver content as it currently stands.
We separated out the first of several key issues to try and make progress. This is just the basic fundamental decision of whether we will allow (as a "SHOULD NOT") NBC changes in in YANG 1.0/YANG1.1 (option 1), or we are going to mandate that can only happen in a YANG 1.2 (option 2). After this poll settles out (hoping we'll get rough concensus), then we'll get back to chipping away at the other key issues (e.g. see email "YANG Versioning: Key Issues #2 and #3 - revision labels" from back in July, but there will be several other such debates & discussions). Jason > -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen Schönwälder > Sent: Thursday, September 14, 2023 5:35 AM > To: Rob Wilton (rwilton) <rwil...@cisco.com> > Cc: Jan Lindblad (jlindbla) <jlind...@cisco.com>; netmod@ietf.org > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
