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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 20 March 2019 18:10 UTC

Return-Path: <rwilton@cisco.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 14BCB12AF7A for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 11:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FS0jVG_N-8BM for <netmod@ietfa.amsl.com>; Wed, 20 Mar 2019 11:10:06 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF349131202 for <netmod@ietf.org>; Wed, 20 Mar 2019 11:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15817; q=dns/txt; s=iport; t=1553105404; x=1554315004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=363w53kvgVrsoamSIPA53cilkZ9JUdvVsHU6lUoLqfI=; b=MxHffWKOkM0/6zwVVnzMPCTAJUcSAHpGwbbz6A4zmVGbBSmxTtBqVlWt +crTi3cyyKyrPQ3mwqvXZvFOMMVGO4koyurmZF9xPGA8fNwzIbH4hgryn zbXMZpeKgT7jv4pfnVDxDKPA+ik0rZ7Xul4uAhtwLqmwplzQrpJk062IP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAD3gJJc/40NJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBghBogQMnCplLmDUUgWcLAQEYC4FUgi9?= =?us-ascii?q?GAoRnIjYHDQEBAwEBCQEDAm0cDIVKAQEBAwEBASUTNAsMBAIBCA4DBAEBAR4?= =?us-ascii?q?QJwsdCAIEDgUIE4MIgW0ID6wGM4ovBYEvAYsiDxeBQD+BEYIUfoMeAQEDgSs?= =?us-ascii?q?BEgEJhXcDiiAOMwKGO5J+YAkCh16EB4dBIYF9hXODS4gqjCmEZo0RAhEVgS0?= =?us-ascii?q?mAi9lcXAVO4JsghYXiF+FP0Exik6BH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208";a="452778125"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 18:10:03 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KIA35F032649 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 18:10:03 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 13:10:02 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Wed, 20 Mar 2019 13:10:02 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kent+ietf@watsen.net" <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02
Thread-Index: AQHU2dp4LgK63tqezk2Dd3s9wP+vpaYTbHKA//+y6SCAAV5PAP//9h1QgAB1QYD//9ucoA==
Date: Wed, 20 Mar 2019 18:10:02 +0000
Message-ID: <7bcc505f43154c80b6d57529ce429228@XCH-RCD-007.cisco.com>
References: <aee7d9770a2c4570a3185a1ebeef4c36@XCH-RCD-007.cisco.com> <20190320.083022.2046737837256499330.mbj@tail-f.com> <96f475459f6049bfa20c66412983f4a2@XCH-RCD-007.cisco.com> <20190320.145439.1107389062091531440.mbj@tail-f.com>
In-Reply-To: <20190320.145439.1107389062091531440.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-jBOzGGfSlRJMBb7VpJpLM9Fhmo>
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 18:10:20 -0000

Hi Martin,

> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>
> Sent: 20 March 2019 13:55
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: kent+ietf@watsen.net; netmod@ietf.org
> Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
> 
> "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> > Hi Martin,
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund <mbj@tail-f.com>
> > > Sent: 20 March 2019 07:30
> > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > Cc: kent+ietf@watsen.net; netmod@ietf.org
> > > Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
> > >
> > > Hi,
> > >
> > > "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.
> > >
> > > Right, and I think that is ok.  If vendors want to break backwards
> > > compatibility it is up to them.  With the current rules you can have
> > > tool that detect this and flags it.  You can then fix the problem or
> > > release the new NBC module anyway, but you have been warned.
> > > Customers will accept this or not.
> >
> > [RW]
> > Revision-dates don't help here, and are not sufficient to indicate the
> > true version history of a module when it is not chronologically
> > ordered.
> >
> > Vendors want a way to accurately communicate to clients how the module
> > is actually being changed, in a way that is easier for them to
> > understand.
> 
> If I'm at 1.0.1M and see 1.0.2M it doesn't help me much.

[RW] 
In this case the client has to diff the YANG modules.  This is the same as going from 1.0.0 to 2.0.0.

The aim of the 'm'|'M' is to *allow* models to be fixed with NBC changes if required, it is not intended to encourage models to have lots of NBC changes.  I.e. the scheme is deliberately restricted in the information that it conveys as a means to prevent model authors from having carte blanche when updating models.  It is meant to be used as a last resort, and that is what draft-verdt-netmod-yang-semver-00 tries to express.

