On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) <jason.ste...@nokia.com> wrote:
> We considered this approach as well in the weekly calls but in the end > felt that was just dodging the problem. We have a set of “MUST” rules that > we know need to occasionally be broken. Shouldn’t we officialize this so > our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? > > > > It isn’t just an IETF issue. These same exceptions occur in vendor models, > 3GPP, etc. There are times when making the NBC change is the reasonable way > to go. > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with I do not support these changes in any version of YANG. The advice to the community is non-specific and obviously not backward compatible with RFC 7950. The new advice is that any change at all in a YANG module is now allowed. Instead of normative rules, RFC 7950 simply advises whether the optional 'non-backwards-compatible' extension could be applied or not. This is not a good change, especially on top of YANG 1.1. I could see if specific MUST NOT rules were changed to SHOULD NOT instead. A blank check using the current "MAY" (3.1, para 2) is not a good idea. Jason > Andy > > > *From:* Andy Bierman <a...@yumaworks.com> > *Sent:* Wednesday, July 19, 2023 1:13 PM > *To:* Martin Björklund <mbj+i...@4668.se> > *Cc:* Jason Sterne (Nokia) <jason.ste...@nokia.com>; 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. > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <mbj+i...@4668.se> wrote: > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > > > > > This is the approach I also suggested on the mailing list. > > > > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > > > > > The important thing in each case is to consider > > the expected impact on the real world and real deployments. > > > > IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC > change. > > But this is not the same thing as changing the rules in a new document to > shift the > > implementation burden to the client. > > > > This is only an IETF issue and the burden should be on a WG to convince > the IESG and IETF > > that making the NBC change is a bugfix and should be allowed as a special > case. > > > > > > > /martin > > > > Andy > > > > > "Jason Sterne (Nokia)" <jason.ste...@nokia.com> 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 > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod