Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman <[e-mail]>]

On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Fri, Oct 26, 2018 at 09:35:39AM -0700, Andy Bierman wrote:
> >
> > IMO requirements 3.1 and 3.2 are the most  important and have the most
> > impact
> > on the solution space. I do not agree with either of these requirements.
> >
> > Implementing multiple non-compatible revisions of a module on a server
> > sounds hard,
> > not to mention that it breaks RFC 7950 rules. The current protocols do
> not
> > support the
> > ability to specify different versions of the same QName. This change
> makes
> > YANG validation
> > much to difficult to specify and implement (as that has to be rewritten
> as
> > well).
> >
> > It is one thing to deploy rapidly changing, buggy YANG modules in order
> to
> > gain experience quickly.  It is quite another to complicate YANG and the
> > protocols
> > to preserve these interim mistakes, and bake into the standards the
> notion
> > that this
> > is good engineering.
> >
>
> So how do you think this conflict between more agility and client
> stability should be handled? It seems you can't easily have both at
> the same time. Are you saying that backwards compatibility to support
> existing clients is not important?
>
>
It depends on the data model and how broken it is in the replaced version.
YANG validation is slow and complicated enough without pretending there
are 8 or 10 separate schema trees within a datastore. It might be impossible
for all constraints to be true in all schema trees at once.  It is a burden
on operators
and client developers to understand and properly manage multiple
incompatible revisions
of the same module

yang-library is a good example of a clean break.
The /yang-library tree completely replaces the /modules-state tree.
A server can easily support both subtrees.
No new YANG or protocol features are needed at all.
This was not a bugfix, just the normal instability in the IETF.

Even with this clean break, there could be external modules that have
leafref
or must/when that point at the /modules-state subtree.  They have to be
rewritten
to use /yang-library instead. But this can happen as needed since the old
tree is unchanged.

For truly broken changes (e.g. change a node from a container to a list;
change a leaf from type boolean to an enumerated type w/ 6 enums;
remove or rename lots of existing nodes) the cross-references from external
modules can easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
not needed.
Another - just the opposite.


Andy



/js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>