+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 <netmod-boun...@ietf.org> On Behalf Of Jason Sterne (Nokia) > Sent: Monday, October 2, 2023 4:06 PM > To: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Cc: Kent Watsen <k...@watsen.net>; netmod@ietf.org > 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 > > <jschoenwaelder@constructor.university<mailto:jschoenwaelder@constructor.university>> > > Sent: Friday, September 29, 2023 1:46 AM > > To: Jason Sterne (Nokia) > > <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> > > Cc: Reshad Rahman <res...@yahoo.com<mailto:res...@yahoo.com>>; Kent Watsen > <k...@watsen.net<mailto:k...@watsen.net>>; > > netmod@ietf.org<mailto: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<mailto: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<mailto:res...@yahoo.com>> > > > > Cc: Kent Watsen <k...@watsen.net<mailto:k...@watsen.net>>; > > > > netmod@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jason.ste...@nokia.com>> > > > > > Cc: netmod@ietf.org<mailto: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<mailto:netmod@ietf.org> > > > > > 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: +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 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > > > > 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<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<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
