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 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
