[netconf] Generic Capabilities model

Qin Wu <bill.wu@huawei.com> Thu, 05 December 2019 03:56 UTC

Return-Path: <bill.wu@huawei.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 7DEE912091E for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2019 19:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 fbR0oWXx2Vv0 for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2019 19:56:36 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 88B2412001A for <netconf@ietf.org>; Wed, 4 Dec 2019 19:56:36 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 025A5135CBA46961B0F0; Thu, 5 Dec 2019 03:56:31 +0000 (GMT)
Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 5 Dec 2019 03:56:30 +0000
Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 5 Dec 2019 03:56:30 +0000
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 5 Dec 2019 03:56:30 +0000
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.151]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Thu, 5 Dec 2019 11:56:27 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Generic Capabilities model
Thread-Index: AdWrHi7eIq0bEJsrSBqCRqY5LAgWxA==
Date: Thu, 05 Dec 2019 03:56:27 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA94AFE56@dggeml511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA94AFE56dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/YU9Tpu0qVGRweqZbbAVGdWHGVMw>
Subject: [netconf] Generic Capabilities model
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: Thu, 05 Dec 2019 03:56:39 -0000

Hi, Balazs:
In last IETF meeting, you offered a proposal in netmod session on notification capability change that was discussed in netmod session.
I think it is a good idea to define generic capabilities model in draft-ietf-netconf-notification-capabilities
https://datatracker.ietf.org/meeting/106/materials/slides-106-netmod-sessb-generic-model-for-server-capabilities-00
since we have other capabilities that need to be covered, one of example such capability is one that can be self-described in
draft-tao-netmod-yang-node-tags<https://tools.ietf.org/id/draft-tao-netmod-yang-node-tags-00.txt>.
With such new capability, should we augment from YANG Push model or should we augment from notification capability?
We see one downside of augmenting from YANG Push model, is it only can be used in the running time, it can not be used in the design time or
Implementation time.

So I think if one generic capability model can be defined, it will allow more flexibility to add new capability. However if we decide to take this approach,
Probably notification capabilities draft require substantial changes to the current model structure. But I think it worth to do so, in my personal view.

-Qin