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 <netmod-boun...@ietf.org> 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 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
