[netmod] Deviations and augmentations

Robert Wilton <rwilton@cisco.com> Mon, 12 November 2018 16:29 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 410AD130E1D for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 08:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 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, 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 tc_XqgyyntK6 for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 08:29:27 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.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 707AE130E53 for <netmod@ietf.org>; Mon, 12 Nov 2018 08:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1542040164; x=1543249764; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=8fhWIFSkXGkjzz5+islBrOFCa+iaPPcRtW6TR9WycHw=; b=M/T0eaSthDtmFIVG2VgkOPeOpap0tqQCPGpMLjGRPAdgY8P/+dKfAYLw VwemYTtd9zdT/sTPsjMWIcMgGh+vgKl8C3JcKWKhJCKs6yjqD8UVZoTy/ 8EHEDO5eeb35sianQPyGsX9tLHJlOCl9HippbXrVRoU0V5FrwU9zyZpzA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgDpqOlb/xbLJq1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYFWgWMhEoQfiHeNA5lUDYg9OBYBAwEBAgEBAm0dC4VkDwEFdgImAl8?= =?us-ascii?q?NCAEBgx2CAqlWgS+FPoRmgQuLDIFAP4E4DIIyAYUUgxqCVwKJPpYRCYFijzU?= =?us-ascii?q?GGIlWhxqRIIZYgVohgVUzGggbFYMokFk/A45EAQE?=
X-IronPort-AV: E=Sophos;i="5.54,495,1534809600"; d="scan'208";a="7998906"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 16:29:22 +0000
Received: from [] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com []) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wACGTLY1003300 for <netmod@ietf.org>; Mon, 12 Nov 2018 16:29:21 GMT
To: "netmod@ietf.org" <netmod@ietf.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <a8c912c8-a7a5-1852-d053-10f0f11076e8@cisco.com>
Date: Mon, 12 Nov 2018 16:29:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client:, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nyQCungc38-gkXCvwaoMCogHpBU>
Subject: [netmod] Deviations and augmentations
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: Mon, 12 Nov 2018 16:29:28 -0000

In the Thursday Netmod meeting, it was interesting to hear Rob Shakir 
describe how deviations and augmentations are used in OpenConfig to add 
functionality into an older YANG model where the semver rules prevent 
the version number from being incremented.

Further, I think that someone (Martin?) stated on the audio bridge that 
this was an intended/allowed behavior for deviations.

This surprised me, because I thought that RFC 7950 was quite explicit 
that this is not what deviations are intended for.  My reading of RFC 
7950 is that the deviation statement represents the case where the 
server *implementation* does not match the *specification*.  However, 
the versioning issue that we are discussing are bug fixes/changes in the 
specification rather than the bug fixes in the implementation.

Personally, I'm really not keen on using deviations to represent bug 
fixes to older YANG models for three reasons:

(i) It is changing the meaning of deviation.  It is much cleaner to keep 
the meaning of deviation statements as they are defined today, and not 
conflate their semantics.
(ii) A different mechanism is used to put a bug fix into an older branch 
rather than in the head of the development.
(iii) For clients to track the lifecycle of modules they would not only 
need to know the module version number but would also need to find and 
track all associated deviation modules.  This seems significantly more 
complex for clients than the modified semver that was proposed.


I think that has also been some suggestion that augmentations (or 
duplicate YANG modules with their major version number changed) can be 
used to make bug fixes in a completely backwards compatible way.  
However, I still don't understand a robust scheme of how this works.


Finally, there were some comments about using augmentation modules for 
enhancements.  This is fine, where appropriate (e.g. a non trivial 
number of data nodes are being added as an enhancement) then a separate 
module may be the right way to go. But here, I presume that the new 
functionality will always be tracked by that separate module.  If that 
functionality folds back into the original module at some point in the 
future, then obviously a non backwards compatible version change is 
being forced on to the client, along with additional work on the server 
as well.

I think that there are also many cases where the number of data nodes 
being added via an enhancement is small compared to the size of the 
module being updated.  In this case I believe that it better to add 
these data nodes into the module itself, perhaps predicated under 
if-feature if appropriate.