Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 26 July 2018 14:16 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 DC747131001 for <netmod@ietfa.amsl.com>; Thu, 26 Jul 2018 07:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dPUAOtAOZjf6 for <netmod@ietfa.amsl.com>; Thu, 26 Jul 2018 07:16:17 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id B4BDB130E58 for <netmod@ietf.org>; Thu, 26 Jul 2018 07:16:17 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id DC572238535E; Thu, 26 Jul 2018 16:16:16 +0200 (CEST)
Date: Thu, 26 Jul 2018 16:16:16 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Andy Bierman <andy@yumaworks.com>, Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
Message-ID: <20180726141616.sb5rnpv3rfaxqv46@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>, Andy Bierman <andy@yumaworks.com>, Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
References: <87va981svk.fsf@chopps.org> <CABCOCHSkpn_=04qJP9m6TUA+doCjk0=BFG6jX9T4awj+CO-QdA@mail.gmail.com> <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de> <CABCOCHQdwqB78JgNdB_UvhDTz5W-RM3XHajrhCQAgogj4T2VHQ@mail.gmail.com> <e386b70a-f99e-d631-32c2-e1092012ddff@cisco.com> <20180725110308.e3xznaszhwpt6mq4@anna.jacobs.jacobs-university.de> <1021657c-69ef-86ea-b114-dde9a814950a@cisco.com> <20180725165946.wvs7g623lzwndhd3@anna.jacobs.jacobs-university.de> <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <64b033b6-9bae-33d5-172a-1a54d6f74567@cisco.com>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/S_L6yiCdGPDyvkXFHNja-BwE3TI>
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 26 Jul 2018 14:16:20 -0000

On Thu, Jul 26, 2018 at 11:19:07AM +0100, Robert Wilton wrote:
> 
> I think that some aspects of versioning are the same problem.  E.g. I think
> that there is a difference between a major release where more backwards
> compatible changes could be expected, vs maintenance releases where one
> would expect backwards compatibility should likely be preserved.
>

Well 'could be expected' and 'would expect backwards compatibility
should likely be preserved' is kind of hand-waving. There are often
situations where people are reluctant to bump major version numbers
just because a tiny bit of an API has changed in a non-backwards
compatible way - for the same reason that you brought up. Most of the
definitions did not change, so people do not want to bump the major
version.

> This was similar to a comment above.  I don't like the (module, path) of a
> data node having to change (due to a module name change for a major version)
> if its definition hasn't changed at all.

Fine. Then you deprecate the broken foo and create foo'. You do not
like that because you do not want foo and foo' at the same time. But
others want deprecated objects to stay to allow a transition period.

> Yes, both of these are right.  And partly it is a chicken and egg problem. 
> We would like clients to migrate from CLI to YANG, but that requires stable
> models, but don't want to invest heavily in creating stable models in YANG
> if customers are not using it. Having two separate sets of standard models
> (e.g. IETF and OpenConfig) doesn't help either.

So do we hit a requirement (which is independent of versioning) that a
mechanism is needed to select different module sets (or views), given
that the reality gives us overlapping and competing models? And then
as a side effect, such a mechanism may also be used to select between
different versions?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>