Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

["Jason Sterne (Nokia)" <[e-mail]>]

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 <[e-mail]>
> Sent: Monday, October 2, 2023 11:45 AM
> To: Jan Lindblad (jlindbla) <[e-mail]>
> Cc: Jason Sterne (Nokia) <[e-mail]>; Kent Watsen
> <[e-mail]>; [e-mail]
> 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
> <[e-mail]> 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 <[e-mail]> On Behalf Of Jürgen Schönwälder
> > Sent: Thursday, September 28, 2023 9:12 AM
> > To: Reshad Rahman <[e-mail]>
> > Cc: Kent Watsen <[e-mail]>; [e-mail]
> > 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
> > <[e-mail]> 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
> > <[e-mail]> 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 <[e-mail]> On Behalf Of Jürgen Schönwälder
> > Sent: Tuesday, September 26, 2023 5:24 PM
> > To: Jason Sterne (Nokia) <[e-mail]>
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > Jürgen Schönwälder              Constructor University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Jürgen Schönwälder              Constructor University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>