On Fri, Oct 26, 2018 at 04:36:26PM -0700, Andy Bierman wrote:
> On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> 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.
>
3.1 The solution MUST provide a mechanism to allow servers to
support existing clients in a backwards-compatible way.
I believe 3.1 is exactly what we have today. If it is necessary to
make incompatible changes, you create new definitions. This allows
servers to support existing clients in a backwards-compatible way (as
long as the old and new definitions are not conflicting.)
3.2 The solution MUST provide a mechanism to allow servers to
simultaneously support clients using different revisions of
modules. A client's choice of particular revision of one or
more modules may restrict the particular revision of other
modules that may be used in the same request or session.
Today, the version number is effectively an (implicit) part of the
module name (plus the revision date for backwards compatible changes).
Hence, my understanding is that today's model does satisfy 3.2 as
well.
If we want to increase 'agility' in an attempt to make it easier to
deliver early designs and to fix them on the go, the costs will go up
somewhere. The extreme cases are:
1) The server can make changes to YANG modules in arbitrary ways and
the clients have to adapt, i.e., clients have to pay the bill.
2) The server has to provide strict backwards compatibility in order
to not break clients, i.e., servers have to pay the bill.
The question is whether there is a solution somewhere in the middle
that balances the costs and eases the process of adapting clients to
servers and vice versa. It might very well be that there is no sweet
point.
Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
important requirements.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
