Re: [netmod] Poll on YANG Versioning NBC Approach

[Lou Berger]

WG,

Based on the very good discussion on list and the opinions recorded on 
the poll, the Chairs want to state that the WG has agreed to:


"OPTION 1. Publish an RFC based on 
draft-ietf-netmod-yang-module-versioning that updates both YANG 1.0 (RFC 
6020) and YANG 1.1 (RFC 7950) to allow YANG modules to be modified with 
non-backwards-compatible changes – This option does not change the YANG 
version number."


There remain open issues from the last call and there continues to be be 
good discussion on the poll and related to the document. We look to the 
document Editors to continue to move the document to address the open 
issues and gauge their understanding of WG position on this document. 
Once the document is ready, there will be an additional, and hopefully 
final, WG LC.


Kent and Lou

On 9/11/2023 6:39 PM, Kent Watsen wrote:

WG,

Please help the YANG-versioning effort move forward by participating 
in the following poll:


  - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login 
required)


Kent and Lou


___
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

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

[Jason Sterne (Nokia)]

Mandatory to be used by module authors.

Tools can ignore them as you say.


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: Monday, October 2, 2023 12:07 PM
> To: Jason Sterne (Nokia) 
> Cc: Jan Lindblad (jlindbla) ; Kent Watsen
> ; 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 +, 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 
> > > Sent: Monday, October 2, 2023 11:45 AM
> > > To: Jan Lindblad (jlindbla) 
> > > Cc: Jason Sterne (Nokia) ; Kent Watsen
> > > ; 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 +, 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
> > >  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 

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

[Jürgen Schönwälder]

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 +, 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 
> > Sent: Monday, October 2, 2023 11:45 AM
> > To: Jan Lindblad (jlindbla) 
> > Cc: Jason Sterne (Nokia) ; Kent Watsen
> > ; 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 +, 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
> >  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 +, 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 

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

[Jason Sterne (Nokia)]

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 
> Sent: Monday, October 2, 2023 11:45 AM
> To: Jan Lindblad (jlindbla) 
> Cc: Jason Sterne (Nokia) ; Kent Watsen
> ; 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 +, 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
>  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 +, 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 

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

[Sergio Belotti (Nokia)]

+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  On Behalf Of Jason Sterne (Nokia)

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

> To: Jürgen Schönwälder 

> Cc: Kent Watsen ; 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 
> > mailto:jschoenwaelder@constructor.university>>

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

> > To: Jason Sterne (Nokia) 
> > mailto:jason.ste...@nokia.com>>

> > Cc: Reshad Rahman mailto:res...@yahoo.com>>; Kent Watsen

> mailto: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.

> >

> >

> >

> > 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 +, 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 

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

[Jürgen Schönwälder]

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 +, 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 
>  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 +, 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  On Behalf Of Jürgen Schönwälder
> Sent: Thursday, September 28, 2023 9:12 AM
> To: Reshad Rahman 
> Cc: Kent Watsen ; 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 +, Reshad Rahman wrote:
> As a client (consumer of models), I do not want only the 

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

[Jürgen Schönwälder]

On Mon, Oct 02, 2023 at 02:20:04PM +, Rob Wilton (rwilton) wrote:
> 
> Hence my proposal is to reject this erratum, but perhaps Jürgen you can 
> update your copy of rfc-6991bis to make these consistent please?  And yes, I 
> appreciate that I need to finish processing my AD review of your doc.
>

I have removed all prefixes from type statement arguments that refer
to locally defined types.

/js

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Joe Clarke (jclarke)]

I was going to say something similar.  We agreed on a set of requirements ahead 
of the module versioning and other work that included a mechanism that would 
indicate that an NBC change had been made.  Simply allowing them without it 
would more chaotic to consumers.

Joe

From: netmod  on behalf of Reshad Rahman 

