Mandatory to be used by module authors.
Tools can ignore them as you say.
> -----Original Message-----
> From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
> Sent: Monday, October 2, 2023 12:07 PM
> To: Jason Sterne (Nokia) <jason.ste...@nokia.com>
> Cc: Jan Lindblad (jlindbla) <jlind...@cisco.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.
>
>
>
> 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/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
