Re: [netmod] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder <[e-mail]>]

If the poll does not say what you want it to say, then the poll is
broken.

Right now, I see the following solution proposals floating around:

1) We change a single sentence in RFC 7950 and put an end to a
   multi-year effort that causes the AD to block other work from
   moving forward.

2) We make changes to YANG but we pretend that they are not real
   changes to YANG and we leave it to developers and operators to
   figure out differences in implementation behaviour one can create.

3) We make some minimal changes to YANG and we create clarity which
   rules apply and what what implementations support by giving the
   result a new version number.

Are there others? Lets talk about solutions and their properties, lets
stop standing on our heads. Guess what my acceptable and non-acceptable
solutions are.

/js

On Thu, Sep 14, 2023 at 03:42:43PM +0000, Jason Sterne (Nokia) wrote:
> 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 <[e-mail]> On Behalf Of Jürgen Schönwälder
> > Sent: Thursday, September 14, 2023 5:35 AM
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: Jan Lindblad (jlindbla) <[e-mail]>; [e-mail]
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>