Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>