On 24/07/2018 16:11, Andy Bierman wrote:
On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:
> There are actual instances where small perhaps non-disruptive but
> incompatible changes are required. The example given to me for this
> type of change was when the original specification had an obvious
> bug (e.g., a range was incorrectly specified).
I strongly believe that fixing bugs is not a reason to change the
current versioning rules. Bugs come essentially in three flavors:
- A definition is messed up (i.e., a range, a pattern, a must
expression) but the original intention of the definition is clear
from the context (description clauses, references, ...). In this
case, implementors will likely have done the right thing (or when
they observed the problem they will likely have done the right
thing).
- A definition is messed up but it is not clear from the context what
the original intention of the definition was. In this case, there is
a true ambiguity and implementors can rightfully have come to
different conclusions how to deal with the conflict in the
definition.
In the first case, I believe there is no issue with simply fixing the
messed up definition. I believe this kind of bug fixes is not
constrained by the YANG update rules.
In the second case, there is true ambiguity what implementations may
do and hence the safest approach is to deprecate the messed up
definition and to create a replacement.
Of course, in reality, things are often not so clear cut and hence it
takes some informed judgement what is the reasonable way to deal with
things. (A type two bug caught very early may be different from a type
two bug caught after several months of implementation and deployment.)
Sometimes we also have situations where a definition that was
originally OK turs out over time to be problematic as technology has
evolved. So after some time, the original definition starts to look
like a bug but it actually is not. The safe path forward is again to
create new definitions and to deprecate the old ones.
Now, for those in favour of moving from (module, path) to (module,
path, version), you loose the deprecated definition. So if you wan't
to allow for a transition period, there is a need to allow an old
client to work with the old definition and a new client to work with
the new definition. In the current naming scheme, this is not a
problem, with a (module, path, version) naming scheme this requires
some extra complexity.
The problem with versioning the "YANG API" is that it is not possible
to isolate
individual modules and say "I pick version 1.0.3 of module foo and
version 2.1.1
of module bar". And every client can pick a different arbitrary subset of
mix-and-match YANG modules.
Well YANG does not work that way. There is no concept of a YANG package.
There is no concept of a group of modules/versions/features that are
not divisible within a server implementation.
The other problem is what you are pointing out..
It would be far easier to just fix the clients and the servers, not
just the servers.
Why is it OK for the client developer to decide "we are sticking with the
defective version of the module and not going to upgrade to
the fixed version like the server developers have done."
One of the aims of the YANG versioning work is to give more information
to the client about whether they are likely to be impacted by upgrading
to a new set of modules. For me, I think that the most useful thing is
if this is done by comparing the full schema between old and new
releases (including module versions, enabled features, and deviations),
and then identifying the data nodes that have been changed in a
backwards compatible way, and those that have been changed in a non
backwards compatible way (if that is allowed).
E.g. even it is a change is an obvious bugfix, it still makes sense to
flag that change so that client implementations can be checked to ensure
that they don't break.
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). 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?
Thanks,
Rob
/js
Andy
--
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/
<https://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
