[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [173.38.203.51]) (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: A0DcAgDpqOlb/xbLJq1jHAEBAQQBAQcEAQGBZYFWgWMhEoQfiHeNA5lUDYg9OBYBAwEBAgEBAm0dC4VkDwEFdgImAl8NCAEBgx2CAqlWgS+FPoRmgQuLDIFAP4E4DIIyAYUUgxqCVwKJPpYRCYFijzUGGIlWhxqRIIZYgVohgVUzGggbFYMokFk/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) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 16:29:22 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) 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: 10.63.23.62, 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. Thanks, Rob
- [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Martin Bjorklund
- Re: [netmod] Deviations and augmentations Andy Bierman
- Re: [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Ebben Aries
- Re: [netmod] Deviations and augmentations Balázs Lengyel
- Re: [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Andy Bierman
- Re: [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Andy Bierman
- Re: [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Andy Bierman
- Re: [netmod] Deviations and augmentations Juergen Schoenwaelder
- Re: [netmod] Deviations and augmentations Robert Wilton
- Re: [netmod] Deviations and augmentations Juergen Schoenwaelder
- Re: [netmod] Deviations and augmentations Andy Bierman
- Re: [netmod] Deviations and augmentations Robert Wilton