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

[Balázs Lengyel <[e-mail]>]

Hello,
I am writing this as
- Balazs Lengyel one of the authors, but also as
- an Ericsson guy and also as
- a delegate of 3GPP, which requested a better versioning scheme in a reasonably
 fast timeline.  3GPP represents both vendors and operators, so in this last
 role I am sitting on both side of the fence.
 I strongly support option 1 - modifying 7950 to allow NBC changes and
 introducing something like Semver.
- We need this soon and the other alternatives will take a longer time.
- we need it for the current YANG models too, not just for YANG 1.2 or 2 models
- We are already today doing backwards incompatible updates. We would like to have
 that aligned with IETF.
 - as one of the authors I believe the work is ready and reasonably good
- I believe adapting the tooling for a few new extensions is much less work
 than adapting to a new YANG version
 Option 2 will take a long time to specify, implement and roll out. During this time
 other non-standard solutions will proliferate; messy solutions, like just
 ignoring the current RFC7950 rules, will be used more and more.
 Option 3 just ignores the real world.
 NBC changes are happening. There are SDOs that value speed over final quality
 and role out a new version of the modules every few months. These can not
 live without some NBC changes.
 A more fine grained versioning system is required.

Regards Balazs

From: netmod <[e-mail]> On Behalf Of Andy Bierman
Sent: Thursday, 20 July, 2023 18:52
To: Jason Sterne (Nokia) <[e-mail]>
Cc: [e-mail]
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?



On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, July 19, 2023 1:13 PM
To: Martin Björklund <[e-mail]<mailto:[e-mail]>>
Cc: Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-688efc90f7cb3f03&q=1&e=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6&u=http%3A%2F%2Fnok.it%2Fext> for additional information.




On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod