Hi guys,
I think we'll need to be concrete about exactly which parts/extensions in
Module Versioning we're talking about. And it will likely be a slightly
different debate/discussion for each one.
I think the top level rev:non-backwards-compatible extension (and it being
mandatory) is important to bundle in with the NBC rule change to SHOULD NOT.
The rev:recommended-min is useful IMO but may not be critical to include &
bundle into the first versioning RFC. I still think it is useful for the YANG
ecosystem to have this though.
In Key Issue #2 we've raised the question about the rev:revision-label-scheme
already.
We should probably discuss each of these different & separate ideas/concepts in
individual threads though..
Jason
> -----Original Message-----
> From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
> Sent: Monday, October 2, 2023 11:45 AM
> To: Jan Lindblad (jlindbla) <jlind...@cisco.com>
> Cc: Jason Sterne (Nokia) <jason.ste...@nokia.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.
>
>
>
> Jan,
>
> I am certainly not against documenting NBC changes. This can be done
> using extension statements. Whether such extensions are defined in the
> same document or not at the end is a procedural question.
>
> That said, any extensions that go beyond something that can be safely
> ignored (e.g., extensions that for example influence how imports are
> resolved) do for me require a new YANG language version. It would help
> if people could acknowledge that we have agreement on this. Otherwise,
> I fear that we may repeat the same discussion we had again several
> months later.
>
> /js
>
> On Mon, Oct 02, 2023 at 02:34:31PM +0000, Jan Lindblad (jlindbla) wrote:
> > Jürgen, WG,
> >
> > I agree that a document that updates 7950 would be the preferred solution
> here, rather than a bis or errata.
> >
> > I'm quite attracted, however, by the idea to bundle the softening of 7950
> > with
> the requirement to document any incompatibilities introduced. This way, we get
> something useful back as we provide the needed flexibility. This is something
> I
> would have an easy time to explain to YANG practitioners, and it seems
> pragmatic
> to me.
> >
> > I agree completely that YANG extensions cannot change YANG at all for
> > clients
> that are not in on them. In the key issue #1 debate, however, I believe most
> people agreed that we should allow non-backwards compatible changes to some
> degree. To also require that any such non-backwards compatible changes are
> documented using an extension statement is not to muddy the waters in my
> opinion. Quite the contrary, actually. People's understanding of what's going
> on
> will likely be improved by this requirement, for clients and server
> implementors
> alike.
> >
> > We can certainly discuss the pros and cons of requiring users to document
> > their
> non-backwards compatible changes once we have the key issue #1 behind us.
> >
> > Best Regards,
> > /jan
> >
> >
> > On 29 Sep 2023, at 07:45, Jürgen Schönwälder
> <jschoenwaelder@constructor.university> wrote:
> >
> > 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<mailto: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
