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

[Juergen Schoenwaelder]

On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> 
> This is what we have today only if modules are updated in legal ways.
> The 3.1 requirement says this backward compatibility is maintained even
> if the module is updated in violation of the module update rules.
>

It is stating a requirement. How solutions meet the requirement is for
the solutions to figure out.

> How would 3.1 be met if the WG decided to just add a new 'datastore'
> key leaf to the /modules-state/module list?

Depends on the solution I guess.
 
> IMO the current "deprecate and start over" is actually the easiest
> and most robust solution path, and it requires no changes to YANG or
> the protocols.

Yep. But there are people who think that other solutions can do
better. The challenge is to find out whether they actually do better
or for whom they do better (and if someone has to pay a price for it).
For having this discussions, it is good to write down requirements.

> >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.
> 
> This is not what we have at all. RFC 7950 says a server can only implement
> one revision of a module.
>

A new version today essentially means a new module name and I do not
see a conflict with what I wrote.

> > 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.
> >
> >
> This is not correct. Implementing multiple incompatible revisions of a
> module
> (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> server developer.

Depends on the details and the developer will decide based on the
impact on the clients and whether a transition period is possible. You
seem to read that the requirement says one has to implement backwards
compatibility. This is not what the text says. The text says it must
be possible.

> > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > important requirements.
> 
> I do not agree with the premise that non-compatible data model updates are
> required.
> 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> a new(much more complicated) version of YANG

I think you misread the requirements text.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Sat, Oct 27, 2018 at 1:36 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

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


This is what we have today only if modules are updated in legal ways.
The 3.1 requirement says this backward compatibility is maintained even
if the module is updated in violation of the module update rules.

How would 3.1 be met if the WG decided to just add a new 'datastore' key
leaf
to the /modules-state/module list?

IMO the current "deprecate and start over" is actually the easiest and most
robust
solution path, and it requires no changes to YANG or the protocols.




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

This is not what we have at all. RFC 7950 says a server can only implement
one revision of a module.



> 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

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

[Juergen Schoenwaelder]

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod