Hi Jurgen, The idea here is to focus on the question of whether we're going to allow NBC changes in YANG 1.0/YANG 1.1. So maybe there are some details of the options that are independent or need further refinement/debate. Can you give 1 or 2 examples of the points below that you're concerned with?
Note - K1 isn't intended to be a discussion about the full solution. We're going to instead try to pull things apart in a series of independent sequential decisions that build on each other (at least for a small number of key issues). Jason > -----Original Message----- > From: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Sent: Monday, July 17, 2023 2:50 PM > To: Jason Sterne (Nokia) <jason.ste...@nokia.com> > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in > YANG 1.0 & YANG 1.1 or not? > > > CAUTION: This is an external email. Please be very careful when clicking links > or opening attachments. See the URL nok.it/ext for additional information. > > > > 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
