Hi Andy,
Thanks for the comments.
1. Regular Semver 2.0.0 (as per semver.org) allows some branching. I.e. you
can create version 2.0.0 based of version 1.1.0, and then subsequently create
version 1.2.0 based of 1.1.0. So structure wise this would logically look like:
1.0.0
| \
| 1.1.0 – 1.2.0 - …
|
2.0.0
|
I also raised https://github.com/semver/semver/issues/504 on the semver 2.0.0
github to confirm that my interpretation is correct, and no one has disputed it
yet.
2. Vendor software releases can have a very long support time (e.g. easily 5+
years), with an expectation that bugs get fixed. Requiring that customers
upgrade their software (or perhaps hardware) to the very latest software
version to pick up a small bug fix is not realistic. This is primarily why I
think that the ‘m’ and ‘M’ are so important. They allow for bug fixes in a way
that Semver 2.0.0 simply does not.
Semver 2.0.0 only allows for bugfixes in the implementation (by updating the
patch version number), but has the expectation that there are *never* any
non-backwards-compatible changes in the API, not even to fix a bug, except at
the tip of the development tree.
In short, I think that vanilla Semver 2.0.0 is a good fit for open source
projects where you can just tell the client to update to the latest version to
pick up the fix. I don’t think that Semver 2.0.0 is so well aligned to APIs
that are required to be maintained for long periods of time.
The alternative that Rob Shakir mentioned at IETF 103 in the context of
OpenConfig, which uses strict Semver 2.0.0, is to handle these bug fixes using
deviations. But it seems to be significantly more complex to manage bug fixes
using extra deviation modules rather than allowing the ‘m’ | ‘M’ modifiers.
Versioning would no longer limited to a module version number, but require
knowledge of the module version and set of deviations that are applied to it.
I would rather deviations are reserved to indicate whether an implementation
doesn’t match the module specification rather than use them as a way of fixing
bugs in the specification itself.
3. I agree that the use of Semver + packages + version selection does not
reduce the overall number of paths to a configurable property, but it does
ensure that there is only a single path to a configurable property within a
YANG datastore schema. So whichever version each client is using, they only
use a single path. I.e. mirroring the way that a classic programming API might
be versioned.
Servers that wish to support this would have to map the data between different
YANG datastore schema versions. Not all mappings are possible, but at least
any cases where it is not possible can be detected and reported to the client
via an out of band mechanism.
If the module content changes significantly between module versions that
mapping will be much harder than if the changes are minimal or backwards
compatible. So there is still a strong incentive for model writers to minimize
churn to the YANG models.
Thanks,
Rob
From: Andy Bierman <[email protected]>
Sent: 19 March 2019 18:35
To: Rob Wilton (rwilton) <[email protected]>
Cc: Martin Bjorklund <[email protected]>; [email protected]; [email protected]
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton)
<[email protected]<mailto:[email protected]>> wrote:
Hi Martin,
Thanks for the review and comments.
A couple of points:
1) Lots of models outside those published in SDOs are already not following the
RFC 7950 revision rules. I think that it is better to have a versioning scheme
that reflects how YANG models are actually evolving rather than have all vendor
and OC YANG modules either just ignoring the rules, or using clever tricks that
strictly conform with the rules but go against the spirit of them (e.g. just
publish an entirely new set of YANG modules for each release). Also noting
that having a scheme that allows non-backwards-compatible changes does not
require that everyone uses them - IETF could continue to always publish
backwards compatible modules. The obvious alternative here is that each vendor
comes up with their own versioning extension and ignores the RFC 7950 section
11 rules anyway, but I'm not sure how that really helps client<->server interop.
I do not support branching for YANG models so I do not supported modified
SEMVER.
Adding a special character to the version string doesn't help the deployed
client code
that stops working when the server code is upgraded. This is a quality issue
that
each organization has to deal with the best they can.
I do not object to the addition of a SEMVER field to a YANG module because
these version
strings are familiar to users. It is possible to express import ranges such as
1.2.* (any 1.2.x release)
which are not possible with date strings.
2) I don't understand how the RFC 7950 approach of "deprecate a buggy node, and
replace with a working node" really works in practice, particularly for
configuration data nodes where you have two clients interacting with a server,
one interacting with the old path, and another using the new path. Perhaps
there is a robust scheme that works in all cases, but it isn't obvious to me.
Historically, for CLI we just translate the CLI from old to new format and then
return the new format when the running config is requested. But that will
still break an old client that doesn't understand how to read the new CLI, even
if the server supports them writing via the old CLI.
SEMVER does not reduce the number of paths to the underlying configuration
object.
That problem does not change whether a new XPath absolute-path-expr is used
or whether the same path is overloaded with semantics derived from additional
protocol parameters
(e.g., versioning of each data node). I prefer the existing XPath solution
because it is explicit
so the YANG reader can easily see the multiple paths, and no new protocol work
needed to support it.
If there is an NBC change to an object then all XPath and leafref references to
it will probably break.
That seems like a harder problem to solve than the original path duplication
problem.
Even if there is a workable solution for this simple case, I suspect that there
are many slightly more complicated cases that don't work (e.g. rekeying a list,
changing defaults, incompatible types).
In short, I don't agree with the premise that the current YANG versioning
schema using revision dates is working just fine, and no changes are needed.
Thanks,
Rob
Andy
-----Original Message-----
From: netmod <[email protected]<mailto:[email protected]>> On
Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: [email protected]<mailto:kent%[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
Hi,
I have read this document, and I do not think it should be adopted.
I object to the idea that we should allow non-backwards-compatible changes to
published YANG modules.
The draft motivates this idea with:
we must recognize that many YANG
modules are actually generated YANG modules (for example, from
internal databases)
I do not agree that we should change what we allow in published modules b/c of
this.
It also motivates this idea with:
The points made above lead to the logical conclusion that the
standardized YANG modules have to be perfect on day one (at least the
structure and meaning), which in turn might explain why IETF YANG
modules take so long to standardize.
I disagree with this. First of all, we have already published revision two of
several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interfaces,
ietf-ip, ietf-routing, ...), so the statement that "standardized YANG modules
have to be perfect on day one" is simply not true.
Second, I don't think the upgrade rules are the reason it takes a long time to
standardize IETF models (I think it has to do with the process itself,
including the fact that models get reviews from many different people with
different background.) [BTW, is it true that drafts with YANG models take
longer time from wg -00 to published RFC than other drafts?]
This said, I think there are some important points that the draft raises, and
that I think we should continue to work on; specifically 2.3, 2.5, 2.6, 2.7.
But I don't think that these areas require changes to the versioning scheme,
and I think it is a mistake to include these areas in this draft.
Some comments on section 4, The Problem Statement:
o Any non-backwards-compatible change of a definition requires
either a new module name or a new path. This has been found
costly to support in implementations, in particular on the client
side.
Yes I agree there is a cost associated with this. But I have come across
vendor modules that make NBC changes w/o introducing a new path, and this is
also costly to handle.
o Since non-backwards-compatible changes require either a new module
name or a new path, such changes will impact other modules that
import definitions. In fact, with the current module versioning
scheme other modules have to opt-in in order to use the new
version. This essentially leads to a ripple effect where a non-
backwards-compatible change of a core module causes updates on a
potentially large number of dependent modules.
This is by design. We cannot have a situation where a legal modification to a
module leads to other modules becoming invalid.
o YANG has a mechanism to mark definitions deprecated but it leaves
it open whether implementations are expected to implement
deprecated definitions and there is no way (other than trial and
error) for a client to find out whether deprecated definitions are
supported by a given implementation.
As I wrote above, I agree that this is a problem that should be solved. But
this is not a motivation for changing YANG versioning.
o YANG does not have a robust mechanism to document which data
definitions have changed and to provide guidance how
implementations should deal with the change. While it is possible
to have this described in general description statements, having
these details embedded in general description statements does not
make this information accessible to tools.
This might also be worth exploring, but this is not a motivation for changing
YANG versioning.
/martin
Kent Watsen <[email protected]<mailto:kent%[email protected]>> wrote:
> Seeing as how we all need to read this draft anyways, in preparation for our
> meeting in Prague, it seems like a good time for this poll. Thusly, this
> email begins a 1-week adoption poll for:
>
>
> https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02
> <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-0
> 2>
>
> Please voice your support or objections before March 20.
>
> Note that this draft defines *requirements* and its intended status is
> "Informational." I believe that it is good for WGs to formalize
> requirements, even taking such drafts thru Last Call, in order to ensure
> consensus on the requirements. This is the "adoption" call, to ascertain if
> the WG agrees with that statement; if adopted, a separate "last call" will be
> issued to ensure to correctness of the draft's content.
>
> Kent (and Lou and Joel)
>
>
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
