Jan,
I need to see the text. Using the existing versioning draft as a base
for this minimal solution scares me since this document went over
board. I need to see the text that details in which situations an NBC
change is allowed. I need to see the definition of the extension to
mark NBC changes. Only then I can tell whether we made progress.
If the WG does draft-schoenw-netmod-yang-relaxed-versioning-00 without
the import statement change (section 2), which was the reason to bump
the YANG language version number, then I am OK.
/js
On Tue, Oct 03, 2023 at 05:06:42PM +0000, Jan Lindblad (jlindbla) wrote:
> Jürgen,
>
> Thanks for the clarifications. It seems to me we're in complete agreement
> here.
>
> Here are the use cases I can think of:
> a) Tools that don't care about modules being backwards-compatible are fine.
> They will see good-old 7950 and 6020 YANG modules which are supposed to be
> backwards compatible, but sometimes are not. Occasionally they will see an
> unknown extension statement that they ignore.
> b) Tools which flag YANG modules that are not backwards compatible and are
> unaware of the extension statement will flag all incompatibilities as errors.
> Not ideal, but an uncommon case that is pretty easy to handle in practice.
> c) Tools which flag YANG modules that are not backwards compatible and are
> *aware* of the extension statement will flag incompatibilities without proper
> markup as errors, and allow the rest. This is great.
> d) 7950 and 6020 module authors are (theoretically) bound by the strict sec
> 11 and sec 10 backwards compatibility rules, like today.
> e) Module authors that need to introduce backwards incompatible changes may
> do so provided some appropriate extension statement defined in an upcoming
> document is applied.
>
> To me, this makes sense. If it does to you too, Jürgen, that would certainly
> make me happy.
>
> Best Regards,
> /jan
>
>
>
>
> On 2 Oct 2023, at 18:06, Jürgen Schönwälder
> <jschoenwaelder@constructor.university> wrote:
>
> RFC 7950 is clear that extensions must be designed such that they can
> be ignored by YANG parsers and tools.
>
> If you use 'mandatory, are you talking about 'mandatory' in an RFC
> 8407 sense (and not in an YANG language sense)? The difference here is
> between 'mandatory to use by module authors' versus 'mandatory to be
> understood by tools'.
>
> /js
>
> On Mon, Oct 02, 2023 at 03:52:00PM +0000, Jason Sterne (Nokia) wrote:
> 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/>
>
> --
> 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/>
>
--
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
