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
