Hi Jürgen, Please see inline ...
> -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen > Schönwälder > Sent: 12 September 2023 14:11 > To: Jan Lindblad (jlindbla) <jlind...@cisco.com> > Cc: netmod@ietf.org > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach > > The two options mix things together. Option 1 says updating YANG 1 and > YANG 1.1 to allow YANG modules to be modified _based on > draft-ietf-netmod-yang-module-versioning_ but this document has much > more in it than just changing a MUST to SHOULD. [Rob Wilton (rwilton)] 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? 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). > > 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. > > 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. Regards, Rob > > /js > > PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long > as you do not use YANG 1.2 rules and mechanism. > > On Tue, Sep 12, 2023 at 12:43:56PM +0000, Jan Lindblad (jlindbla) wrote: > > Jürgen, all, > > > > I see the irony in changing the YANG RFC(s) without updating the YANG > language version number, but digging a bit deeper, I think the question is not > as clear-cut as it might seem at first. > > > > Altering the contents of the backwards-compatibility section of RFC 6020 > (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module > authors' behavior. > > > > Speaking as a YANG compiler implementor, however, I don't see any > changes that have to made to the compiler because of this RFC change. There > are no new keywords, none are removed. There is no change in the meaning > of existing keywords. There is no difference in the output the compiler needs > to generate. > > > > So while there are changes to the YANG *standard* (meaning RFCs) there is > no actual change to the YANG *language*. If we require user's to mark their > modules with version 1.2 (or 2.0), from the compiler's pov, that would just > be an alias for YANG 1.1. It means a fair amount of trouble to update all the > tools out there to accept "yang-version 1.2" but do nothing new. It also adds > a burden to YANG module implementors, since they would have to go > through all YANG 1.1 modules and mark them 1.2, for no change in meaning. > For organizations with some modules still on YANG 1.0, the bar is even > higher. > > > > I think the most pragmatic approach in this case would be to change the > RFC text in the backwards-compatibility sections and not update the yang- > version number as long as no change is required in the compilers. If anyone > can point to actual things the compiler needs to do differently, I'd be > interested to hear. > > > > Best Regards, > > /jan > > > > > > > > > On 12 Sep 2023, at 07:55, Jürgen Schönwälder > <jschoenwaelder@constructor.university> wrote: > > > > > > I disagree with the poll. There are important teachnigal differences > > > behind the two options that this polls tries to hide. > > > > > > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG > > > 1.1'. There is no way that a new versioning approach will be > > > understood by existing YANG tooling. That's an illusion. > > > > > > /js > > > > > > On Mon, Sep 11, 2023 at 10:39:39PM +0000, Kent Watsen wrote: > > >> WG, > > >> > > >> Please help the YANG-versioning effort move forward by participating in > the following poll: > > >> > > >> - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login > required) > > >> > > >> Kent and Lou > > >> > > > > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > -- > > > 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 > > > > -- > 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
