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? /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
