Re: [netmod] Poll on YANG Versioning NBC Approach

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

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/>