Re: [netconf] System capabilities versus augmenting-extensions

Balázs Lengyel <balazs.lengyel@ericsson.com> Fri, 09 July 2021 11:53 UTC

Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED13A1E89; Fri, 9 Jul 2021 04:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 73LmnmnjLzci; Fri, 9 Jul 2021 04:53:31 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.51]) (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 2A3A63A1E88; Fri, 9 Jul 2021 04:53:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUI1vhjjrOvxUj2pgup7KQGOC8hghXW20IueXf7sSXJ1MEafczisOJN9GZNwC2m7aV0a5Erue+Rr13ScqvYgIoG61vInYQ4pzSefmwDiG1oy73v2WbPQKb5D6Mvh31atdEj16re9nE+a/Rk7MoPl99NYbvL88MmjVb5Ed6jaxytS/btv+QbbJX/S95SamK1QUuL8pyLHzT7AMLILccAcRQB/jiwNSu7Iv7HRr8upTMmKolYXlAljFUcCvAoQTUxPrGc05zYV/o7afRzM2xF1cGwn1G8gFsWV4DhimLyobyFcGCko4HcVCsfowBVikjSBxoVr+HrUtuSsG0WJneJAdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IzeX2TaK+GGNDFAHYjtUdz3NnypBRbSVj3yxiPVhseA=; b=k/306lnoN01yohlGkJYOYnlrY0LMgIhoZOoDnRaYAAjca6LwfnMOkpd0HhiA7IzoNaVXwxfk6z6EBqaOuMGJujuiKOc1EzHIJby4t/zF11oqEPPBVxITbAwOFO0w8Ya4S1THBTCLMNcSvBDCiJZHazNXQdLP7tjgnrzNB1H06GHyuMA5FmuI+VClAnqXEQRw5BiGLWLqfhnyHDojjpqSrTMQG+/75strCO7IxLOY2VFJsQzAwpbNrC343hrO7DKmwzws0rW3L86iAvuADHEpmzE2ThDEcczXzLfAZpYHOuzmJNDqyfbWuECLpFri42uWlyu6w7k8N5sY/gYjBrDjrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
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=IzeX2TaK+GGNDFAHYjtUdz3NnypBRbSVj3yxiPVhseA=; b=YPGVgwvXnVVLoYNPGlZ1iRnmSAqQvptw7GpSQD+YWQl6uvadmt3TsfICn9hlQXHlQ8BEhI6Z2mTvHoJ11/g7hM0fHHyEy0EAU7ulk5Sn/YlhpL7GO5wvq6UiO/aRJcye9SnC/ShYq27FazuUPPM/evsQ22HrloFyD13oj59v68A=
Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8145.eurprd07.prod.outlook.com (2603:10a6:20b:320::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.9; Fri, 9 Jul 2021 11:53:28 +0000
Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 11:53:28 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
CC: "draft-ietf-netconf-notification-capabilities@ietf.org" <draft-ietf-netconf-notification-capabilities@ietf.org>
Thread-Topic: System capabilities versus augmenting-extensions
Thread-Index: AQHXdCokpUdLPi48fU2UKEZ6KwVPL6s6h0zQ
Date: Fri, 09 Jul 2021 11:53:28 +0000
Message-ID: <AM8PR07MB823095861B0B985D13944337F0189@AM8PR07MB8230.eurprd07.prod.outlook.com>
References: <DM4PR11MB54380D220515D83AF8F84DE8B50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <f7606bd3-d38b-3497-3c5d-93490a7c92b1@huawei.com> <5c680eac-0622-b863-22e8-01b9e987f99c@huawei.com> <DM4PR11MB5438A784F9D464DFC5A243F2B51B9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a7d3a2e1f-af85d7a6-9304-4e62-9fcb-785fae37004b-000000@email.amazonses.com> <0100017a7e2cc558-bb17a877-08d6-410d-804e-8b12efb000e5-000000@email.amazonses.com> <0100017a8774e9a2-4bef02f8-3bd4-413d-9c75-f57e23c70a0f-000000@email.amazonses.com>
In-Reply-To: <0100017a8774e9a2-4bef02f8-3bd4-413d-9c75-f57e23c70a0f-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 060b6f54-9a1a-49f9-d8ea-08d942d02aa2
x-ms-traffictypediagnostic: AM8PR07MB8145:
x-microsoft-antispam-prvs: <AM8PR07MB814588AE97C85A721E296637F0189@AM8PR07MB8145.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eqJKLweXQu9ytyp69Cr9+9F26tSsDjl7RLoea+L0fxYStDDbMc4HKVO2TQD+b1iSicW9VAmi6O4rvKE08d/gqnpIVuZMg0JGs4KS6R8XaUCfO+ZWjxS3+0CzrP5//kFJYjFm8VjASurl1pba24BBtL21C8m4I+FK6s92TAD9rlXJW3v5bAeTSyaBJ8g0aKFVSmJ/PhkU8D3fvuV530TD1Zpj/3b1AmrpAOjo7g8BmRdf0UYAkx8YzXqNPc87mj1ZHuj5fY5PGH7MNUj2GgMQHfy5OnWNmFn9ZyGZMGMPJeP7DYxgdm41CTv4KCSDm+aDK1UMHjspYNc2Or8dkEEKfVd5De2UN5xMfeY44Xov/TfoJW/UJTbSlbbPaoNtRUTXeh8TmgfDehgCn2mfzgdQHBcwbhd+xSf1UxF1wYlQ3SEnj98j3bVX/orJM8GKSoXpHve8iWdkO0EHhGmg3CQsEBegpRMgmGMEjuYNxV0aBB1Wwbp4MQk5gZkc5jpdiuz0Vs2FUGgS7etMdmdlMIU2GZ0/Er0vzMbPMES4ZvLepNhcgCNkiSZOv/m5olGmppOyPwBJ+NNmmtV7i/YF9Aufm+P4hyCdZs2Zz+di4oL7y8NcNA5LgcDSXp1RzmTuzXW0phaj8XU7ysL68cH0xOc8Tw95lU7mn5QaMkiyCxL9j5iSfvAufUq4FGg2xU6LqdoDpj22F/pxb/LYL6CPbOk+sQM6NbNqitBBfJtkoMqrp2U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(122000001)(26005)(99936003)(64756008)(55016002)(7696005)(316002)(52536014)(66556008)(33656002)(86362001)(66574015)(71200400001)(85202003)(2906002)(478600001)(38100700002)(83380400001)(5660300002)(76116006)(85182001)(66476007)(9686003)(66616009)(186003)(8676002)(110136005)(66446008)(66946007)(6506007)(53546011)(8936002)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PcDVMDFq3jOc6RfraS0mJev6VU+13xmkXqOovAkWwXMv5PRAVt1krXXmy4e6pwJBHE3LTUI5HNryfXi9kUPTJ0p0hNOWYYlcCiaDeohx7WZbHf5qwVl1hOuGFWXWBCGwHwCNMpqcZLwe+ZQ/SB/j83DPL/+28DqfKNkvopxFzM2OLq6NDQ6fZWJcH0/Foz9nBK1Cb+rS6rz64y68J68+sl8ob96aNrousxqN/10LXHcHc/zP3PdPk3KzCxZYa44XkCQlGlcKp7saxfJIvQ1RHwzyeyWGgd5jc9WgOFks6QeSD/afoQchKP5wT1M27J/DtcQ0TNdZLgcJo71ovI8W3Dq+hwsE7Y57TJExgxKlfpcABkLf3k2W55Yo+nXFjIFIkLj+0TNuWG2B93FvoX5uew7lkXynNEmN6903/cLa2H+u35SVfx+SmG4EhHh+pEh3BwoP9AiSIyi2mPZluP1Tdp75atwSTZqXWwGUXwAeYuw6x03ko6qa+ULDyPX9//3dojrvXxxV4+lfu68TwoZsbiIXGkWiKC02RTAGtZi6gqb+4i8m0EelAPzW0zrQKAqgaFVAcW7bX4SJKGjNsKvrwMz0wOOUPFHMUXmP9jeEW6n8h6wmCIky9Xph5glb95w35eeqrwYUOhoFl68EzxnPrMF84GEpxYOg9OLfocD4+3Dz/w5tmu6uNEZ6bQ9fZAUIHlrmz0SSeYPDM3vnPpdgI7l5VGy8e4stL9VzVFRC0QI/l3bDrehktkTR2N3R3Axi8QowbBlOoVhzXR5kpa4sLtUY19apPo/DkD2HMSCndSP9IyL2GTScy60l8Cgd7khz7/7h4OtzQ/DkCXr4F39BIx+EJRVGq7IcwoZrvVbhnPQFOD1OU0OrKrGPxA+ZQHTQ0OPpSKI5RcSD1oPw3173YBxkKPxrDgBxBTgPRNe87394aO3g+LPaZdbr4uQVZoK580W6d/5ikH2ho5EEtCUiRbf9yXwYpiZoo1Rk02NT3iSqioQhrFZ/SynjVPfBRI+0WvbOTgSYxTUh1suDsXHnMtdrOSeRcnXS/5714Cp6ANhLWyfVkD/dQfiBV8j13LexlVQfQbkIXnuWCIn/DPabKHBTPunH8a7tWTt9T+BOUK0lKx/wKOthzh4C1EHtjyYKisoxEPO2OzIQWv+a0JPZZQ5fV/NimXs6lGVnrq0LtHs5IT8lHco+AuNfIl/rG3eWGLigj2d/fTQgVjJGZgL97auUcas4D17297zA70gjoPdJyNOuSgCpsgXU/rI+L9hoAAKKRjj0uw0P0PmUi9vHv5JpFZPKj1QrbX8uqvDIAmQoRmPR9j8oNCQGZRamcwm3
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_051F_01D774C9.CACB2B40"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 060b6f54-9a1a-49f9-d8ea-08d942d02aa2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 11:53:28.4676 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Qh+aPBS85wcidTUIoMdAgc24biBv/4GpkC1/OrI86PgMMioowdsCKebh/khOEfC0Ie3Ax17qIO77B0XR/Vz6yODPix+MPn5uFzNDuUXV204=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8145
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/243YFZ9wyCsVDtpFI0iYRpKMbjo>
Subject: Re: [netconf] System capabilities versus augmenting-extensions
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2021 11:53:37 -0000

Hello Kent,
I think the capabilities-based approach should be used if the data is a meta-data about the model. It depends on what is foobar?
- foobar is the release-date of the song: this is not meta-data, this is one of the song's properties, so use augment
- foobar is the set of access right needed to download the song, this is more like meta-data: use capabilities. Also, if the same set of access right can be defined on the datastore, system, album, or even individual song level then capabilities are better.

Sometimes what is real-data and what is meta-data is subjective, so I don't know if there is a clear-cut rule.
Regards  Balazs

-----Original Message-----
From: Kent Watsen <kent+ietf@watsen.net> 
Sent: 2021. július 8., csütörtök 20:50
To: netconf@ietf.org
Cc: draft-ietf-netconf-notification-capabilities@ietf.org
Subject: System capabilities versus augmenting-extensions


I’m sure this must’ve been discussed before, but I’m trying to understand the Pros/Cons of decorating a YANG-defined data model using “capabilities” vs “augmenting-in extensions”.

For instance, assuming the “jukebox” module from RFC 8040:

1) Capabilities-based approach

	module example-foo {
	  namespace “http://example.com/ns/example-foo”;
	  prefix foo;
	  import ietf-system-capabilities  {
	    prefix sysc;
	  }
	  augment
	    "/sysc:system-capabilities/sysc:datastore-capabilities”
	    + "/sysc:per-node-capabilities/sysc:node-selection/“
	    + "sysc:node-selector” {
	     leaf foobar {
	       type empty;
	     }
	  }
	}

    Followed with the instance document:

	<system-capabilities
	  xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities”
	  xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores”
	  xmlns:jbox="http://example.com/ns/example-jukebox”
	  xmlns:foo="http://example.com/ns/example-foo”>
	  <datastore-capabilities>
	    <datastore>ds:operational</datastore>
	    <per-node-capabilities>
	      <node-selector>/jbox:jukebox/jbox:playlist/jbox:song</node-selector>
	      <foo:foobar/>
	    </per-node-capabilities>
	  </datastore-capabilities>
	</system-capabilities>


2) Augment-extension based approach

	module foo {
	  namespace “http://example.com/ns/example-foo”;
	  prefix foo;
	  import ietf-system-capabilities  {
	    prefix sysc;
	  }
	  augment "/jbox:jukebox/jbox:playlist/jbox:song” {
	     leaf foobar {
	       type empty;
	     }
	  }
	}



Some differences I see:

1) “augments" are datastore-independent, whereas “capabilities" must be defined for each datastore.  This could be seen as “important” or a “nuisance” depending on perspective.

2) “capabilities” support model-independent (global) values, but an “augmenting” module can also define global values.

3) “capabilities” centralize where such values are located, but consumers need to know what to look for, and so could just as easily look for the “augmenting” modules.

4) “capabilities” are semantically about *capabilities*, whereas augments may regard anything.



When is each approach preferred?  What “best practice” statement can be made, and should it be made in the RFC?  Assuming datastore-independent, SHOULD augments be used, else capabilities SHOULD be used?  


K.