Re: [netmod] adoption poll for yang-versioning-reqs-02

[Andy Bierman <[e-mail]>]

On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> 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.
>
>
>

The numbering may allow it, but it is not really being used that way.
I don't think the YANG standard needs to support branching in this way.


>
>
> 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.
>
>
>


I agree that deviations should be used instead of branching.
You can cherry-pick features from the latest very easily with deviations.
IMO it is more accurate to say the implementation supports version X minus
some features,
rather than assigning some version string to mean the same thing.  This
approach can get
out of control very quickly if multiple independent release trains exist. I
prefer a linear
development progression, and each implementation will identity its
functionality the same way.



>
> 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.
>
>
>

I don't think the versioning data nodes is a good idea.
I have seen entire REST APIs be versioned, but not individual parameters
within the API.
How do you version the must/when/path references from other objects that
point at the data node?
Sounds way too complex to manage.


> Thanks,
> Rob
>
>
>

Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 19 March 2019 18:35
> *To:* Rob Wilton (rwilton) <[e-mail]>
> *Cc:* Martin Bjorklund <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [netmod] adoption poll for yang-versioning-reqs-02
>
>
>
>
>
>
>
> On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) <[e-mail]>
> 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 <[e-mail]> On Behalf Of Martin Bjorklund
> Sent: 19 March 2019 15:12
> To: [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>