On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder < [email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
