Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sat, 27 October 2018 21:14 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 CE2701277D2 for <netmod@ietfa.amsl.com>; Sat, 27 Oct 2018 14:14:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 w9nI60ERSH4c for <netmod@ietfa.amsl.com>; Sat, 27 Oct 2018 14:13:59 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98AF130DE8 for <netmod@ietf.org>; Sat, 27 Oct 2018 14:13:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7F81BE50; Sat, 27 Oct 2018 23:13:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wBbxwPX_yTlt; Sat, 27 Oct 2018 23:13:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 27 Oct 2018 23:13:57 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 425F12003C; Sat, 27 Oct 2018 23:13:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lqdHNKPJvsS3; Sat, 27 Oct 2018 23:13:56 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A46EE2003B; Sat, 27 Oct 2018 23:13:56 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Sat, 27 Oct 2018 23:13:56 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 024123002AC391; Sat, 27 Oct 2018 23:13:55 +0200 (CEST)
Date: Sat, 27 Oct 2018 23:13:55 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org> <a0392622-4405-8286-374b-effd652114cd@cisco.com> <sa636st2a97.fsf@chopps.org> <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de> <CABCOCHS6Vp6=HS6HPztDqojh=U84LuwbAJGB73HA01S9ukjfZg@mail.gmail.com> <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de> <CABCOCHQUwFvLVz-kHPofNc6n4TG=+6Vj3dK87LqLrH=vtzVQcQ@mail.gmail.com> <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de> <CABCOCHRmcqpffXYcOOeZA7hy=NRhK8RAF8KcJYpht+Mp9g8qkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABCOCHRmcqpffXYcOOeZA7hy=NRhK8RAF8KcJYpht+Mp9g8qkQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JdZpj_-QvhsXeoULzgOKODqLbAw>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
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: Sat, 27 Oct 2018 21:14:02 -0000

On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> 
> This is what we have today only if modules are updated in legal ways.
> The 3.1 requirement says this backward compatibility is maintained even
> if the module is updated in violation of the module update rules.
>

It is stating a requirement. How solutions meet the requirement is for
the solutions to figure out.

> How would 3.1 be met if the WG decided to just add a new 'datastore'
> key leaf to the /modules-state/module list?

Depends on the solution I guess.
 
> IMO the current "deprecate and start over" is actually the easiest
> and most robust solution path, and it requires no changes to YANG or
> the protocols.

Yep. But there are people who think that other solutions can do
better. The challenge is to find out whether they actually do better
or for whom they do better (and if someone has to pay a price for it).
For having this discussions, it is good to write down requirements.

> >        3.2  The solution MUST provide a mechanism to allow servers to
> >             simultaneously support clients using different revisions of
> >             modules.  A client's choice of particular revision of one or
> >             more modules may restrict the particular revision of other
> >             modules that may be used in the same request or session.
> >
> > Today, the version number is effectively an (implicit) part of the
> > module name (plus the revision date for backwards compatible changes).
> > Hence, my understanding is that today's model does satisfy 3.2 as
> > well.
> 
> This is not what we have at all. RFC 7950 says a server can only implement
> one revision of a module.
>

A new version today essentially means a new module name and I do not
see a conflict with what I wrote.

> > If we want to increase 'agility' in an attempt to make it easier to
> > deliver early designs and to fix them on the go, the costs will go up
> > somewhere. The extreme cases are:
> >
> > 1) The server can make changes to YANG modules in arbitrary ways and
> >    the clients have to adapt, i.e., clients have to pay the bill.
> >
> > 2) The server has to provide strict backwards compatibility in order
> >    to not break clients, i.e., servers have to pay the bill.
> >
> >
> This is not correct. Implementing multiple incompatible revisions of a
> module
> (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> server developer.

Depends on the details and the developer will decide based on the
impact on the clients and whether a transition period is possible. You
seem to read that the requirement says one has to implement backwards
compatibility. This is not what the text says. The text says it must
be possible.

> > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > important requirements.
> 
> I do not agree with the premise that non-compatible data model updates are
> required.
> 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> a new(much more complicated) version of YANG

I think you misread the requirements text.

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