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

Andy Bierman <andy@yumaworks.com> Wed, 20 March 2019 13:48 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F612867A for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 06:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpXtEqyfg54R for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 06:48:34 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008A312782C for <netmod@ietf.org>; Wed, 20 Mar 2019 06:48:33 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id y18so1963992lfe.1 for <netmod@ietf.org>; Wed, 20 Mar 2019 06:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g4xV9ubUyoOSkFnD+rOi+LBH/2SmPSIRfpHsQZHTOmQ=; b=hIZnLZH3pPV3XxP2Yubjbysd6CTLtl26pUiLOYfNfi2VDFtaM+XIrxmycNAJdB8QAo yhvsjRLYqFgfpyFxJ5JwM8cP/n6dyZnqDGXo46ZcjI78+7M3fN8L7T3VgmCoM5s5rz+m slscMAqwuoXTObzjnd7abkl5L5ti+AOa13Osxpf1jOYJ8xRAYYJrIht791ZxX2NfPezZ Fv+4kiAdvxOjorjcC0U1MPWHXdb4RZdZ5BFUAFh31M8iXCnFW/7Cy3DpWVZ9r4dGnV7m yZ1uHT0wvnAPziS9xDawuOdLWYDkitJOlss8s5KL/xJeMdwtQ4+PjZB63e2xdrDuASeL GI1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g4xV9ubUyoOSkFnD+rOi+LBH/2SmPSIRfpHsQZHTOmQ=; b=k3trrQkb5cJbUrX60m9m+5/xT0VOuJBAxb5YDOoqoxqqquBTbfx0B0QQOLXmk/S9xZ zkvihI0jF3hIJr/J0nFv6ve+qclF2++IAsotATqYdcCN8z7peSMZH6LnGw+EavlXqcU2 psZ3uETjXj/0OugDbcn6rscua7kY/43J0IyFi1ZTpzJQSU+iWN7LO99uF6uVdLxxq54f bgrYFdgTss4sDptpK1xkN3T35nerzcVNreI/K5ru06Ve/je3A7T8YbS3I6BQZXAppuHv 3RiSu1AGRhInGl3Y94Yt1eyFV1pUHEgQLktGEZHxPlpwTCVL95H1wPo5CRwg4UOKUrJ2 d1Qw==
X-Gm-Message-State: APjAAAXGA7z046ouJyuMXfq+rdIwEWa99us5WnenW8bvxlitn3x2WcGn +dwCMiPvMq6dumQnHesibjvRnGgN7fUNy9tDCtsUVA==
X-Google-Smtp-Source: APXvYqzwEppUZNhfMDpNcNB0OdtfepM5B7fzSt0BARvZyFFo+O7nXCEDnfSH8UtgbOkS+Uthyt4hRhVH+kznY0oH4Rc=
X-Received: by 2002:ac2:569b:: with SMTP id 27mr17224494lfr.24.1553089711523; Wed, 20 Mar 2019 06:48:31 -0700 (PDT)
MIME-Version: 1.0
References: <0100016978b80dcd-31f317a5-443b-400a-98b3-2bfc91841bdc-000000@email.amazonses.com> <20190319.161229.1910835285804688041.mbj@tail-f.com> <aee7d9770a2c4570a3185a1ebeef4c36@XCH-RCD-007.cisco.com> <CABCOCHTsH_wk+MGQwSPA-JZCUiTT38ua-dsnoFgjO=r0U07veA@mail.gmail.com> <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com>
In-Reply-To: <8871415dce7343a28afa25faf6080d8c@XCH-RCD-007.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 20 Mar 2019 06:48:20 -0700
Message-ID: <CABCOCHQX5i1a6zqOSc2ec3YJ=8Ugc6WeN4_uh6YqRq6jKrR1ig@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f5fc9058486e07b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Z5grAbsayiX4WEvMc2OxPEbRc7k>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 13:48:40 -0000

On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) <rwilton@cisco.com>
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 <andy@yumaworks.com>
> *Sent:* 19 March 2019 18:35
> *To:* Rob Wilton (rwilton) <rwilton@cisco.com>
> *Cc:* Martin Bjorklund <mbj@tail-f.com>om>; kent+ietf@watsen.net;
> netmod@ietf.org
> *Subject:* Re: [netmod] adoption poll for yang-versioning-reqs-02
>
>
>
>
>
>
>
> On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) <rwilton@cisco.com>
> 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 <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
> Sent: 19 March 2019 15:12
> To: kent+ietf@watsen.net
> Cc: netmod@ietf.org
> 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 <kent+ietf@watsen.net> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>