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