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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 09 November 2018 13:54 UTC

Return-Path: <rrahman@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 65AB8130E03 for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 05:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 d-qJZW5HCt9H for <netmod@ietfa.amsl.com>; Fri, 9 Nov 2018 05:54:43 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9114E130DFF for <netmod@ietf.org>; Fri, 9 Nov 2018 05:54:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22104; q=dns/txt; s=iport; t=1541771683; x=1542981283; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pHjw6aMSYa6mUm8j700ob4Xu1BtAjMzdKCwqeq3Pt6E=; b=Ps3MkrVNdHTWVTbQP1isa7TRuudKOSqwGff3yZU/WcawW7hlNCLMKH5i TmK1EVkG9EGDpQzgJuEUXF3bkg5QqGp5aMvVdSZcTSc/eI90xCGfgZ/X2 nBR//PtJLYDR5B0i55gyZrc2XsBVM1UABM8lILoMM8wz03Lzoyoj2CBDK c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACvkOVb/4gNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDbogYi3uCDZFehVSBegs?= =?us-ascii?q?BASOESQIXgwsiNA0NAQMBAQIBAQJtHAyFOgEBAQEDIwpKEgIBCBABAwECASc?= =?us-ascii?q?DAgICMBQJCAIEARIbgwYBgR1kD6dCgS6KHQWLfBeBQT+BEScfgU5+gxsBAQI?= =?us-ascii?q?BgUgkEhaCTjGCJgKJHSBMhGIXhhiKMgkChnGKJhiBV48XiVaDS4opAhEUgSY?= =?us-ascii?q?dOIFVcBU7KgGCQQmCR4hMhT5BMQEBi3CBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,483,1534809600"; d="scan'208,217";a="199021327"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 13:54:42 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wA9DsgRd002579 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2018 13:54:42 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Nov 2018 07:54:41 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 9 Nov 2018 07:54:41 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUbQzN26pBXqFS9Uuo4XPBFQXcdaUxl7WAgAB13oCAAGvkAIAACa0AgACW4gCAAFffAIAAe8KAgBL0rgCAALEIgIAAOHeA///SWAA=
Date: Fri, 9 Nov 2018 13:54:41 +0000
Message-ID: <6A766C10-92D0-465E-A3D9-FB54086E2510@cisco.com>
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> <CABCOCHQ_gyiQMaDDnLZE4aJ-xBp5cNHFjASpHsCHWni=cBK2_A@mail.gmail.com>
In-Reply-To: <CABCOCHQ_gyiQMaDDnLZE4aJ-xBp5cNHFjASpHsCHWni=cBK2_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.214]
Content-Type: multipart/alternative; boundary="_000_6A766C1092D0465EA3D9FB54086E2510ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TC1moYbT6sLahsNdNJIr6vBW-so>
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 13:54:48 -0000

From: netmod <netmod-bounces@ietf.org> on behalf of 'Andy Bierman' <andy@yumaworks.com>
Date: Friday, November 9, 2018 at 6:38 PM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>de>, Martin Bjorklund <mbj@tail-f.com>om>, 'Andy Bierman' <andy@yumaworks.com>om>, NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt



On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto: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<mailto: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.
<RR> I disagree, per https://tools.ietf.org/html/rfc7950#section-4.2.1
   A server may implement a number of modules, allowing multiple views
   of the same data or multiple views of disjoint subsections of the
   server's data.  Alternatively, the server may implement only one
   module that defines all available data.


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.
<RR> Correct, but some scenarios can be implemented. IMO we should document the type of changes where this would or would not work.

Regards,
Reshad.
<snip>