Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Andy Bierman <[e-mail]>]

On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) <[e-mail]>
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 <[e-mail]>
> *Sent:* Wednesday, July 19, 2023 1:13 PM
> *To:* Martin Björklund <[e-mail]>
> *Cc:* Jason Sterne (Nokia) <[e-mail]>; [e-mail]
> *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 <[e-mail]> 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)" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>