Hi Jurgen & WG,
One thing that's clear to me: although the Key Issue #1 poll seems clear that
we don't need YANG 1.2 to continue this versioning work (subject to
confirmation from the chairs), more discussion is needed on the content of "the
first YANG Versioning RFC" that we want to publish (i.e. what subset of the
Module Versioning draft/concepts to include).
Some people seem to be leaning towards only including an extremely minimal
concept from the versioning work: allowing NBC changes (as a "SHOULD NOT"). I'm
not in favor of one having that minimal draft.
But it does seem that nobody is championing (anymore) the idea of doing an
errata to 7950 or doing a 7950 bis. Certainly the 7-8 people from our weekly
call last week are all against it (so at minimum, it doesn't have any sort of
consensus to do that). Does anyone on the list still want to champion the idea
of a 7950 errata or bis?
Back to the minimal draft concept: I think opening up NBC changes as allowed
(as "SHOULD NOT") without also trying in the rev:non-backwards-compatible
marker as mandatory in the same draft would be a mistake and not move us
forward. An important part of the versioning work is to bring explicit
visibility that an NBC change has occurred (provided by the publisher/author).
It would be good to hear from others in the WG on this point.
Jason
> -----Original Message-----
> From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
> Sent: Friday, September 29, 2023 1:46 AM
> To: Jason Sterne (Nokia) <jason.ste...@nokia.com>
> Cc: Reshad Rahman <res...@yahoo.com>; Kent Watsen <k...@watsen.net>;
> netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
> (from Key Issue #1)
>
>
> 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.
>
>
>
> Jason,
>
> the must/should change is technically a change of the language. We can
> do a short RFC to do that so that we get unstuck and oour AD allows us
> again to publish YANG modules where bug fixes or alignment with other
> modeled technologies is desirable.
>
> Adding decorations that can be ignored is something one can do with
> YANG extensions. However, once such extensions change the behaviour
> of YANG language constructs, we get into muddy waters.
>
> I prefer to clearly separate changes of the language from additional
> decorations that can be ignored and do not influence the behaviour of
> YANG implementations (i.e., they can be ignored).
>
> /js
>
> On Thu, Sep 28, 2023 at 08:57:42PM +0000, Jason Sterne (Nokia) wrote:
> > Hi all,
> >
> > IMO - We've already started moving out of the "stuck" situation. We no
> > longer
> have to debate whether a new YANG 1.2 is needed for allowing an NBC change.
> That will be the end of a big distraction and circular discussions for the WG.
> >
> > I'm not so convinced we want to rush and do a separate RFC just for that one
> part of Module Versioning (and one part of the original versioning
> requirements).
> It is a key/critical part, but we should continue discussing what other parts
> we'd
> want to also tackle as part of the "first" versioning RFC.
> >
> > I'm very doubtful we should relax MUST to SHOULD NOT without also at least
> making the rev:non-backwards-compatible marker mandatory (as per Module
> Versioning). The marking is a key part of making this all better for
> consumers of
> modules and clients (one of the main problems is the current silent NBC
> changes
> happening).
> >
> > We should also clarify that marking an element as "status obsolete" is NBC.
> That has major impact on clients who are trying to continue using an old
> version
> of the module.
> >
> > (and there are likely at least a few other pieces from Module Versioning
> > that
> should be in a "first" RFC)
> >
> > Jason
> >
> > > -----Original Message-----
> > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen Schönwälder
> > > Sent: Thursday, September 28, 2023 9:12 AM
> > > To: Reshad Rahman <res...@yahoo.com>
> > > Cc: Kent Watsen <k...@watsen.net>; netmod@ietf.org
> > > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or
> > > errata
> > > (from Key Issue #1)
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > The truth is that we did bug fixes in the past. We now have maneuvered
> > > us into a situation where work is put on hold because we do not even
> > > do bug fixes anymore (and yes, I know, the line between bug fixes,
> > > alignment with moving targets and other changes is vague and needs to
> > > be decided on a case by case basis). The fastest way to get unstuck is
> > > to write this one page content RFC that changes MUST to SHOULD and
> > > then we at least get out of the being stuck situation.
> > >
> > > /js
> > >
> > > On Thu, Sep 28, 2023 at 01:00:23PM +0000, Reshad Rahman wrote:
> > > > As a client (consumer of models), I do not want only the MUST -> SHOULD
> > > change, IMO that would be worse than the current situation.
> > > > Regards,Reshad.
> > > > On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen
> > > <k...@watsen.net> wrote:
> > > >
> > > > This was my thought as well, that it would be best to have the
> > > > smallest-
> possible
> > > draft update 6020/7950. That way, when someone follows the “Updated”
> links,
> > > they’re not overloaded with material that could’ve been left out.
> > > > Jason was saying that just doing MUST/SHOULD by alone isn’t great, that
> > > > at
> > > least the "rev:non-backwards-compatible” extension statement should be
> > > included and, by extension I suppose, the rules for editing the revision
> > > history.
> > > Presumably revision labels could be left out. IDK what minimal is
> > > possible.
> > > > K. // contributor
> > > >
> > > >
> > > >
> > > > On Sep 27, 2023, at 7:06 PM, Rodney Cummings
> > > <rodney_cummings_...@hotmail.com> wrote:
> > > >
> > > >
> > > > It is easy to write a short RFC updating RFC 7950, changing one sentence
> from
> > > MUST to SHOULD.
> > > >
> > > >
> > > > I agree. I found that I cannot enter a response to the poll, because I
> > > > disagree
> > > with both Option 1 and Option 2.
> > > >
> > > > My concern is that there are many people out there who are implementing
> > > YANG, but who do not follow discussions on this mailing list. I'm
> > > concerned
> that
> > > there is a serious risk that those people will interpret the change from
> > > MUST
> to
> > > SHOULD as "backward compatibility is irrelevant for YANG". We all know
> > > that
> the
> > > concern is about bug fixes and so on, but without explaining that in a
> > > short and
> > > focused manner (i.e., the short RFC described above), that will be lost
> > > in the
> noise
> > > of the larger draft-ietf-netmod-yang-module-versioning change.
> > > >
> > > > draft-ietf-netmod-yang-module-versioning is a great draft, but I think
> > > > it
> should
> > > move forward as an independent RFC, distinct from the MUST/SHOULD
> change.
> > > >
> > > > Rodney Cummings
> > > >
> > > > -----Original Message-----
> > > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen
> Schönwälder
> > > > Sent: Tuesday, September 26, 2023 5:24 PM
> > > > To: Jason Sterne (Nokia) <jason.ste...@nokia.com>
> > > > Cc: netmod@ietf.org
> > > > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or
> > > > errata
> > > (from Key Issue #1)
> > > >
> > > > It is easy to write a short RFC updating RFC 7950, changing one sentence
> from
> > > MUST to SHOULD. This is inline with the goal to not change the language,
> > > i.e.,
> to
> > > keep the version numbers.
> > > >
> > > > /js
> > > >
> > > > On Tue, Sep 26, 2023 at 03:00:19PM +0000, Jason Sterne (Nokia) wrote:
> > > >
> > > > Hello NETMOD WG,
> > > >
> > > > We've had a poll going for a few weeks to determine if we require YANG
> > > > 1.2
> for
> > > allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC
> > > Approach").
> > > >
> > > > As part of that, some discussion has happened on the list around
> > > > potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if
> > > > rough consensus is reached for option 1 of the poll)
> > > >
> > > > 7-8 of us discussed this in the YANG Versioning weekly call group today.
> > > >
> > > > First of all: this question of mechanics (errata vs bis vs Module
> > > > Versioning
> draft)
> > > is orthogonal to the poll. Let's first and separately resolve the poll
> > > and confirm
> if
> > > we need YANG 1.2 or not (that's the fundamental question the poll is
> > > resolving
> -
> > > everything else is a subsequent issue to be discussed). We'll let the
> > > chairs
> confirm
> > > when/if rough consensus on the poll has been reached.
> > > >
> > > > But *if* the answer to the poll is option 1, then the weekly call group
> > > > was
> > > unanimous that we should not do an errata for RFC7950/6020 and we should
> not
> > > do a 7950/6020 bis. We should just continue with the Module Versioning
> > > draft
> > > which will update 7950 and 6020.
> > > >
> > > > The primary reason is that we shouldn't just change MUST NOT to SHOULD
> NOT
> > > without also tying it together with the mandatory top level rev:non-
> backwards-
> > > compatible extension when an NBC change is done. Changing the NBC rule to
> > > SHOULD NOT needs to be in the same RFC as the mandatory rev:non-
> backwards-
> > > compatible tag.
> > > >
> > > > Other reasons:
> > > >
> > > > * an errata probably isn't correct since this isn't fixing an intent
> > > > that was
> > > present back when 7950 was written (it was clearly the intent at the time
> > > to
> > > block NBC changes)
> > > > * a bis would be odd without actually introducing other changes to
> > > > YANG
> and
> > > changing the version (this discussion is all based on "if the answer to
> > > the poll is
> > > option 1")
> > > >
> > > > Jason (he/him)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.i/
> > > >
> > >
> etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7C%7C22464d2aa09
> > > 441
> > > >
> > >
> f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6
> > > 38313
> > > >
> > >
> 638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > oiV2luM
> > > >
> > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgsZVlBTQt
> > > qJjR
> > > > tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D&reserved=0
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > > --
> > > 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
