On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) <[email protected]> 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 <[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]> > 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]> On Behalf Of Martin Bjorklund > Sent: 19 March 2019 15:12 > To: [email protected] > Cc: [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]> 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] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
