Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Respectively submitted for your consideration, Having listened to the pros/cons of this issue at IETF 117, the mailing list, and some of the calls... IMHO... Option 1 is the option that best reflects current practice in several standards bodies and provides a way forward that is the least disruptive. Since there is a bis of 8407 being considered, extra warnings could be added there if the editor/community thought that helpful. This is not to encourage NBC, but simply acknowledge that NBC is a fact in some cases. Like has been pointed out in some threads, something can be allowed but not encouraged. Regards, -scott. From: netmod On Behalf Of Jason Sterne (Nokia) Sent: Monday, July 17, 2023 1:52 PM To: netmod@ietf.org Subject: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Hi all, At the request of the NETMOD chairs, and on behalf of the YANG Versioning weekly call group, here's a summary of Key Issue #1 for the versioning work (i.e. for the Module Versioning and YANG Semver WGLC). We'd like to suggest that the WG has a strong focus on deciding on this specific issue first. Then we'll move on to tackle other key issues. The idea is to try and avoid getting tangled in a web of multiple intertwined issues. Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or not? For now please avoid debating other issues in this thread (e.g. multiple vs single label schemes, whether YANG semver is a good scheme, etc). Let's focus on K1 and work towards a WG decision. ### K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Option 1 - Update RFC7950 to Allow NBC Changes --- - Module Versioning modifies 7950 to allow NBC changes - guidance that NBC changes SHOULD NOT be done (impact to user base) - rev:non-backwards-compatible is a YANG extension - introduction in published YANG does not impact current tooling (ignored until recognized) PROS: - address fundamental requirement of this versioning work (requirements doc) - allows gradual adoption in the industry. YANG authors can immeditately start publishing with the new extensions. - move faster to produce modules in the IETF (accept some errors/iteration) - address the liaison from external standards bodies in a reasonable timeframe - authors believe work is ready - broad vendor support - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) CONS: - perception that we're "cheating" by not bumping our own spec's version - Not fundamentally mandatory for clients or servers using YANG (mandatory for YANG claiming conformance to Module Versioning). Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow NBC changes --- - NBC changes only allowed in a new (future) version of YANG - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) - Content = Module Versioning + YANG Semver + very limited YANG NEXT items - rev:non-backwards-compatible tag is a language keyword - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't been updated - TBD how to handle small NBC changes in IETF in the short term (i.e. non conformance to 7950)? - RFC6991 bis - change the use/meaning of ip-address (or change datetime) - YANG date-and-time (because of SEDATE date string changes) PROS: - address fundamental requirement of this versioning work (requirements doc) - clear delineation of changes in the YANG language - consistent with philosophy that version number changes for significant changes in a spec (avoids concern that YANG is changing without bumping the version of YANG) - can do this with mandatory YANG keywords which helps increase conformance to the new rules CONS: - difficult to roll out in the industry. Tools need upgrading before they won't error on a YANG 1.2 module. - Authors can't publish YANG 1.2 until their users have upgraded their tools. Everyone has to move at once. - likely large delay in producing the work (unclear what would go into YANG 1.2, may not reach concensus easily on N items) - delay in follow up work (Packages, Schema Comparison, Version Selection) - continue dominating WG effort for longer (opportunity cost) Option 3 - Strict Adherence to Current RFC7950 Rules --- - IESG will be unable to approve any RFCs that make any changes to IETF YANG modules that don't strictly conform to those rules - RFC6991 bis would not be allowed to change the use/meaning of ip-address (or change datetime) - YANG date-and-time couldn't change (related to SEDATE date string changes) PROS: - clear rules for entire industry including IETF CONS: - doesn't address agreed/adopted requirements of YANG versioning work - incorrect assumption in too
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
On Mon, Jul 24, 2023 at 4:41 PM Christian Hopps wrote: > > Balázs Lengyel writes: > > > Hello Andy, > > > > I assume you are referring to the sentence “A new module revision MAY > > contain NBC changes” from the versioning draft. > > > > IMHO the authors agree that NBC changes are bad. They should be > > allowed but discouraged. > > That's what "SHOULD NOT" means. > > Indeed. https://datatracker.ietf.org/doc/html/rfc2119 It is clear that 'SHOULD NOT' is the correct term and 'MAY' does not even apply here. > Would a sentence like > > > > “A new module revision MAY but SHOULD NOT contain NBC changes … ” > > > > be OK ? > > > > I think the MAY part is also needed< because that is what we are > > introducing as new compared to 7950. > > IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD > NOT" allows a thing while discouraging it. > > Thanks, > Chris. > > Andy > > > > be agreeable? > > > > Regards Balazs > > > > > > > > From: Andy Bierman > > Sent: Sunday, 23 July, 2023 17:26 > > To: Balázs Lengyel > > Cc: Martin Björklund ; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC > > changes in YANG 1.0 & YANG 1.1 or not? > > > > > > > > > > > > > > > > On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel < > > balazs.leng...@ericsson.com> wrote: > > > > Hello Andy, > > > > In 3GPP we have endless debates about what is a bugfix. If the > > functionality will not work it is a bugfix. If it works in a bad > > way it is or maybe not a bugfix. If it works just in an ugly way > > is it a bugfix? > > > > Conclusion: it is not possible to define clear criteria about > > what is a bug and what is an improvement. > > > > > > > > > > > > It is easy to change MAY to SHOULD NOT in the versioning draft. > > > > > > > > IMO changing MUST NOT to MAY is unacceptable. > > > > The versioning draft is attempting to completely toss out all of the > > YANG update rules. > > > > Changing the normative text to SHOULD NOT instead of MAY does not > > require any specification of a bugfix. > > > > > > > > > > > > Regards Balazs > > > > > > > > > > > > Andy > > > > > > > > > > > > From: netmod On Behalf Of Andy Bierman > > Sent: Wednesday, 19 July, 2023 10:13 > > To: Martin Björklund > > Cc: netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC > > changes in YANG 1.0 & YANG 1.1 or not? > > > > > > > > > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund < > > mbj+i...@4668.se> wrote: > > > > What about Option 4 - Pragmatic Adherence to Current RFC7950 > > Rules > > > > > > > > > > > > This is the approach I also suggested on the mailing list. > > > > > > > > - As it works today; the IETF *has* published bugfixed > > modules that break the > > rules. (and many vendors do this as well) > > - (Possibly) Introduce rev:non-backwards-compatible > > > > This would allow 6991bis to update date-and-time to follow > > the updated > > semantics for RFC3339 timestamps (which imo is the only > > reasonable > > thing to do - the consuequences of this change is handled by > > SEDATE). > > > > > > > > > > > > The important thing in each case is to consider > > > > the expected impact on the real world and real deployments. > > > > > > > > IMO a bugfix should be OK, even if the rules in RFC 7950 say it > > is an NBC change. > > > > But this is not the same thing as changing the rules in a new > > document to shift the > > > > implementation burden to the client. > > > > > > > > This is only an IETF issue and the burden should be on a WG to > > convince the IESG and IETF > > > > that making the NBC change is a bugfix and should be allowed as a > > special case. > > > > > > > > > > > > > > /martin > > > > > > > > Andy &
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Balázs Lengyel writes:
Hello Andy,
I assume you are referring to the sentence “A new module revision MAY
contain NBC changes” from the versioning draft.
IMHO the authors agree that NBC changes are bad. They should be
allowed but discouraged.
That's what "SHOULD NOT" means.
Would a sentence like
“A new module revision MAY but SHOULD NOT contain NBC changes … ”
be OK ?
I think the MAY part is also needed< because that is what we are
introducing as new compared to 7950.
IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD NOT"
allows a thing while discouraging it.
Thanks,
Chris.
be agreeable?
Regards Balazs
From: Andy Bierman
Sent: Sunday, 23 July, 2023 17:26
To: Balázs Lengyel
Cc: Martin Björklund ; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?
On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel <
balazs.leng...@ericsson.com> wrote:
Hello Andy,
In 3GPP we have endless debates about what is a bugfix. If the
functionality will not work it is a bugfix. If it works in a bad
way it is or maybe not a bugfix. If it works just in an ugly way
is it a bugfix?
Conclusion: it is not possible to define clear criteria about
what is a bug and what is an improvement.
It is easy to change MAY to SHOULD NOT in the versioning draft.
IMO changing MUST NOT to MAY is unacceptable.
The versioning draft is attempting to completely toss out all of the
YANG update rules.
Changing the normative text to SHOULD NOT instead of MAY does not
require any specification of a bugfix.
Regards Balazs
Andy
From: netmod On Behalf Of Andy Bierman
Sent: Wednesday, 19 July, 2023 10:13
To: Martin Björklund
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?
On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <
mbj+i...@4668.se> wrote:
What about Option 4 - Pragmatic Adherence to Current RFC7950
Rules
This is the approach I also suggested on the mailing list.
- As it works today; the IETF *has* published bugfixed
modules that break the
rules. (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible
This would allow 6991bis to update date-and-time to follow
the updated
semantics for RFC3339 timestamps (which imo is the only
reasonable
thing to do - the consuequences of this change is handled by
SEDATE).
The important thing in each case is to consider
the expected impact on the real world and real deployments.
IMO a bugfix should be OK, even if the rules in RFC 7950 say it
is an NBC change.
But this is not the same thing as changing the rules in a new
document to shift the
implementation burden to the client.
This is only an IETF issue and the burden should be on a WG to
convince the IESG and IETF
that making the NBC change is a bugfix and should be allowed as a
special case.
/martin
Andy
"Jason Sterne (Nokia)" wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the
YANG Versioning weekly call group, here's a summary of Key
Issue #1 for the versioning work (i.e. for the Module
Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on
deciding on this specific issue first. Then we'll move on to
tackle other key issues. The idea is to try and avoid getting
tangled in a web of multiple intertwined issues.
>
> Key Issue #1 is the following: Allow NBC changes in YANG
1.0 & YANG 1.1 or not?
>
> For now please avoid debating other issues in this thread
(e.g. multiple vs single label schemes, whether YANG semver
is a good scheme, etc). Let's focus on K1 and work towards a
WG decision.
>
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
>
> Option 1 - Update RFC7950 to Allow NBC Changes
>
---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to
user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact
current tooling (ignored until recognized)
> PROS:
> - address fundamental requirement of this versioning work
(requirements doc)
> - allows gra
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hello Andy, I assume you are referring to the sentence “A new module revision MAY contain NBC changes” from the versioning draft. IMHO the authors agree that NBC changes are bad. They should be allowed but discouraged. Would a sentence like “A new module revision MAY but SHOULD NOT contain NBC changes … ” be OK ? I think the MAY part is also needed< because that is what we are introducing as new compared to 7950. be agreeable? Regards Balazs From: Andy Bierman Sent: Sunday, 23 July, 2023 17:26 To: Balázs Lengyel Cc: Martin Björklund ; netmod@ietf.org Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel mailto:balazs.leng...@ericsson.com>> wrote: Hello Andy, In 3GPP we have endless debates about what is a bugfix. If the functionality will not work it is a bugfix. If it works in a bad way it is or maybe not a bugfix. If it works just in an ugly way is it a bugfix? Conclusion: it is not possible to define clear criteria about what is a bug and what is an improvement. It is easy to change MAY to SHOULD NOT in the versioning draft. IMO changing MUST NOT to MAY is unacceptable. The versioning draft is attempting to completely toss out all of the YANG update rules. Changing the normative text to SHOULD NOT instead of MAY does not require any specification of a bugfix. Regards Balazs Andy From: netmod mailto:netmod-boun...@ietf.org>> On Behalf Of Andy Bierman Sent: Wednesday, 19 July, 2023 10:13 To: Martin Björklund mailto:mbj%2bi...@4668.se>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund mailto:mbj%2bi...@4668.se>> wrote: What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules This is the approach I also suggested on the mailing list. - As it works today; the IETF *has* published bugfixed modules that break the rules. (and many vendors do this as well) - (Possibly) Introduce rev:non-backwards-compatible This would allow 6991bis to update date-and-time to follow the updated semantics for RFC3339 timestamps (which imo is the only reasonable thing to do - the consuequences of this change is handled by SEDATE). The important thing in each case is to consider the expected impact on the real world and real deployments. IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC change. But this is not the same thing as changing the rules in a new document to shift the implementation burden to the client. This is only an IETF issue and the burden should be on a WG to convince the IESG and IETF that making the NBC change is a bugfix and should be allowed as a special case. /martin Andy "Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi, OLD: A new module revision MAY contain NBC changes, e.g., the semantics of an existing data-node definition MAY be changed in an NBC manner without requiring a new data-node definition with a new identifier. NEW: A new module revision SHOULD NOT contain NBC changes, e.g., the semantics of an existing data-node definition SHOULD NOT be changed in an NBC manner without requiring a new data-node definition with a new identifier. This allows Option 4 since SHOULD NOT will require an exception review to get an RFC published. Andy On Sun, Jul 23, 2023 at 5:11 PM Balázs Lengyel wrote: > Hello, > > I am writing this as > > - Balazs Lengyel one of the authors, but also as > > - an Ericsson guy and also as > > - a delegate of 3GPP, which requested a better versioning scheme in a > reasonably > > fast timeline. 3GPP represents both vendors and operators, so in this > last > > role I am sitting on both side of the fence. > > I strongly support option 1 - modifying 7950 to allow NBC changes and > > introducing something like Semver. > > - We need this soon and the other alternatives will take a longer time. > > - we need it for the current YANG models too, not just for YANG 1.2 or 2 > models > > - We are already today doing backwards incompatible updates. We would like > to have > > that aligned with IETF. > > - as one of the authors I believe the work is ready and reasonably good > > - I believe adapting the tooling for a few new extensions is much less > work > > than adapting to a new YANG version > > Option 2 will take a long time to specify, implement and roll out. During > this time > > other non-standard solutions will proliferate; messy solutions, like just > > ignoring the current RFC7950 rules, will be used more and more. > > Option 3 just ignores the real world. > > NBC changes are happening. There are SDOs that value speed over final > quality > > and role out a new version of the modules every few months. These can not > > live without some NBC changes. > > A more fine grained versioning system is required. > > > > Regards Balazs > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Thursday, 20 July, 2023 18:52 > *To:* Jason Sterne (Nokia) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > > > On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) < > jason.ste...@nokia.com> wrote: > > We considered this approach as well in the weekly calls but in the end > felt that was just dodging the problem. We have a set of “MUST” rules that > we know need to occasionally be broken. Shouldn’t we officialize this so > our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? > > > > It isn’t just an IETF issue. These same exceptions occur in vendor models, > 3GPP, etc. There are times when making the NBC change is the reasonable way > to go. > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with > > > > I do not support these changes in any version of YANG. > > The advice to the community is non-specific and obviously not backward > compatible with RFC 7950. > > The new advice is that any change at all in a YANG module is now allowed. > > Instead of normative rules, RFC 7950 simply advises whether the optional > 'non-backwards-compatible' extension could be applied or not. > > This is not a good change, especially on top of YANG 1.1. > > > > I could see if specific MUST NOT rules were changed to SHOULD NOT instead. > > A blank check using the current "MAY" (3.1, para 2) is not a good idea. > > > > > > Jason > > > > Andy > > > > > > *From:* Andy Bierman > *Sent:* Wednesday, July 19, 2023 1:13 PM > *To:* Martin Björklund > *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-688efc90f7cb3f03=1=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6=http%3A%2F%2Fnok.it%2Fext> > for additional information. > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote: > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > > > > > This is the a
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel wrote: > Hello Andy, > > In 3GPP we have endless debates about what is a bugfix. If the > functionality will not work it is a bugfix. If it works in a bad way it is > or maybe not a bugfix. If it works just in an ugly way is it a bugfix? > > Conclusion: it is not possible to define clear criteria about what is a > bug and what is an improvement. > It is easy to change MAY to SHOULD NOT in the versioning draft. IMO changing MUST NOT to MAY is unacceptable. The versioning draft is attempting to completely toss out all of the YANG update rules. Changing the normative text to SHOULD NOT instead of MAY does not require any specification of a bugfix. Regards Balazs > Andy > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* Wednesday, 19 July, 2023 10:13 > *To:* Martin Björklund > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote: > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > > > > > This is the approach I also suggested on the mailing list. > > > > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > > > > > The important thing in each case is to consider > > the expected impact on the real world and real deployments. > > > > IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC > change. > > But this is not the same thing as changing the rules in a new document to > shift the > > implementation burden to the client. > > > > This is only an IETF issue and the burden should be on a WG to convince > the IESG and IETF > > that making the NBC change is a bugfix and should be allowed as a special > case. > > > > > > > /martin > > > > Andy > > > > > "Jason Sterne (Nokia)" wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The > idea is to try and avoid getting tangled in a web of multiple intertwined > issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple > vs single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > --- > > - NBC changes only allowed in a new (future) ve
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hello, I am writing this as - Balazs Lengyel one of the authors, but also as - an Ericsson guy and also as - a delegate of 3GPP, which requested a better versioning scheme in a reasonably fast timeline. 3GPP represents both vendors and operators, so in this last role I am sitting on both side of the fence. I strongly support option 1 - modifying 7950 to allow NBC changes and introducing something like Semver. - We need this soon and the other alternatives will take a longer time. - we need it for the current YANG models too, not just for YANG 1.2 or 2 models - We are already today doing backwards incompatible updates. We would like to have that aligned with IETF. - as one of the authors I believe the work is ready and reasonably good - I believe adapting the tooling for a few new extensions is much less work than adapting to a new YANG version Option 2 will take a long time to specify, implement and roll out. During this time other non-standard solutions will proliferate; messy solutions, like just ignoring the current RFC7950 rules, will be used more and more. Option 3 just ignores the real world. NBC changes are happening. There are SDOs that value speed over final quality and role out a new version of the modules every few months. These can not live without some NBC changes. A more fine grained versioning system is required. Regards Balazs From: netmod On Behalf Of Andy Bierman Sent: Thursday, 20 July, 2023 18:52 To: Jason Sterne (Nokia) Cc: netmod@ietf.org Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) mailto:jason.ste...@nokia.com>> wrote: We considered this approach as well in the weekly calls but in the end felt that was just dodging the problem. We have a set of “MUST” rules that we know need to occasionally be broken. Shouldn’t we officialize this so our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? It isn’t just an IETF issue. These same exceptions occur in vendor models, 3GPP, etc. There are times when making the NBC change is the reasonable way to go. https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with I do not support these changes in any version of YANG. The advice to the community is non-specific and obviously not backward compatible with RFC 7950. The new advice is that any change at all in a YANG module is now allowed. Instead of normative rules, RFC 7950 simply advises whether the optional 'non-backwards-compatible' extension could be applied or not. This is not a good change, especially on top of YANG 1.1. I could see if specific MUST NOT rules were changed to SHOULD NOT instead. A blank check using the current "MAY" (3.1, para 2) is not a good idea. Jason Andy From: Andy Bierman mailto:a...@yumaworks.com>> Sent: Wednesday, July 19, 2023 1:13 PM To: Martin Björklund mailto:mbj%2bi...@4668.se>> Cc: Jason Sterne (Nokia) mailto:jason.ste...@nokia.com>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-688efc90f7cb3f03=1=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6=http%3A%2F%2Fnok.it%2Fext> for additional information. On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund mailto:mbj%2bi...@4668.se>> wrote: What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules This is the approach I also suggested on the mailing list. - As it works today; the IETF *has* published bugfixed modules that break the rules. (and many vendors do this as well) - (Possibly) Introduce rev:non-backwards-compatible This would allow 6991bis to update date-and-time to follow the updated semantics for RFC3339 timestamps (which imo is the only reasonable thing to do - the consuequences of this change is handled by SEDATE). The important thing in each case is to consider the expected impact on the real world and real deployments. IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC change. But this is not the same thing as changing the rules in a new document to shift the implementation burden to the client. This is only an IETF issue and the burden should be on a WG to convince the IESG and IETF that making the NBC change is a bugfix and should be allowed as a special case. /martin Andy "Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hello Andy, In 3GPP we have endless debates about what is a bugfix. If the functionality will not work it is a bugfix. If it works in a bad way it is or maybe not a bugfix. If it works just in an ugly way is it a bugfix? Conclusion: it is not possible to define clear criteria about what is a bug and what is an improvement. Regards Balazs From: netmod On Behalf Of Andy Bierman Sent: Wednesday, 19 July, 2023 10:13 To: Martin Björklund Cc: netmod@ietf.org Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund mailto:mbj%2bi...@4668.se>> wrote: What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules This is the approach I also suggested on the mailing list. - As it works today; the IETF *has* published bugfixed modules that break the rules. (and many vendors do this as well) - (Possibly) Introduce rev:non-backwards-compatible This would allow 6991bis to update date-and-time to follow the updated semantics for RFC3339 timestamps (which imo is the only reasonable thing to do - the consuequences of this change is handled by SEDATE). The important thing in each case is to consider the expected impact on the real world and real deployments. IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC change. But this is not the same thing as changing the rules in a new document to shift the implementation burden to the client. This is only an IETF issue and the burden should be on a WG to convince the IESG and IETF that making the NBC change is a bugfix and should be allowed as a special case. /martin Andy "Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for clients or servers using YANG (mandatory > for YANG claiming conformance to Module Versioning). > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow > NBC changes > --- > - NBC changes only allowed in a new (future) version of YANG > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > - Content = Module Versioning + YANG Semver + very limited YANG NEXT items > - rev:non-backwards-compatible tag is a language keyword > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > - RFC6991 bis - change the use/meaning of ip-address (or change datetime) > - YANG date-and-time (because of SEDATE date string changes) > > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - clear delineation of changes in the YANG language > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bump
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) wrote: > We considered this approach as well in the weekly calls but in the end > felt that was just dodging the problem. We have a set of “MUST” rules that > we know need to occasionally be broken. Shouldn’t we officialize this so > our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? > > > > It isn’t just an IETF issue. These same exceptions occur in vendor models, > 3GPP, etc. There are times when making the NBC change is the reasonable way > to go. > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with I do not support these changes in any version of YANG. The advice to the community is non-specific and obviously not backward compatible with RFC 7950. The new advice is that any change at all in a YANG module is now allowed. Instead of normative rules, RFC 7950 simply advises whether the optional 'non-backwards-compatible' extension could be applied or not. This is not a good change, especially on top of YANG 1.1. I could see if specific MUST NOT rules were changed to SHOULD NOT instead. A blank check using the current "MAY" (3.1, para 2) is not a good idea. Jason > Andy > > > *From:* Andy Bierman > *Sent:* Wednesday, July 19, 2023 1:13 PM > *To:* Martin Björklund > *Cc:* Jason Sterne (Nokia) ; netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > *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. > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote: > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > > > > > This is the approach I also suggested on the mailing list. > > > > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > > > > > The important thing in each case is to consider > > the expected impact on the real world and real deployments. > > > > IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC > change. > > But this is not the same thing as changing the rules in a new document to > shift the > > implementation burden to the client. > > > > This is only an IETF issue and the burden should be on a WG to convince > the IESG and IETF > > that making the NBC change is a bugfix and should be allowed as a special > case. > > > > > > > /martin > > > > Andy > > > > > "Jason Sterne (Nokia)" wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The > idea is to try and avoid getting tangled in a web of multiple intertwined > issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple > vs single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
We considered this approach as well in the weekly calls but in the end felt that was just dodging the problem. We have a set of “MUST” rules that we know need to occasionally be broken. Shouldn’t we officialize this so our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? It isn’t just an IETF issue. These same exceptions occur in vendor models, 3GPP, etc. There are times when making the NBC change is the reasonable way to go. Jason From: Andy Bierman Sent: Wednesday, July 19, 2023 1:13 PM To: Martin Björklund Cc: Jason Sterne (Nokia) ; netmod@ietf.org Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? 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. On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund mailto:mbj%2bi...@4668.se>> wrote: What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules This is the approach I also suggested on the mailing list. - As it works today; the IETF *has* published bugfixed modules that break the rules. (and many vendors do this as well) - (Possibly) Introduce rev:non-backwards-compatible This would allow 6991bis to update date-and-time to follow the updated semantics for RFC3339 timestamps (which imo is the only reasonable thing to do - the consuequences of this change is handled by SEDATE). The important thing in each case is to consider the expected impact on the real world and real deployments. IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC change. But this is not the same thing as changing the rules in a new document to shift the implementation burden to the client. This is only an IETF issue and the burden should be on a WG to convince the IESG and IETF that making the NBC change is a bugfix and should be allowed as a special case. /martin Andy "Jason Sterne (Nokia)" mailto:jason.ste...@nokia.com>> wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for clients or servers using YANG (mandatory > for YANG claiming conformance to Module Versioning). > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow > NBC changes > --- > - NBC changes only allowed in a new (future) version of YANG > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > - Content = Module Versioning + YANG Semver + very limited YANG NEXT items > - rev:non-backwards-compatible tag is a language keyword > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > - RFC6991 bis - change the use/meaning of ip-address (or change datetime) > - YANG date-and-time (because of SEDATE date string changes) > > PROS: > -
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund wrote: > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > This is the approach I also suggested on the mailing list. > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > The important thing in each case is to consider the expected impact on the real world and real deployments. IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC change. But this is not the same thing as changing the rules in a new document to shift the implementation burden to the client. This is only an IETF issue and the burden should be on a WG to convince the IESG and IETF that making the NBC change is a bugfix and should be allowed as a special case. > /martin > Andy > > "Jason Sterne (Nokia)" wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The > idea is to try and avoid getting tangled in a web of multiple intertwined > issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple > vs single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > --- > > - NBC changes only allowed in a new (future) version of YANG > > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > > - Content = Module Versioning + YANG Semver + very limited YANG NEXT > items > > - rev:non-backwards-compatible tag is a language keyword > > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that > hasn't been updated > > - TBD how to handle small NBC changes in IETF in the short term (i.e. > non conformance to 7950)? > > - RFC6991 bis - change the use/meaning of ip-address (or change > datetime) > > - YANG date-and-time (because of SEDATE date string > changes) > > > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - clear delineation of changes in the YANG language > > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping the > version of YANG) > > - can do this with mandatory YANG keywords which helps increase > conformance to the new rules > > CONS: > > - difficult to roll out in the industry. Tools need upgrading before > they won't error on a YANG 1.2 module. > > - Authors can't publish YANG 1.2 until their users have upgraded their > tools. Everyone has to move at once. > > - likely large delay in producing the work (unclear what would go into > YANG 1.2, may not reach concensus easily on N items) > > - delay in follow up work (Packages, Schema Comparison, Version > Selection) > > - continue dominating WG effort for longer (opportunity cost) > > > > Option 3 - Strict Adherence to Current RFC7950 Rules > >
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi Martin, You may have just seen my comment to Juergen, but with an AD hat on, I think that what you propose is not a valid option. My understanding is that the IETF process does not allow an RFC to choose to ignore a MUST statement in another RFC for pragmatic reasons (I would DISCUSS on this and suspect that many other ADs would as well). If you are sometimes allowed to ignore the rule then one would correctly argue that would be a SHOULD not a MUST ... If the goal is to have the module update rules of RFC 7950 be interpreted differently then the only choices are to bis RFC 7950 or write another RFC that updates it. I currently allow the RFC 7950 module update rules to be interpreted pragmatically on the understanding that the RFC 7950 rules would be loosened to allow it. Regards, Rob > -Original Message- > From: netmod On Behalf Of Martin Björklund > Sent: 18 July 2023 04:48 > To: jason.ste...@nokia.com > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in > YANG 1.0 & YANG 1.1 or not? > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > > /martin > > "Jason Sterne (Nokia)" wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is > to try and avoid getting tangled in a web of multiple intertwined issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > --- > > - NBC changes only allowed in a new (future) version of YANG > > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > > - Content = Module Versioning + YANG Semver + very limited YANG NEXT > items > > - rev:non-backwards-compatible tag is a language keyword > > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > > - RFC6991 bis - change the use/meaning of ip-address (or change > datetime) > > - YANG date-and-time (because of SEDATE date string changes) > > > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - clear delineation of changes in the
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi Jürgen, WG, Writing as an author: I think that the authors, who have invested a lot of time and effort in this, are really just looking for a path forward to reach consensus, if that is possible. I don't think that presenting the 3 options was intended to mean that participants just have to choose 1, 2, or 3, but to try and highlight the main options that available and some of benefits/concerns that the authors have thought of when considering these options as a starting point for a discussion. There may be other choices and there may be pros/cons that we have missed. With an AD hat on: It would be really nice if we are able to discuss some of these at IETF 117, but I don’t know if you, Andy or Martin are planning on attending (local or remote)? Or, if timing doesn't work for IETF 117, then we could try and setup a set of virtual interim meetings (or even an in-person interim) if we thought that we could unblock and make progress ... My biggest concern here is that the WG doesn't reach any consensus on a way forward that has sufficient energy for the WG to find a solution. I still regard that my current AD position of allowing small breaking changes to IETF YANG modules (i.e., that don't strictly follow RFC 7950 section 11 rules, but where the likely harm is easily outweighed by the benefit), is valid only because the WG is working on a proper solution that enabled these changes to happen. E.g., if the WG conclusions ends up being that the RFC 7950 rules are fine as they are, and there is no problem here to be fixed, then my interpretation is that the IETF/IESG will also be required to strictly follow these rules. Rob > -Original Message- > From: netmod On Behalf Of Jürgen Schönwälder > Sent: 17 July 2023 11:50 > To: Jason Sterne (Nokia) > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in > YANG 1.0 & YANG 1.1 or not? > > Dear Jason, > > the three options come with a bunch of details that make it hard to > support any of them. I think what is needed is a dialog, not a choice > of given options (for a yet to be determined set of issues and options > to come). > > /js > > On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is > to try and avoid getting tangled in a web of multiple intertwined issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > --- > > - NBC changes only allowed in a new (future) version of YANG > > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > > - Content = Module Versioning + YANG Semver + very limited
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules - As it works today; the IETF *has* published bugfixed modules that break the rules. (and many vendors do this as well) - (Possibly) Introduce rev:non-backwards-compatible This would allow 6991bis to update date-and-time to follow the updated semantics for RFC3339 timestamps (which imo is the only reasonable thing to do - the consuequences of this change is handled by SEDATE). /martin "Jason Sterne (Nokia)" wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for clients or servers using YANG (mandatory > for YANG claiming conformance to Module Versioning). > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow > NBC changes > --- > - NBC changes only allowed in a new (future) version of YANG > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > - Content = Module Versioning + YANG Semver + very limited YANG NEXT items > - rev:non-backwards-compatible tag is a language keyword > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > - RFC6991 bis - change the use/meaning of ip-address (or change datetime) > - YANG date-and-time (because of SEDATE date string changes) > > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - clear delineation of changes in the YANG language > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping the > version of YANG) > - can do this with mandatory YANG keywords which helps increase conformance > to the new rules > CONS: > - difficult to roll out in the industry. Tools need upgrading before they > won't error on a YANG 1.2 module. > - Authors can't publish YANG 1.2 until their users have upgraded their tools. > Everyone has to move at once. > - likely large delay in producing the work (unclear what would go into YANG > 1.2, may not reach concensus easily on N items) > - delay in follow up work (Packages, Schema Comparison, Version Selection) > - continue dominating WG effort for longer (opportunity cost) > > Option 3 - Strict Adherence to Current RFC7950 Rules > --- > - IESG will be unable to approve any RFCs that make any changes to IETF YANG > modules that don't strictly conform to those rules > - RFC6991 bis would not be allowed to change the use/meaning of > ip-address (or change datetime) > - YANG date-and-time couldn't change (related to SEDATE date > string changes) > PROS: > - clear rules for entire industry including IETF > CONS: > - doesn't address agreed/adopted requirements of YANG versioning work > - incorrect assumption in tool chains, etc that NBC changes don't happen. > Silent failures. > > Jason (he/him) > ___ netmod mailing list netmod@ietf.org
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi Jason, IMHO, there are cases where NBC changes are unavoidable. With option 3 these cases will be managed (as they are already managed) in an uncontrolled manner so I would suggest not to adopt option 3. However, the NBC changes SHOULD NOT be done (impact to user base), unless really unavoidable. With option 1 and 2, we can clearly give this strong recommendation and manage the cases where NBC changes are unavoidable. I do not have any strong preference between option 1 or option 2 but I do believe we need to complete this work as quickly as possible. At the first glance option 1 seems faster but if option 2 is reducing the level of opposition, option 2 (if focused to only few changes) might end up to be faster than option 1 from an IETF standardization process timing It would also be good to get feedbacks about how difficult would be to upgrade the YANG toolchain to support YANG 1.2 My 2 cents Italo From: Jason Sterne (Nokia) Sent: lunedì 17 luglio 2023 19:52 To: netmod@ietf.org Subject: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Hi all, At the request of the NETMOD chairs, and on behalf of the YANG Versioning weekly call group, here's a summary of Key Issue #1 for the versioning work (i.e. for the Module Versioning and YANG Semver WGLC). We'd like to suggest that the WG has a strong focus on deciding on this specific issue first. Then we'll move on to tackle other key issues. The idea is to try and avoid getting tangled in a web of multiple intertwined issues. Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or not? For now please avoid debating other issues in this thread (e.g. multiple vs single label schemes, whether YANG semver is a good scheme, etc). Let's focus on K1 and work towards a WG decision. ### K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Option 1 - Update RFC7950 to Allow NBC Changes --- - Module Versioning modifies 7950 to allow NBC changes - guidance that NBC changes SHOULD NOT be done (impact to user base) - rev:non-backwards-compatible is a YANG extension - introduction in published YANG does not impact current tooling (ignored until recognized) PROS: - address fundamental requirement of this versioning work (requirements doc) - allows gradual adoption in the industry. YANG authors can immeditately start publishing with the new extensions. - move faster to produce modules in the IETF (accept some errors/iteration) - address the liaison from external standards bodies in a reasonable timeframe - authors believe work is ready - broad vendor support - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) CONS: - perception that we're "cheating" by not bumping our own spec's version - Not fundamentally mandatory for clients or servers using YANG (mandatory for YANG claiming conformance to Module Versioning). Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow NBC changes --- - NBC changes only allowed in a new (future) version of YANG - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) - Content = Module Versioning + YANG Semver + very limited YANG NEXT items - rev:non-backwards-compatible tag is a language keyword - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't been updated - TBD how to handle small NBC changes in IETF in the short term (i.e. non conformance to 7950)? - RFC6991 bis - change the use/meaning of ip-address (or change datetime) - YANG date-and-time (because of SEDATE date string changes) PROS: - address fundamental requirement of this versioning work (requirements doc) - clear delineation of changes in the YANG language - consistent with philosophy that version number changes for significant changes in a spec (avoids concern that YANG is changing without bumping the version of YANG) - can do this with mandatory YANG keywords which helps increase conformance to the new rules CONS: - difficult to roll out in the industry. Tools need upgrading before they won't error on a YANG 1.2 module. - Authors can't publish YANG 1.2 until their users have upgraded their tools. Everyone has to move at once. - likely large delay in producing the work (unclear what would go into YANG 1.2, may not reach concensus easily on N items) - delay in follow up work (Packages, Schema Comparison, Version Selection) - continue dominating WG effort for longer (opportunity cost) Option 3 - Strict Adherence to Current RFC7950 Rules --- - IESG will be unable to approve any RFCs that make any changes to IETF YANG modules that don't strictly conform to those rules - RFC6991 bis would not be allowed to change the use/meaning of ip-addres
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Jurgen, I/we certainly agree that discussion plays an important role in reaching consensus. We've reserved an hour for related discussion - which we are looking to set the stage for further discussions to close on the open points raised during LC. Again for your comments to the group on this topic, Lou and Kent -- On July 17, 2023 2:50:00 PM Jürgen Schönwälder wrote: Dear Jason, the three options come with a bunch of details that make it hard to support any of them. I think what is needed is a dialog, not a choice of given options (for a yet to be determined set of issues and options to come). /js On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote: Hi all, At the request of the NETMOD chairs, and on behalf of the YANG Versioning weekly call group, here's a summary of Key Issue #1 for the versioning work (i.e. for the Module Versioning and YANG Semver WGLC). We'd like to suggest that the WG has a strong focus on deciding on this specific issue first. Then we'll move on to tackle other key issues. The idea is to try and avoid getting tangled in a web of multiple intertwined issues. Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or not? For now please avoid debating other issues in this thread (e.g. multiple vs single label schemes, whether YANG semver is a good scheme, etc). Let's focus on K1 and work towards a WG decision. ### K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Option 1 - Update RFC7950 to Allow NBC Changes --- - Module Versioning modifies 7950 to allow NBC changes - guidance that NBC changes SHOULD NOT be done (impact to user base) - rev:non-backwards-compatible is a YANG extension - introduction in published YANG does not impact current tooling (ignored until recognized) PROS: - address fundamental requirement of this versioning work (requirements doc) - allows gradual adoption in the industry. YANG authors can immeditately start publishing with the new extensions. - move faster to produce modules in the IETF (accept some errors/iteration) - address the liaison from external standards bodies in a reasonable timeframe - authors believe work is ready - broad vendor support - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) CONS: - perception that we're "cheating" by not bumping our own spec's version - Not fundamentally mandatory for clients or servers using YANG (mandatory for YANG claiming conformance to Module Versioning). Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow NBC changes --- - NBC changes only allowed in a new (future) version of YANG - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) - Content = Module Versioning + YANG Semver + very limited YANG NEXT items - rev:non-backwards-compatible tag is a language keyword - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't been updated - TBD how to handle small NBC changes in IETF in the short term (i.e. non conformance to 7950)? - RFC6991 bis - change the use/meaning of ip-address (or change datetime) - YANG date-and-time (because of SEDATE date string changes) PROS: - address fundamental requirement of this versioning work (requirements doc) - clear delineation of changes in the YANG language - consistent with philosophy that version number changes for significant changes in a spec (avoids concern that YANG is changing without bumping the version of YANG) - can do this with mandatory YANG keywords which helps increase conformance to the new rules CONS: - difficult to roll out in the industry. Tools need upgrading before they won't error on a YANG 1.2 module. - Authors can't publish YANG 1.2 until their users have upgraded their tools. Everyone has to move at once. - likely large delay in producing the work (unclear what would go into YANG 1.2, may not reach concensus easily on N items) - delay in follow up work (Packages, Schema Comparison, Version Selection) - continue dominating WG effort for longer (opportunity cost) Option 3 - Strict Adherence to Current RFC7950 Rules --- - IESG will be unable to approve any RFCs that make any changes to IETF YANG modules that don't strictly conform to those rules - RFC6991 bis would not be allowed to change the use/meaning of ip-address (or change datetime) - YANG date-and-time couldn't change (related to SEDATE date string changes) PROS: - clear rules for entire industry including IETF CONS: - doesn't address agreed/adopted requirements of YANG versioning work - incorrect assumption in tool chains, etc that NBC changes don't happen. Silent failures. Jason (he/him) ___ netmod mailing list netmod@ietf.org
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi Jurgen, The idea here is to focus on the question of whether we're going to allow NBC changes in YANG 1.0/YANG 1.1. So maybe there are some details of the options that are independent or need further refinement/debate. Can you give 1 or 2 examples of the points below that you're concerned with? Note - K1 isn't intended to be a discussion about the full solution. We're going to instead try to pull things apart in a series of independent sequential decisions that build on each other (at least for a small number of key issues). Jason > -Original Message- > From: Jürgen Schönwälder > Sent: Monday, July 17, 2023 2:50 PM > To: Jason Sterne (Nokia) > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in > YANG 1.0 & YANG 1.1 or not? > > > 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. > > > > Dear Jason, > > the three options come with a bunch of details that make it hard to > support any of them. I think what is needed is a dialog, not a choice > of given options (for a yet to be determined set of issues and options > to come). > > /js > > On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is > to try and avoid getting tangled in a web of multiple intertwined issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > --- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > --- > > - NBC changes only allowed in a new (future) version of YANG > > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > > - Content = Module Versioning + YANG Semver + very limited YANG NEXT > items > > - rev:non-backwards-compatible tag is a language keyword > > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > > - RFC6991 bis - change the use/meaning of ip-address (or change > datetime) > > - YANG date-and-time (because of SEDATE date string changes) > > > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - clear delineation of changes in the YANG language > > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping > the version of YANG) > > - can do this with mandatory YANG keywords which helps increase > conformance to the new r
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Dear Jason, the three options come with a bunch of details that make it hard to support any of them. I think what is needed is a dialog, not a choice of given options (for a yet to be determined set of issues and options to come). /js On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for clients or servers using YANG (mandatory > for YANG claiming conformance to Module Versioning). > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow > NBC changes > --- > - NBC changes only allowed in a new (future) version of YANG > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > - Content = Module Versioning + YANG Semver + very limited YANG NEXT items > - rev:non-backwards-compatible tag is a language keyword > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > - RFC6991 bis - change the use/meaning of ip-address (or change datetime) > - YANG date-and-time (because of SEDATE date string changes) > > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - clear delineation of changes in the YANG language > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping the > version of YANG) > - can do this with mandatory YANG keywords which helps increase conformance > to the new rules > CONS: > - difficult to roll out in the industry. Tools need upgrading before they > won't error on a YANG 1.2 module. > - Authors can't publish YANG 1.2 until their users have upgraded their tools. > Everyone has to move at once. > - likely large delay in producing the work (unclear what would go into YANG > 1.2, may not reach concensus easily on N items) > - delay in follow up work (Packages, Schema Comparison, Version Selection) > - continue dominating WG effort for longer (opportunity cost) > > Option 3 - Strict Adherence to Current RFC7950 Rules > --- > - IESG will be unable to approve any RFCs that make any changes to IETF YANG > modules that don't strictly conform to those rules > - RFC6991 bis would not be allowed to change the use/meaning of > ip-address (or change datetime) > - YANG date-and-time couldn't change (related to SEDATE date > string changes) > PROS: > - clear rules for entire industry including IETF > CONS: > - doesn't address agreed/adopted requirements of YANG versioning work > - incorrect assumption in tool chains, etc that NBC changes don't happen. > Silent failures. > > 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
[netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Hi all, At the request of the NETMOD chairs, and on behalf of the YANG Versioning weekly call group, here's a summary of Key Issue #1 for the versioning work (i.e. for the Module Versioning and YANG Semver WGLC). We'd like to suggest that the WG has a strong focus on deciding on this specific issue first. Then we'll move on to tackle other key issues. The idea is to try and avoid getting tangled in a web of multiple intertwined issues. Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or not? For now please avoid debating other issues in this thread (e.g. multiple vs single label schemes, whether YANG semver is a good scheme, etc). Let's focus on K1 and work towards a WG decision. ### K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? Option 1 - Update RFC7950 to Allow NBC Changes --- - Module Versioning modifies 7950 to allow NBC changes - guidance that NBC changes SHOULD NOT be done (impact to user base) - rev:non-backwards-compatible is a YANG extension - introduction in published YANG does not impact current tooling (ignored until recognized) PROS: - address fundamental requirement of this versioning work (requirements doc) - allows gradual adoption in the industry. YANG authors can immeditately start publishing with the new extensions. - move faster to produce modules in the IETF (accept some errors/iteration) - address the liaison from external standards bodies in a reasonable timeframe - authors believe work is ready - broad vendor support - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) CONS: - perception that we're "cheating" by not bumping our own spec's version - Not fundamentally mandatory for clients or servers using YANG (mandatory for YANG claiming conformance to Module Versioning). Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow NBC changes --- - NBC changes only allowed in a new (future) version of YANG - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) - Content = Module Versioning + YANG Semver + very limited YANG NEXT items - rev:non-backwards-compatible tag is a language keyword - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't been updated - TBD how to handle small NBC changes in IETF in the short term (i.e. non conformance to 7950)? - RFC6991 bis - change the use/meaning of ip-address (or change datetime) - YANG date-and-time (because of SEDATE date string changes) PROS: - address fundamental requirement of this versioning work (requirements doc) - clear delineation of changes in the YANG language - consistent with philosophy that version number changes for significant changes in a spec (avoids concern that YANG is changing without bumping the version of YANG) - can do this with mandatory YANG keywords which helps increase conformance to the new rules CONS: - difficult to roll out in the industry. Tools need upgrading before they won't error on a YANG 1.2 module. - Authors can't publish YANG 1.2 until their users have upgraded their tools. Everyone has to move at once. - likely large delay in producing the work (unclear what would go into YANG 1.2, may not reach concensus easily on N items) - delay in follow up work (Packages, Schema Comparison, Version Selection) - continue dominating WG effort for longer (opportunity cost) Option 3 - Strict Adherence to Current RFC7950 Rules --- - IESG will be unable to approve any RFCs that make any changes to IETF YANG modules that don't strictly conform to those rules - RFC6991 bis would not be allowed to change the use/meaning of ip-address (or change datetime) - YANG date-and-time couldn't change (related to SEDATE date string changes) PROS: - clear rules for entire industry including IETF CONS: - doesn't address agreed/adopted requirements of YANG versioning work - incorrect assumption in tool chains, etc that NBC changes don't happen. Silent failures. Jason (he/him) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
