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
<jschoenwaelder@constructor.university> 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 +0000, 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 421 200 3103 <https://constructor.university/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
