Re: [netmod] yang versioning solution complexity and alternative approaches

[Andy Bierman <[e-mail]>]

On Wed, Jun 8, 2022 at 10:04 AM Jürgen Schönwälder <
[e-mail]> wrote:

> On Wed, Jun 08, 2022 at 04:40:05PM +0000, Rob Wilton (rwilton) wrote:
> > >
> > > Rob,
> > >
> > > discussing details is likely distracting from the main difference in
> > > our viewpoints so I will only give a top posting response.
> >
> > Okay.
> >
> > I believe that the consensus of the authors on the weekly calls is also
> that annotations at the "data definition" level are helpful, alongside
> module and package (i.e., schema level) version numbers.
> >
> > Hence, my understanding of the main difference is whether
> non-backwards-compatible changes MUST always be explicitly documented at
> the data node level (and hence whether that means that data nodes can never
> be deleted from a YANG module), or whether these annotations are
> unnecessary, and potentially unhelpfully clutter the YANG module in the
> cases where tooling can robustly infer whether the change is backwards
> compatible or not.
>
> For me, its a MUST. If you potentially break things, you have to tell
> others. If you choose to violate the YANG 1.1 update rules, you have
> to document that. Deleting data nodes (well, data nodes is actually
> too limiting but that is likely a detail) is a special case and some
> way to document that something was remvoed is indeed needed. I think
> it is wrong to use a corner case to design the general case here.
>
>

Strongly agree with all of Juergen's concerns.
It is normal engineering practice to identify API changes
in the documentation for a specific API (not at some global level).

The interactions between YANG modules are too complex for a "module-is-NBC"
flag to really help.

IMO only NBC changes are a MUST. BC changes are a MAY.
These changes should not be documented in an extension that MAY be ignored.
The existing description-stmt is mandatory-to-implement for all tools.


Andy


If your YANG module gets cluttered because of NBC changes, perhaps
> there is something to be said about the engineering process. To
> unclutter a module, you give it a new new and remove the history.  I
> do not believe that there is a robust algorithm to infer in the
> general case whether a change in NBC or not, so it is pointless to
> consider this option.
>
> > Possibly there is also a second difference of opinion as to whether it
> is appropriate/safe to assume that any changes that are not explicitly
> marked as being non-backwards-compatible are in fact backwards compatible.
> I.e., specifically, is a "backwards-compatible" annotation also required in
> the cases where a tool cannot safely infer that a change is
> backwards-compatible.
>
> If NBC markers are a MUST, then everything not marked is a BC
> change. In YANG 1.1, everything following the update rules is a BC
> change, hence there are no markers. It seems logical to me to keep the
> existing assumptions.
>
> > Do you think that accurately represents the difference in opinion
> > from your perspective?
>
> There is another one concerning the implementation. If YANG is changed
> in such a way that existing deployed tools derive wrong conclusions,
> then this is an NBC change to YANG and the YANG version number needs
> to be incremented.
>
> /js
>
> --
> Jürgen Schönwälder              Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>