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 <[email protected]> On Behalf Of Jürgen Schönwälder > Sent: 17 July 2023 11:50 > To: Jason Sterne (Nokia) <[email protected]> > Cc: [email protected] > 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 +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 > > [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
