Re: [netmod] import-by-semver issue

"Rob Wilton (rwilton)" <rwilton@cisco.com> Sun, 24 March 2019 15:29 UTC

Return-Path: <rwilton@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 79471130E91 for <netmod@ietfa.amsl.com>; Sun, 24 Mar 2019 08:29:58 -0700 (PDT)
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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 NwDgGsGowqnN for <netmod@ietfa.amsl.com>; Sun, 24 Mar 2019 08:29:56 -0700 (PDT)
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 77E70130EAA for <netmod@ietf.org>; Sun, 24 Mar 2019 08:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7780; q=dns/txt; s=iport; t=1553441396; x=1554650996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3OEwDhRhQAATNaP6kG9l2narFYohQneSrC3ooEk5/Nw=; b=UVtZ3zU/YKLJuu75p54tI2OrfF8+Aeg7RRhMBgVbG3pu3Op/nj7GdQd2 xbyFcREQmIYs75qbWp6jGuFHGOQ5fVDwn6TF+iDMcql/6qizN90RZnAAP E5gvWfMo7AsedfzQqPoCfZ8OUvgWmbdFhM4absp1EaSuoH+G6rvZ1Cvkp s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAwoZdc/4cNJK1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYFhL2iBAycKhASVSJo1DQEBGAuEA0Y?= =?us-ascii?q?CF4RlIjcGDQEBAwEBCQEDAm0cDIVKAQEBBAEBIRE6CwwCAgIBCA4CAQQBAQE?= =?us-ascii?q?CAiYCAgIZDAsVCAgCBA4FCBODCIF1D6wfgS+KHwUFgQYkAYsxF4FAP4ERgxI?= =?us-ascii?q?+gmEBAYFLLQomgkOCVwOKaoIGmCYJApMvIZN+nkYCERWBLjUigVZwFTuCbIY?= =?us-ascii?q?rhGGFP0ExjnOBHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,256,1549929600"; d="scan'208";a="249230996"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2019 15:29:55 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2OFTtnr028216 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Mar 2019 15:29:55 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 24 Mar 2019 10:29:54 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Sun, 24 Mar 2019 10:29:54 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] import-by-semver issue
Thread-Index: AQHU4arYjIn8/1YI30euxcwhgGMsT6YahbWggABuJwD//9uzgIAAXWcA//+zwcCAAFpIAP//rGjA
Date: Sun, 24 Mar 2019 15:29:54 +0000
Message-ID: <468413dab2794f46979abafb2cb33c43@XCH-RCD-007.cisco.com>
References: <4c0a8dca338f4ca384dea933f046511e@XCH-RCD-007.cisco.com> <20190324143116.evgabiqpmz5gwgem@anna.jacobs.jacobs-university.de> <de771cdd329046cfa42a92d8d8ecf525@XCH-RCD-007.cisco.com> <20190324.162130.857835975235711028.mbj@tail-f.com>
In-Reply-To: <20190324.162130.857835975235711028.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.79.96]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fP9Iun-c9Nv6snd-wr2jDx0Ld_I>
Subject: Re: [netmod] import-by-semver issue
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: Sun, 24 Mar 2019 15:29:58 -0000


> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>
> Sent: 24 March 2019 16:22
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] import-by-semver issue
> 
> "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote:
> > Hi Juergen,
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > > Sent: 24 March 2019 15:31
> > > To: Rob Wilton (rwilton) <rwilton@cisco.com>
> > > Cc: Andy Bierman <andy@yumaworks.com>om>; NetMod WG
> <netmod@ietf.org>
> > > Subject: Re: [netmod] import-by-semver issue
> > >
> > > On Sun, Mar 24, 2019 at 02:07:15PM +0000, Rob Wilton (rwilton) wrote:
> > > > Hi Andy,
> > > >
> > > > There are many ways to write and design compilers.
> > > >
> > > > Compilers that don’t understand import-by-semver just ignore the
> > > > extension,
> > > no deviation is required.  They just import whichever arbitrary
> > > revision that they would have imported anyway, as specified by YANG
> > > 1.1.  The import-by-semver statement just reduces the set of valid
> > > modules revisions that can be used for import.
> > > >
> > >
> > > If two compilers (one supporting semver, the other not) resolve
> > > imports differently, then the design is in my view somewhat broken,
> > > in particular if you allow NBC changes.
> >
> > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section
> > 5.1.1 in RFC 7950).
> 
> This is by design, of course.  With an "open" import (not import by revision), the
> server implementor is free to implement any set of modules that work together.
> 
> > So, I would argue that "import-by-version" doesn't make YANG compilers
> > any less consistent that they are already today, since that
> > inconsistency already exists.
> 
> I don't think I understand Andy's objection.   I also think that this
> is just another implementation detail.
> 
> > I presume that the real solution here is to explicitly define the full
> > set of implemented, import-only-modules to the compiler so that it
> > always compiles a consistent schema.  Perhaps other compilers have
> > different ways to solve this problem.
> >
> > Note, I also think that YANG library has a similar inconsistency.
> > I.e. there is no guarantee that two different compilers will construct
> > exactly the same datastore schema from the YANG library output.
> 
> Can you elaborate?  Given an instance of YANG library, it should be clear which
> set of modules are used.

For modules that are "import-only" rather than "implemented" then some modules might use import-by-revision to import a specific revision, and other modules might just use import (without revision).  In this case, the compiler can choose which revision it uses to satisfy that import (e.g. getting different grouping definitions).

In draft-verdt-netmod-yang-semver-00, we aim to resolve this ambiguity with the following text that incorporates semver, a similar solution or just using the latest revision dates could also be devised:

5.2.  Resolving ambiguous module imports

   A YANG datastore schema, defined in [RFC8525], can specify multiple
   revisions of a YANG module in the schema using the 'import-only'
   list, with the requirement from [RFC7950] that only a single revision
   of a YANG module may be implemented.

   If a YANG module import statement does not specify a specific version
   or revision within the datastore schema then it could be ambiguous as
   to which module revision the import statement should resolve to.
   Hence, a datastore schema constructed by a client using the
   information contained in YANG library may not exactly match the
   datastore schema actually used by the server.

   The following rules remove the ambiguity:

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and one of those revisions
   is implemented (i.e., not an 'import-only' module), then the import
   statement MUST resolve to the revision of the module that is defined
   as being implemented by the datastore schema.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and none of those revisions
   are implemented, but one of more modules revisions specify a YANG
   semantic version, then the import MUST resolve to the module with the
   greatest version number, according to the version comparison rules in
   Section 3.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, none of those revisions are
   implemented, and none of the modules revisions have a YANG semantic
   version number, then the import MUST resolve to the module that has
   the most recent revision date.

Thanks,
Rob


> 
> 
> 
> > I
> > think that this is a design bug, but also one that we attempt to
> > address in draft-verdt-netmod-yang-semver-00.
> >
> > Thanks,
> > Rob
> >
> > >
> > > /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/>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod