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