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) <[email protected]> Sent: lunedì 17 luglio 2023 19:52 To: [email protected] 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 tool chains, etc that NBC changes don't happen. Silent failures. Jason (he/him)
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
