Re: [netmod] Deviations and augmentations
Robert Wilton <rwilton@cisco.com> Mon, 12 November 2018 17:08 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 88E33130DF2 for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 09:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level:
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 TIn6MLMp_daQ for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 09:08:45 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB6D128CB7 for <netmod@ietf.org>; Mon, 12 Nov 2018 09:08:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1542042525; x=1543252125; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wB3aWoSEdWfgUynWO+X0eD+D7ZMv+M0nmrWB+gNN6bc=; b=dor3TTfCA9eA3PpdS2AbFRRxJnHb//3ONbGSgjcSl6ejN7C9TMvo7Wlq +zYTgZJcqbSlpM1luDbf0LodPZpxDb22JPfOmf5EeuJS5jDwt0SrxmuND CSOWi/Oz6LHgNphAkqrh2uMKZ5qQ4hEt0R6/AMlvcyY9jik1RxbRAOOqN o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AaAACPsulb/xbLJq1jGwEBAQEDAQEBBwMBAQGBUwQBAQELAYJpTyESJ4N4iHeNAyWXNYF6DRgLhANGAoNPNgsNAQMBAQIBAQJtHAyFOgEBAQMBAQEhDwEFNgsQCw4KAgImAgInMAYNBgIBAReDBgGBeQgPqTGBL4U+hGMFgQuLDIFAP4E4DIFhfoMbAQGBS4MaglcCiT6WEQmJYYc2BhiJVocakSCGWIFKByqBVTMaCBsVO4JsgicXiF6FPj8DMI4UAQE
X-IronPort-AV: E=Sophos;i="5.54,495,1534809600"; d="scan'208";a="7996274"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 17:08:42 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wACH8gPP021240; Mon, 12 Nov 2018 17:08:42 GMT
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
References: <a8c912c8-a7a5-1852-d053-10f0f11076e8@cisco.com> <20181112.173351.1984161388756642220.mbj@tail-f.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <cbe0103b-112e-4687-e119-0698ea6cb9f4@cisco.com>
Date: Mon, 12 Nov 2018 17:08:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181112.173351.1984161388756642220.mbj@tail-f.com>
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-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fs8fG5krwVplHzlM4aGquVzcLjA>
Subject: Re: [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 17:08:47 -0000
On 12/11/2018 16:33, Martin Bjorklund wrote: > Robert Wilton <rwilton@cisco.com> wrote: >> 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. > I said that using augmentations (not deviations) was one idea we > originally had for solving the "branching problem". Ah, OK. I agree that makes sense. > > I think that this works for OC b/c they don't branch their modules. > Hence I think it is important that we decide if branching is a > requirement or not. So, I think that this probably works for adding enhancements, but not for the (arguably more important) bug fix case, unless there is a reasonable solution to having two config data nodes both modifying the same underlying property. Perhaps under some reasonable constraints this could be made to work - but I don't know. Of course, even for enhancements it is not necessarily a perfect solution. E.g. backporting some subset of a module already coded/implemented in latest to an older release. And yes, we really do get asked to do this sometimes, although it is relatively rare. Thanks, Rob > > > /martin > > >> 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 mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > . >
- [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