On Tue, Jul 24, 2018 at 04:32:05PM +0100, Robert Wilton wrote: > > But if fixing a definition requires a whole new module name then I think > that causes lots of problems (e.g. consider needing to change ief-interfaces > to ietf-interfaces-v2 because of changing one random leaf).
I assume this depends a lot on how clients are written but chances are that a significant portion of clients are written such in such a way that dealing with multiple namespaces is difficult. (But yeah, dealing with multiple versions in the same namespace likely is also difficult for them.) What really chances here is the adaptation process: Today, a client will not bother to use a new namespace (a new version) unless it was programmed to do so (opt-in). The proposed new versioning scheme effectively means that client will automatically use new versions until the client got told to be careful where necessary (and I assume that in most cases this means until the client failed and then got fixed, an opt-out process). I can understand why some people believe a conservative opt-in approach is desirable for them and I can understand why some other people believe an optimistic approach opt-out approach is desirable for them. There are likely good arguments for both and this makes it difficult to pick one. At the end, code that needs to support multiple versions is always going to be to some extend ugly. Whether the uglyness is in namespace bindings or version checks is likely more a question of taste. I believe code uglyness is not really driving this but the desire to be more agile and "lets release and then fix clients when they break" may be more dynamic than "lets release and then wait for clients to get updated". > The YANG 1.1 way is to define a new definition and then deprecate > the broken one. But this has negative consequences as well, > e.g. does writing to the old leaf automatically also write to the > new leaf at the same time? Are both returned in a get request? What > if a different client only writes to the new leaf? Sure, duplicate or overlapping config objects is something we usually try to avoid. In general, I assume a server would try to keep such overlapping leafs in sync. But then, this is an issue that appears in any scheme that allows access to multiple versions of a leaf (or overlapping leafs in general, i.e. a standard object and a vendor version of it). The point I was trying to make was a different one, namely that today we have a way to expose multiple versions of a leaf by using a new (module, path) name while with a (module, path, version) naming system, our protocols need extensions to expose multiple versions of a leaf (or we declare that servers will never expose multiple versions and that clients must always adapt to the version currently offered by a server). /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