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

[Christian Hopps <[e-mail]>]

Balázs Lengyel <balazs.lengyel=[e-mail]> writes:

> Hello Andy,
>
> I assume you are referring to the sentence “A new module revision MAY
> contain NBC changes” from the versioning draft.
>
> IMHO the authors agree that NBC changes are bad. They should be
> allowed but discouraged.

That's what "SHOULD NOT" means.

> Would a sentence like
>
> “A new module revision MAY but SHOULD NOT contain NBC changes … ”
>
> be OK ?
>
> I think the MAY part is also needed< because that is what we are
> introducing as new compared to 7950.

IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD NOT" allows a thing while discouraging it.

Thanks,
Chris.


>
> be agreeable?
>
> Regards Balazs
>
>
>
> From: Andy Bierman <[e-mail]>
> Sent: Sunday, 23 July, 2023 17:26
> To: Balázs Lengyel <[e-mail]>
> Cc: Martin Björklund <[e-mail]>; [e-mail]
> Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
> changes in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
>
>
> On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel <
> [e-mail]> wrote:
>
>     Hello Andy,
>
>     In 3GPP we have endless debates about what is a bugfix. If the
>     functionality will not work it is a bugfix. If it works in a bad
>     way it is or maybe not a bugfix. If it works just in an ugly way
>     is it a bugfix?
>
>     Conclusion: it is not possible to define clear criteria about
>     what is a bug and what is an improvement.
>
>
>
>
>
> It is easy to change MAY to SHOULD NOT in the versioning draft.
>
>
>
> IMO changing MUST NOT to MAY is unacceptable.
>
> The versioning draft is attempting to completely toss out all of the
> YANG update rules.
>
> Changing the normative text to SHOULD NOT instead of MAY does not
> require any specification of a bugfix.
>
>
>
>
>
>     Regards Balazs
>
>
>
>
>
> Andy
>
>
>
>
>
>     From: netmod <[e-mail]> On Behalf Of Andy Bierman
>     Sent: Wednesday, 19 July, 2023 10:13
>     To: Martin Björklund <[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 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
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod