Further to Jan's comments, given that all organizations (vendors, SDOs, and industry consortia) producing YANG modules all occasionally update then in NBC ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is obliged to handle cases where modules change in NBC ways.
Hence, I see changing the following paragraph in RFC 7950 section 11 from Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. to Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this SHOULD be achieved by a new definition with a new identifier. really as bugfix to RFC 7950 (given that it how everyone is interpreting it) rather than a new version of YANG. If, the landscape was different and everyone defining YANG 1 and YANG 1.1 modules was only making BC changes, then I would advocate for a new version of YANG, but that is not where we are, as has Jan as explained below, I think that defining a new version of YANG for this will just cause pain/confusion rather than any wider benefit to the industry. Regards, Rob // As a contributor > -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jan Lindblad > (jlindbla) > Sent: 12 September 2023 13:44 > To: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Cc: netmod@ietf.org > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach > > 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 > > _______________________________________________ > 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
