On Thu, Sep 14, 2023 at 11:46 AM Jürgen Schönwälder
<jschoenwaelder@constructor.university> wrote:
> 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.
>
OK.
It would be useful to identify the specific text in RFC 7950
that is causing all these problems for the IETF.
IMO, nobody is objecting to the MUST or MUST NOT text in sec 11, para 2,
3, 4, and 7.
There is only 1 paragraph in the entire RFC that needs to change (sec 11,
para 6)
OLD:
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.
NEW:
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.
My preferred solution path:
1) Issue Errata for RFC 7950 and Hold for Update or Verify.
Either way, allow IETF modules to use the NEW text
2) Remove updates to RFC 7950 from the versioning draft
3) fix the other issues raised with the versioning draft and publish it
Andy
> 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 <netmod-boun...@ietf.org> On Behalf Of Jürgen Schönwälder
> > > Sent: Thursday, September 14, 2023 5:35 AM
> > > To: Rob Wilton (rwilton) <rwil...@cisco.com>
> > > Cc: Jan Lindblad (jlindbla) <jlind...@cisco.com>; netmod@ietf.org
> > > 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: +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
