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 <netmod-boun...@ietf.org> On Behalf Of Andy Bierman Sent: Wednesday, 19 July, 2023 10:13 To: Martin Björklund <mbj+i...@4668.se> 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<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)" <jason.ste...@nokia.com<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 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<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