Date: Monday, October 2, 2023 at 10:11
To: Jürgen Schönwälder , Jason Sterne 
(Nokia) 
Cc: Kent Watsen , netmod@ietf.org 
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata 
(from Key Issue #1)
+1 Jason. From an IETF process pov, yes the most expedient thing to do is to 
replace MUST with SHOULD. While this may be good for the IETF, it makes things 
worse for consumers/clients of YANG models: it'd allow NBC changes without any 
indication that NBC changes have been made!

Regards,
Reshad.

On Thursday, September 28, 2023, 04:57:46 PM EDT, 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 mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Jürgen Schönwälder
> Sent: Thursday, September 28, 2023 9:12 AM
> To: Reshad Rahman mailto:res...@yahoo.com>>
> Cc: Kent Watsen mailto: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 +, 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
> 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
> 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.
> >
> > 

[netmod] [Errata Held for Document Update] RFC7317 (6245)

[RFC Errata System]

The following errata report has been held for document update 
for RFC7317, "A YANG Data Model for System Management". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6245

--
Status: Held for Document Update
Type: Technical

Reported by: Maurizio Brigandi' 
Date Reported: 2020-07-29
Held by: Rob Wilton (IESG)

Section: 6

Original Text
-
 leaf-list user-authentication-order {
   type identityref {
 base authentication-method;
   }
   must '(. != "sys:radius" or ../../radius/server)' 



Corrected Text
--
 leaf-list user-authentication-order {
   type identityref {
 base authentication-method;
   }
   must '(not(. = "sys:radius") or ../../radius/server)'
 

Notes
-
As indicated in https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans

the following expression comparing a node-set with a string

   . != "sys:radius"

is true if at least one node in the node-set satisfies the boolean expression.

This is not the intention of the "must" condition.

It is necessary to use not(. = "sys:radius") to achieve the right intention of 
the check.

This errata has been marked as "Held for Document Update" because it requires a 
new revision of the YANG module to be published, and hence a new RFC.

--
RFC7317 (draft-ietf-netmod-system-mgmt-16)
--
Title   : A YANG Data Model for System Management
Publication Date: August 2014
Author(s)   : A. Bierman, M. Bjorklund
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jan Lindblad (jlindbla)]

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 
 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 +, 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  On Behalf Of Jürgen Schönwälder
Sent: Thursday, September 28, 2023 9:12 AM
To: Reshad Rahman 
Cc: Kent Watsen ; 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 +, 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
 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
 wrote:


It is easy to write a short RFC updating RFC 7950, changing one sentence from
MUST 

[netmod] [Errata Verified] RFC7951 (7020)

[RFC Errata System]

The following errata report has been verified for RFC7951,
"JSON Encoding of Data Modeled with YANG". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7020

--
Status: Verified
Type: Technical

Reported by: Jernej Tuljak 
Date Reported: 2022-07-11
Verified by: Rob Wilton (IESG)

Section: 6.8

Original Text
-
An "identityref" value is represented as a string -- the name of an
identity.  If the identity is defined in a module other than the leaf
node containing the identityref value, the namespace-qualified form
(Section 4) MUST be used.  Otherwise, both the simple and namespace-
qualified forms are permitted.

Corrected Text
--
An "identityref" value is represented as a string -- the name of an
identity.  If the identity is defined in a module other than the leaf or
leaf-list node containing the identityref value, the namespace-qualified
form (Section 4) MUST be used.  Otherwise, both the simple and namespace-
qualified forms are permitted.

Notes
-
The original text omitted leaf-list nodes, which may also be of "identityref" 
type.

--
RFC7951 (draft-ietf-netmod-yang-json-10)
--
Title   : JSON Encoding of Data Modeled with YANG
Publication Date: August 2016
Author(s)   : L. Lhotka
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

[Rob Wilton (rwilton)]

Hi,

Looking at this erratum, I agree that it would be better that the module prefix 
is used consistently for references to other types within the same module, but 
the existing YANG is not wrong.

In YANG, I generally expect prefixes are used when referencing data nodes or 
types in other imported modules, hence without a prefix I would naturally 
assume that the types/data nodes either exist in the current module or they are 
part of the set of primitive types.  Given there is only a small set of 
primitive types, I think that it is reasonably easy to differentiate between 
these two sets without needing the extra prefix.

Hence my proposal is to reject this erratum, but perhaps Jürgen you can update 
your copy of rfc-6991bis to make these consistent please?  And yes, I 
appreciate that I need to finish processing my AD review of your doc.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Monday, September 25, 2023 12:25 PM
> To: David Martínez García 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
> 
> Interesting. I would have removed all prefixes that are not strictly
> necessary. Why do you think having the prefixes is a good thing?
> 
> /js
> 
> On Sat, Sep 23, 2023 at 10:34:21AM +0200, David Martínez García wrote:
> > Hello,
> >
> > > Using the prefix is perhaps redundant but surely not wrong.
> >
> > Yes, I definetely agree with this.
> >
> > > Which consistency are you looking for, use of prefixes only when
> > > absolutely necessary, or always use prefixes?
> >
> > My proposal is to always use prefixes when defining typedefs that point to
> other typedefs different than the base/primitive ones (such as string, uint32,
> enumeration, etc.).
> >
> > Thank you.
> >
> > - David.
> 
> --
> 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 
> 
> ___
> 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

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

[Reshad Rahman]

 +1 Jason. From an IETF process pov, yes the most expedient thing to do is to 
replace MUST with SHOULD. While this may be good for the IETF, it makes things 
worse for consumers/clients of YANG models: it'd allow NBC changes without any 
indication that NBC changes have been made!
Regards,Reshad.
On Thursday, September 28, 2023, 04:57:46 PM EDT, 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  On Behalf Of Jürgen Schönwälder
> Sent: Thursday, September 28, 2023 9:12 AM
> To: Reshad Rahman 
> Cc: Kent Watsen ; 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 +, 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
>  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
>  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  On Behalf Of Jürgen Schönwälder
> > Sent: Tuesday, September 26, 2023 5:24 PM
> > To: Jason Sterne (Nokia) 
> > 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 

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

[Jason Sterne (Nokia)]

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 
> Sent: Friday, September 29, 2023 1:46 AM
> To: Jason Sterne (Nokia) 
> Cc: Reshad Rahman ; Kent Watsen ;
> 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 +, 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  On Behalf Of Jürgen Schönwälder
> > > Sent: Thursday, September 28, 2023 9:12 AM
> > > To: Reshad Rahman 
> > > Cc: Kent Watsen ; 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 +, Reshad Rahman wrote:
> > > >  As a client (consumer of models), I do not 

[netmod] I-D Action: draft-ietf-netmod-yang-semver-12.txt

[internet-drafts]

Internet-Draft draft-ietf-netmod-yang-semver-12.txt is now available. It is a
work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   YANG Semantic Versioning
   Authors: Joe Clarke
Robert Wilton
Reshad Rahman
Balazs Lengyel
Jason Sterne
Benoit Claise
   Name:draft-ietf-netmod-yang-semver-12.txt
   Pages:   27
   Dates:   2023-10-02

Abstract:

   This document specifies a scheme and guidelines for applying an
   extended set of semantic versioning rules to revisions of YANG
   artifacts (e.g., modules and packages).  Additionally, this document
   defines an RFC-compliant revision-label-scheme for this YANG
   semantic versioning scheme.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-12.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-semver-12

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod