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

["Sergio Belotti (Nokia)" <[e-mail]>]

+1

"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)."



Thanks

Sergio



> -----Original Message-----

> From: netmod <[e-mail]> On Behalf Of Jason Sterne (Nokia)

> Sent: Monday, October 2, 2023 4:06 PM

> To: Jürgen Schönwälder <[e-mail]>

> Cc: Kent Watsen <[e-mail]>; [e-mail]

> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata

> (from Key Issue #1)

>

> 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 <[e-mail]<mailto:[e-mail]>>

> > Sent: Friday, September 29, 2023 1:46 AM

> > To: Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]>>

> > Cc: Reshad Rahman <[e-mail]<mailto:[e-mail]>>; Kent Watsen

> <[e-mail]<mailto:[e-mail]>>;

> > [e-mail]<mailto:[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.

> >

> >

> >

> > 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]<mailto:[e-mail]>> On Behalf Of Jürgen

> > > > Schönwälder

> > > > Sent: Thursday, September 28, 2023 9:12 AM

> > > > To: Reshad Rahman <[e-mail]<mailto:[e-mail]>>

> > > > Cc: Kent Watsen <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Jürgen

> > Schönwälder

> > > > > Sent: Tuesday, September 26, 2023 5:24 PM

> > > > > To: Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]>>

> > > > > Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>

> > > > > https://www.i/

> > > > >

> > > >

> >

> etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7C%7C22464d2

> aa09

> > > > 441

> > > > >

> > > >

> >

> f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0

> %7C6

> > > > 38313

> > > > >

> > > >

> >

> 638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

> CJQIj

> > > > oiV2luM

> > > > >

> > > >

> >

> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgsZVl

> BTQt

> > > > 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]<mailto:[e-mail]>

> > > > > https://www.ietf.org/mailman/listinfo/netmod

> > > > >

> > > > > _______________________________________________

> > > > > netmod mailing list

> > > > > [e-mail]<mailto:[e-mail]>

> > > > > https://www.ietf.org/mailman/listinfo/netmod

> > > > > _______________________________________________

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

> > > >

> > > > _______________________________________________

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

> _______________________________________________

> netmod mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/netmod