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

Andy Bierman <andy@yumaworks.com> Fri, 09 November 2018 11:38 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 8B3E7130DEB for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 03:38:11 -0800 (PST)
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 IWNOEep_yr2p for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 03:38:07 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 4BEDB130DDA for <netmod@ietf.org>; Fri, 9 Nov 2018 03:38:07 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id f3-v6so1296395ljk.9 for <netmod@ietf.org>; Fri, 09 Nov 2018 03:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KAto7xOLUsrxqC2WWuwMw0xRqmMXYn4ss1E9RiAYyQc=; b=X1Qs1MwWmAPfJnRjwkiFH/X+W2ZriB3BTu8F4yIG5xLo446GtGYKGO1LgtuW3CjHM5 CVhN25OD2QAFiZ6vvgjZRTOrX0Izv+Io54PER1d/qCifox0ND1qIwwhiFsJ50HrBlL3T rBu9bRsaG8qwUlUoF/nR9wVnB7JJcQXlLjZ9Qgzgkf5c9ZIsOmwx/4FyYlZewcP8+A/1 N8ZjvNpgeR3SC8xPaLvLWnSdEEhdY0eCw1vowY0p0b6FbV2t2ViH/N5uzt+LO+nsQnc6 KlEHJGXEXscPKVXeI9oRFK1qpfqmhpvuWw1ppI9Y4h0VNcjD5bJ113OKzTfkrzKWezLY a+cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KAto7xOLUsrxqC2WWuwMw0xRqmMXYn4ss1E9RiAYyQc=; b=VzuNggdwq9LOYneRODydS5cYvtLwS2qWIag5lWiMcacgJ4E2rCSZ/GJmon43x7lSGC WmpNTAdUpf57CYy+h/evm4nohSq/JUmvNI1s4/laceJBUu/W7rSnPq6uo5ZphSTauh1F jIb868yGVEnPmOtRRyoASRLXds8Rz33z5mjVZV/BZfxaSLmkKhtb9xCcTYs6Bpkr829W 2D+14c8bcM3eUiw50Q5ddWadGymMgnrptD73WVdhFnW2Uxvwxg2BX4qheLDGPo2midVN nnsrVzHfYffdfiEnjqY6ennBM4pngGC8W98XLcBCSOp2P16mv3RuscET61EIxCv6pujt qnPw==
X-Gm-Message-State: AGRZ1gLQmMu4nRPkCWMiKceK7qrV8HWK4xJ0EJa2ORCNi1QqfqJrkCHI mTYT6bqpMfVEF9KdoiwNOhOWoR40FSroFQEEFDEcBI7n
X-Google-Smtp-Source: AJdET5cOmx06iL92BtPOzultGNeCdgxltI18zA3gEQmYpALPlcSYjg0Y2/c6vkJx3JhPZmETurHR373s2RjsZNFBozM=
X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr4671565ljo.10.1541763485316; Fri, 09 Nov 2018 03:38:05 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 9 Nov 2018 03:38:03 -0800 (PST)
In-Reply-To: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
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> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 09 Nov 2018 03:38:03 -0800
Message-ID: <CABCOCHQ_gyiQMaDDnLZE4aJ-xBp5cNHFjASpHsCHWni=cBK2_A@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dee7fb057a39c8b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/S0wlpx3NjZhXFNoX3tNKLiEayDI>
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 11:38:12 -0000

On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

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

This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.



> 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.
>
>
As Balazs asked, how can the data node be a boolean and an integer at the
same time?
There seem to be plenty of scenarios that cannot be implemented
simultaneously by a server.



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


I understand the transformation approach (am have implemented something
like it).
This only works if the mapping is complete.  If there are any holes in the
mapping
then the affected nodes are lost.  Vendors have already proven they
can implement this approach without any new standards.

Vendors are already releasing updates to old module revisions by managing
the revision date.
I agree SEMVER is incrementally better than that.

I do not agree that more than 1 revision of a module can be implemented.
A server can have multiple "outside" schema that gets transformed to the
real "inside" schema.
This is fine and breaks no YANG rules.  It also requires no additional
standards unless the
transformation mechanism is going to be standardized.



> /js
>


Andy


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