I argue that it is better to indicate an NBC bug fix to a client than to either (i) make the NBC bug fix but be unable to indicate it, or (ii) not be able to fix an obvious bug in the model in case it might break a client.  At least with semantic versioning a client is able to check whether they might get broken.

> 
> > > > 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.
> > >
> > > The client<->server interop will not magically work better if we
> > > allow NBC changes.
> > [RW]
> > It helps clients understand the nature of the changes.
> 
> The draft we talk about does not mention anything about helping clients
> understand the diffs, BC or not.

That part of the work is still TBD.  Section 1.2 of draft draft-verdt-netmod-yang-semver-00 talks about this.

I still think that a tooling based module and schema comparison tool is important, but it probably will require additional module annotations to be properly useful.

But I also still believe that having a semantic version number can greatly help a module reader, in conjunction with the revision history, understand the nature of the changes.



> 
> > I don't believe that vendors are making NBC changes to make client
> > lives harder, they are trying to fix bugs and make their software
> > better.  I obviously agree that it would be better to put more effort
> > into producing higher quality models in the first place, but there
> > will always be mistakes, particularly for vendor models that have much
> > less peer review than YANG modules produced by SDOs.
> >
> >
> > >
> > > > 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.
> > > >
> > > > 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).
> > >
> > > I fully agree.  This is difficult in the general case.  In the worst
> > > case you'll have to give up on backwards compatibility and only
> > > implement the new version of the module (I believe this is possible
> > > both with the current versioning rules, and with the proposed
> > > rules).
> > [RW]
> > Implementing a new module and not supporting the old to fix one leaf
> 
> This is a strawman; I never recommended changing an entire module to fix one
> leaf.

This is not intended as a strawman.

How would you propose handling this change whilst keeping within the RFC 7950 rules?  My understanding is that if this change was required then the only option within the RFC 7950 rules would be to create an entirely new module, with the massive impact that I describe.

I.e. I don't think that the existing rules have a viable solution for this sort of problem.  For config false nodes, adding duplicate nodes & deprecating is fine.  For config true nodes, I'm just not convinced that the current scheme works of adding a second configurable leaf works in a robust way.  

In particular, within a YANG schema I think that there should only be a single path for configuring a property (putting aside hierarchical config which is OK).

> 
> 
> > has a massive impact:
> >  - it breaks all clients using that module (regardless of whether they
> >    were using the leaf)
> >  - it forces updates to all modules that augment or depend on the old
> >    module.
> >
> > Say we hypothetically decide that "link-up-down-trap-enable" in RFC
> > 8343 is wrong should be mandatory true.  Is the right solution here
> > really to define a new "ietf-interfaces-2" YANG module and require all
> > 50 or so YANG modules that augment IETF interfaces to be updated?
> >
> > It seems that this would be a much more impactful change than allowing
> > an NBC change to that module, and documenting that as version 2.0.0.
> >
> > I am sure that if YANG allows NBC changes then some folks will use
> > them for purposes that they should not.  But I also believe that those
> > same folk will make those same changes regardless of what an RFC
> > states.  But I also think that many vendors will try and use NBC
> > changes as a way to make their models better, improve the quality of
> > YANG data models.
> >
> >
> > >
> > > > 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.
> > >
> > > But this is not what the draft is about!  There is nothing in the
> > > draft that talks about problems introduced by using the revision
> > > dates.
> > [RW]
> >
> > I think that "revision-date" and RFC 7950 section 11 module update
> > rules go hand in hand.
> >
> > If your objection is that we don't quite describe the problem clearly
> > enough then that can be fixed.
> >
> >  My interpretation is that your objection is more fundamental than
> > that.
> 
> Yes.
> 
> >  I.e. you don't think that we should be using semantic  versioning at
> > all
> 
> My objection is that I don't agree with the problem statement and I don't think
> that we should allow NBC in published modules.

But on a practical level this seems to be the same as stating:

"Published YANG modules MUST never have any bugs in any config true nodes."

Thanks,
Rob


> 
> 
> /martin
> 
> 
> > , and we should keep RFC 7950 section 11 rules and  revision dates for
> > versioning YANG models.  But I think that the  overwhelming evidence
> > is that the current scheme does not work for  everyone, even if it
> > might be sufficient for YANG modules produced in  the IETF.
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > -----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-r
> > > > > eqs-
> > > > > 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
> > > >
> >