[netmod] import by revision and updated modules

Robert Wilton <rwilton@cisco.com> Mon, 02 October 2017 15:57 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8886A13304D for <netmod@ietfa.amsl.com>; Mon, 2 Oct 2017 08:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.801
X-Spam-Status: No, score=-11.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XDVQxIoFWIpO for <netmod@ietfa.amsl.com>; Mon, 2 Oct 2017 08:57:57 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2BE132811 for <netmod@ietf.org>; Mon, 2 Oct 2017 08:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1888; q=dns/txt; s=iport; t=1506959876; x=1508169476; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=8FiRAnjZgarHZEM2hOda67GebqXERWF9QuyZ/F2Kmxk=; b=QbRAQnuJrxq+cHlTvuT4RCjZaxio4Re2ZSUzAtisgj9UjOgVGwzFAcF7 AUtOhrsSkBxqg4lz7cqnL1hCdah5v1qEgCiwQZPPpB4h2mpzyhclMMmdS 5wWjyOvjugUzG5jufG0OkRkjOq7byd36z75NS+4lHjt2LaKOyDT7ZdrvM M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQCyYNJZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhS+EIIsTqSMKikEUAQIBAQEBAQEBax0LhUIPAQV2AiYCUwwNCAEBF4o?= =?us-ascii?q?VlTGQEYIniy0BCyaBDoIfg1OCFYd0gyCCYQWhMpRli12HLI15h1uBOTYhgQ4yI?= =?us-ascii?q?QgdFYdnP4gGgkEBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,470,1500940800"; d="scan'208";a="656157489"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 15:57:52 +0000
Received: from [] (dhcp-ensft1-uk-vla370-10-63-23-52.cisco.com []) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v92FvqfQ021460 for <netmod@ietf.org>; Mon, 2 Oct 2017 15:57:52 GMT
From: Robert Wilton <rwilton@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <4cd17980-d898-58cf-3c01-5d8fafadca04@cisco.com>
Date: Mon, 2 Oct 2017 16:57:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2FNYIHebh98ODDzxCbjw_4odgis>
Subject: [netmod] import by revision and updated modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 02 Oct 2017 15:57:58 -0000

Ideally, I think that it would be good if the ietf-routing module could 
be upgraded in place without a namespace change.

However, one problem with this approach is that it looks like YANG's 
"import by revision" doesn't help in the way that one might hope:

If ietf-routing is published with revision B, then ideally all the 
modules that are augmenting from ietf-routing would be able to indicate 
that they need at least revision B.

The YANG import revision-date keyword doesn't help because that means 
that they have to import exactly revision B.  So we could have 30+ 
augmenting modules that all import with ietf-routing revision B.  E.g. 
if import revision-date was used then what happens when a new revision C 
of ietf-routing needs to be provided, perhaps to add an extra leaf?  
Suddenly all those modules that previously used revision-date to import 
revision B would need to have a new version published to import revision 
C! Naturally, this problem would recurse down to all other augmenting 
modules, anywhere where import by revision is used.  This sounds like it 
would be a maintenance nightmare.

It seems like the "import with revision-date" functionality in YANG may 
not help with this upgrade problem, and perhaps a more useful variant 
would be an "import with at least revision X" that would accept any 
revision X or later.  This might be another feature request for YANG 
2.0.  Or perhaps this could be solved more elegantly with some proper 
semantic versioning of YANG modules.

I guess that for ietf-routing, the pragmatic solution would be for 
dependent modules to use 'import' and not 'import by revision'.  Perhaps 
with a comment indicating which module they are dependent on.

Thinking about it further, I am slightly unsure when using "import with 
revision-date" is a genuinely good idea.