Re: [netmod] Deviations and augmentations

Balázs Lengyel <balazs.lengyel@ericsson.com> Tue, 13 November 2018 13:47 UTC

Return-Path: <balazs.lengyel@ericsson.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 030BD12F1A6 for <netmod@ietfa.amsl.com>; Tue, 13 Nov 2018 05:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.068
X-Spam-Level:
X-Spam-Status: No, score=-3.068 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PRmnsp1b; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZSRcLsSr
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 A4LqJPxspJab for <netmod@ietfa.amsl.com>; Tue, 13 Nov 2018 05:47:15 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC71712D4EE for <netmod@ietf.org>; Tue, 13 Nov 2018 05:47:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542116832; x=1544708832; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zcvYfCoNUhsTlyEmYU+JyMdcQkIGTHJzHdqGWzuoxos=; b=PRmnsp1bb1gsZB6cGRDcOK0UtQZhEN1u0gA0RTls1mZSYvhp1LmpTWCRtOjroxgd gd8xoN4Zoi+USSLckVO6Atbf7aneKGkSYt9t+LWnWQucmCnYwvYD41qARNw0vuoH iVSMOfwO5saXympSXpD8QKpQfLR/oif6Jxc+lUpzLYk=;
X-AuditID: c1b4fb30-f2dff700000043c4-ac-5bead5e0f878
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.1A.17348.0E5DAEB5; Tue, 13 Nov 2018 14:47:12 +0100 (CET)
Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB502.ericsson.se (153.88.183.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:47:12 +0100
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:47:02 +0100
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 13 Nov 2018 14:47:01 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Jj0HQsudaXIuKiltCx2Uq+5d/THJYCBtXeFPtv6S6g=; b=ZSRcLsSrI0ZVwKWVc7VyrjN6tvYZprxem/KnOzWVmcy402y9hPXyaGByf2N+abkj8KEyF5EhlA+eAn4KpUDFUFeEtewMHLsc4pafz+R+rYpTtf6LwIO/swpETRuolEPLLusJ0loeL74RpBl4cGivFL550BSf6dqUWrId23FX1qw=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2350.eurprd07.prod.outlook.com (10.168.137.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.12; Tue, 13 Nov 2018 13:46:59 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1339.019; Tue, 13 Nov 2018 13:46:59 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Deviations and augmentations
Thread-Index: AQHUeqpc7mk2gryvX0i0YxVu+tJ6OaVNuVoA
Date: Tue, 13 Nov 2018 13:46:59 +0000
Message-ID: <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
References: <a8c912c8-a7a5-1852-d053-10f0f11076e8@cisco.com> <20181112.173351.1984161388756642220.mbj@tail-f.com> <cbe0103b-112e-4687-e119-0698ea6cb9f4@cisco.com>
In-Reply-To: <cbe0103b-112e-4687-e119-0698ea6cb9f4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
x-clientproxiedby: HE1PR0701CA0047.eurprd07.prod.outlook.com (2603:10a6:3:9e::15) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2350; 6:kI7pKvYitdakmkeCHniuaerTV1FKsNI2j/8AGudWV/MH3Su9zewwehn6R2Iy/iKOZl89cMF68NUCblc2QJsz0+SAk1t9wBpfay/XZ/agg0AXWtOnMX7+vDGfvG4xNHawg7zCNrUqa71iTQPwFev0L5DdiF/7JIZN4BA/cEMRx4Z9PWYbxlAK8wSHSgnREYPE+dNB7qgOn1IjWXU5k7fjzLM9iQlFVYI4v4Fad+DXUri6jJPPSXeN8jIOsL5BungGLwfQ8D5mOR6S/uUOmbxsBSufFuaJ3Ui/DI5D95oKDncxQj5HTKMG0O1nfuVJc5IBugJL7ig8vZ5fgeaw9wwicUDSK3sFruZV1WmTaMrHXVYSmwVLAFUOEL/mPG92ec62N2JdnyDPU5vwdj5/jC2PKJy3aIvCafqvJH7XXKnRfPd7Mh9oyocL2kVxJPt9GIMKfn6DSSVGmvWhqFSH/XKlrA==; 5:wbVoDYh4wZfdgRBujiBIPKg85R3GIjkWvlb9wJX0FEdo3aRNFn4nDS/sWqwMZDTtJ4LH8lJkuCiwBU2KpfwQ7pmBS5VS13+G7SxOokxS0dvtwOw769TZKaI33WbCn9Fqh0bUNIccPyNaymTHwXrhb+Pn3s1pU4v3Cur/iciuv10=; 7:Oz8AzCYz219TmUu0qrjjdmP5C6v3xMlWocokAVJPvn4Q6AxiwKcDMe1S51l7e4Ll8J2e/8N8HYul562O2y8FE3M99XEJcE/+SjlmwYl3h51W3iCCS/OF+TPDoiWr91A0AfuCd6q/DMeZjg+xVjKwZg==
x-ms-office365-filtering-correlation-id: aeca9a39-9278-4371-9e4d-08d6496e7ba6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2350;
x-ms-traffictypediagnostic: VI1PR0701MB2350:
x-microsoft-antispam-prvs: <VI1PR0701MB23500BC052610ABCEE43B28EF0C20@VI1PR0701MB2350.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(4983020)(52105112)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2350; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2350;
x-forefront-prvs: 085551F5A8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(346002)(376002)(136003)(189003)(199004)(51444003)(252514010)(6512007)(236005)(99286004)(53936002)(99936001)(31686004)(106356001)(31696002)(26005)(14454004)(6436002)(5660300001)(54896002)(6306002)(76176011)(52116002)(966005)(2900100001)(65826007)(85202003)(53546011)(64126003)(105586002)(81156014)(81166006)(97736004)(8936002)(386003)(8676002)(36756003)(25786009)(4326008)(102836004)(3260700006)(6506007)(478600001)(256004)(71190400001)(6116002)(229853002)(6246003)(7736002)(68736007)(110136005)(14444005)(58126008)(85182001)(486006)(476003)(71200400001)(3846002)(446003)(11346002)(186003)(66066001)(65956001)(606006)(2906002)(6486002)(2616005)(316002)(65806001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2350; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: SVaxvhiqqlZgeoEKeT/IQhQC840tDkuMPJxeHTd+t0g8R5QLj+xzSZAYFfjT/dDFzgneHK3x9cRxZP5V2A/aQC3bjInCaD37jeJE6aVPoEgirI/0YGxz/LNJ2EhqCC5iYtNMn/jQ8Ng3ZxJT+4nyOlak+TAMEKKPL2sOQmTWUhC+x/5lOQkL7k0TeIp5AMuuTRcbl/pBdTtR/MUvm+wJAVearr8cf1U++EDphM6tyrgM+//fQE8dwli8qJ6X42Bxp6ahuDCm/k/AOvoKN4++OCv8wMd9Z+EQ+R/NI8aOXA4Jkf2pYxSX7984iefcYEXoq2a+w6UM9HJLdkqC38RpBi+lsdCPhE7wvRrndfJMjRQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000807020502020505030802"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aeca9a39-9278-4371-9e4d-08d6496e7ba6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 13:46:59.4094 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2350
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUjTYRjHfX/Hrhq+Lc0HS6jRRXkuo0WHmlJCGEVQYlTO/KGSzdys1P5I i/KYhYih+c8SxSxHnqFiIV6QWh6J2DxW0zXZRmJUmtq1n69C/fd5+B7P88IromUW1lOUoE7h NGpVolwgYR5FNqb6fBy2n/P/bghU6nRWoVI/mMkqX/c9oIPp8MKlWja8vHyBCq9dLGNO0lGS g7FcYsJ1TuN3OFoS/8RUJ7g6m5ya1fmUzUCms7lILAIcCD+mOhmeZbgTgWEiOhdJnDyHQP/M QBPBORgnERHKKfidZxTyA4PzafhkH2KJUkzBz885FBmsCF69aRTyeQEOg6yZVopnNxwOs5U5 LM803gHjPVMCntdjBTw3PWSJZw8UGO+vsAKqR5qXswzeBro/RU6/SCTFQWBuCiC7KhBYFzOX d4nxIWgxO5YZ4Q0w32OgyC4PGLXoKfJoNzAP9goIu4Nt6jdLWA7F9lGW73fH56HtdhDfD7gY wdi9aYZ0XoCXpuyVrDe8HbEgwl7wTq9DJPBeAE3N/QwRIiDjjk1IhHEEIx0W4Wra3FaP8pGi 5J8DS5w+Gucg6O+pEvKCFK+D7kcWpsR5FY23Q8Vd+f9+nndDRamDJnwAihfbBIS3QKHOLCS8 FxxdXxDhPVDx/JfgMZI8Q+5aThtzJU6h8OU0CZe02iS1r5pLqUPO/9bWsOTfhGzTIe0Ii5B8 rdRRZT8nY1XXtWlX2tFWZ89kTdUA8mTUSWpO7iZtDnTK0lhVWjqnSbqouZbIadvRRhEj95Aq T9RHyXCcKoW7zHFXOc2qSonEnhmoJGbB4uUy1PWhbE1NhzVX/Kegz9R9eu6bLOKWrfKr8ViE 62T/Nc0843WjZcRDtS/95YubyagoUu6dHTbRPnEqKtktYbjDMKMe+nYrovWo62yp30xo85i4 N+9M8KaGwNA5QzDEjO6sb/KPG3OU+lC2A9b6MpfqzV3Hj+wfCAmazpQz2nhVwC5ao1X9BYos kXR3AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/8JnOYXTCiPNYjdPe6CzVX0UV8gc>
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: Tue, 13 Nov 2018 13:47:23 -0000

Hello,

We also need a method for removing stuff. It does happen that some functionality is deemed not important enough, outdated, too expensive to maintain, so we want to remove it.

  • Augment is clearly not the tool for that.
  • Deviations are not intended for that  (from rfc 7950: "server deviation: A failure of the server ...")

So we still need Semver(or something akin) and the possibility to do NBC changes.

Balazs

On 2018. 11. 12. 18:08, Robert Wilton wrote:


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" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod
.


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod" rel="nofollow">https://www.ietf.org/mailman/listinfo/netmod
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com