Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
Jürgen, Fair enough. We'll discuss more later then. Thanks for providing quick feedback and an outline of what you see as favorable. Best Regards, /jan On 3 Oct 2023, at 19:32, Jürgen Schönwälder wrote: 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 +, 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 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 +, 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 beli
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 +, 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 > 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 +, 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 >
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 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 +, 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 b
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 > implementor
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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. > > > > &g
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 a
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
+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<mailto:netmod@ietf.org> > > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or > > errata (from Key Issue #1) > > > > > > CAUTION: This is an external email. Please be very careful when > > clicking links or opening attachments. See the URL nok.it/ext for additional > information. > > > > > > > > Jason, > > > > the must/should change is technically a change of the language. We can > > do a short RFC to do that so that we get unstuck and oour AD allows us > > again to publish YANG modules where bug fixes or alignment with other > > modeled technologies is desirable. > > > > Adding decorations that can be ignored is something one can do with > > YANG extensions. However, once such extensions change the behaviour > > of YANG language constructs, we get into muddy waters. > > > > I prefer to clearly separate changes of the language from additional > > decorations that can be ignored and do not influence the behaviour of > > YANG implementations (i.e., they can be ignored). > > > > /js > > > > On Thu, Sep 28, 2023 at 08:57:42PM +, 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
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 >
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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<mailto:netmod@ietf.org> > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata > (from Key Issue #1) > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > The truth is that we did bug fixes in the past. We now have maneuvered > us into a situation where work is put on hold because we do not even > do bug fixes anymore (and yes, I know, the line between bug fixes, > alignment with moving targets and other changes is vague and needs to > be decided on a case by case basis). The fastest way to get unstuck is > to write this one page content RFC that changes MUST to SHOULD and > then we at least get out of the being stuck situation. > > /js > > On Thu, Sep 28, 2023 at 01:00:23PM +, 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 ch
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 up
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 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 &g
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 > 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 > >
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 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
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 &
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 26, 2023 at 03:00:19PM +, 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)
>
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 26, 2023 at 03:00:19PM +, 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=05%7C01%7C%7C22464d2aa09441
f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435%7C1%7C0%7C638313
638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DgsZVlBTQtqJjR
tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D=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 mai
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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 mailto:netmod-boun...@ietf.org>> On
> Behalf Of Jürgen Schönwälder
> Sent: Tuesday, September 26, 2023 5:24 PM
> To: Jason Sterne (Nokia) <mailto:jason.ste...@nokia.com>>
> Cc: netmod@ietf.org <mailto:netmod@ietf.org>
> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
> (from Key Issue #1)
>
> It is easy to write a short RFC updating RFC 7950, changing one sentence from
> MUST to SHOULD. This is inline with the goal to not change the language,
> i.e., to keep the version numbers.
>
> /js
>
> On Tue, Sep 26, 2023 at 03:00:19PM +, 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
>> <http://etf.org/>%2Fmailman%2Flistinfo%2Fnetmod=05%7C01%7C%7C22464d2aa09441
>> f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435%7C1%7C0%7C638313
>> 638956186415%7CUnknown%7CTWFpbG
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.
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 26, 2023 at 03:00:19PM +, 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=05%7C01%7C%7C22464d2aa09441
> f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435%7C1%7C0%7C638313
> 638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DgsZVlBTQtqJjR
> tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D=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
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 +, 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.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
[netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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.ietf.org/mailman/listinfo/netmod
