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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 09 November 2018 08: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 A1C32130DBE for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 00:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Kti4sq7l6wau for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 00:16:02 -0800 (PST)
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 8D450124D68 for <netmod@ietf.org>; Fri, 9 Nov 2018 00:16:01 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A300AEDB; Fri, 9 Nov 2018 09:15:59 +0100 (CET)
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 dJJiHYjlTScA; Fri, 9 Nov 2018 09:15:58 +0100 (CET)
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; Fri, 9 Nov 2018 09:15:59 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C83C2003C; Fri, 9 Nov 2018 09:15:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0zHfSUGnqV7m; Fri, 9 Nov 2018 09:15:58 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (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 C13112003D; Fri, 9 Nov 2018 09:15:58 +0100 (CET)
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; Fri, 9 Nov 2018 09:15:58 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 04FBC3003CA1E5; Fri, 9 Nov 2018 09:15:57 +0100 (CET)
Date: Fri, 9 Nov 2018 09:15:57 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
CC: <andy@yumaworks.com>, <netmod@ietf.org>
Message-ID: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, netmod@ietf.org
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de> <CABCOCHRmcqpffXYcOOeZA7hy=NRhK8RAF8KcJYpht+Mp9g8qkQ@mail.gmail.com> <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181108.224220.1513800936571555652.mbj@tail-f.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/pbw1QsYiaGkEcV_lM6sFzZdatmA>
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: Fri, 09 Nov 2018 08:16:06 -0000

On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > 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.
> 
> Then I think this requirement needs clarification.  It says "different
> revision of modules", which can be interpreted as different revisions
> of *the same* module.
> 
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
> 
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.

If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

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