On 25/07/2018 12:03, Juergen Schoenwaelder wrote:
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.)
Yes, I think that this comes down to client implementation.
If clients are looking for a universally unique identifier for a given
datanode then I think that they already have to consider the triple
(module, path, X), where X potentially covers:
(i) per device/vendor/release deviations,
(ii) possibly which revision a data node was first introduced in, or
obsoleted in,
(iii) different YANG features enabled on different devices,
(iv) semantic versioning - at least in the case of the OpenConfig YANG
modules,
(v) non backwards compatible changes (both bug fixes, and more
significant refactoring).
Hence, I'm still not really convinced that adding a semantic version
number is introducing something that robust clients don't have to
already have handle today (even if they didn't have to cope with (iv) or
(v), they still may have to cope with (i) and (ii) and (iii) regardless.
One alternative way to build a robust client would be to have an
internally defined schema by the client (perhaps based on open models,
or perhaps a particular version of vendor models, possibly with some
deviations, or their own model) which they can then map onto one or more
per device schema. So within a particular schema (internal or device
specific) then (module name, path) uniquely resolves to a data node with
particular properties; but between different schema (e.g. for each
different device) then the same (module name, path) pair is allowed to
resolve to a different uniquely defined property.
A layer of mapping is performed between the internal schema and the
device schema for whichever devices/sw-versions it needs to interoperate
with. The more closely the two schema align, the easier the mapping is
to achieve. This is also why, ultimately, that determining whether
changes are backwards compatible or not needs to be done at the schema
level (which takes into account deviations and features), and also the
per data node level.
It is also worth pointing out that the version selection scheme that I
described is really just a way to potentially move the mapping layer
from the client code to the server. Fundamentally it is doing the same
job and serving the same purpose.
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).
My main concern with using module name for major version changes is that
it forces a name change for each data node in that module, regardless of
whether that node has actually changed. This inherently feels like the
wrong this to do. If a data node hasn't changed then ideally you want
it to remain unchanged on the same path. So the alternative way that
RFC 7950 supports today is to keep the module name the same but
introduce new names for all identifiers that have been changed in a non
backwards compatible way, making use of status deprecated/obsolete.
However, it isn't clear to me that handling the old and new values
within the same schema is always a good thing to do. I generally prefer
the idea of doing version selection (if anyone chooses to support this)
so that a given value is only reported once.
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.
My feeling (and I don't have hard evidence to back this up) is that
clients are generally less impacted by keeping the name the same rather
than changing the module name for every major version change.
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".
With version selection, servers would still have the opportunity of not
breaking clients, although it doesn't seem that likely to me that
vendors will spend the effort to implement this. But I still see that
allowing the option to do this is a good idea (perhaps as a separate
experimental draft).
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).
I still think that clients may struggle to process configuration in a
get request that they had not configured, and hence were not expecting.
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).
So, I think that constraint should be that for a given schema (i.e. set
of implemented modules) there can be only a single definition for a
(module, path) pairing. I see the version information, much like
deviations, as just a mechanism to help clients (and readers) to spot
where the definition may deviate from what they were previously
anticipating.
In all cases, I think that minimizing backwards incompatible changes is
the right thing to do, and I suspect that as YANG gains more traction,
more of the latent bugs will get fixed, models will harden, and churn
will decrease. But I think that vendors will always want an easy way to
fix bugs, and to change the model in the case that the implementation
has radically changed, or when the schema is being cleaned up.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
