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

[Andy Bierman <[e-mail]>]

On Mon, Jul 24, 2023 at 4:41 PM Christian Hopps <[e-mail]> wrote:

>
> 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.
>
>
Indeed.
https://datatracker.ietf.org/doc/html/rfc2119

It is clear that 'SHOULD NOT' is the correct term and 'MAY' does not even
apply here.


> 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.
>
>
 Andy


> >
> > 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
>
>