Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities
Qin Wu <bill.wu@huawei.com> Tue, 11 August 2020 02:10 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 0325F3A0EDF for <netconf@ietfa.amsl.com>; Mon, 10 Aug 2020 19:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xCbpo-KUNN8c for <netconf@ietfa.amsl.com>; Mon, 10 Aug 2020 19:10:47 -0700 (PDT)
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 ECDD43A0EE2 for <netconf@ietf.org>; Mon, 10 Aug 2020 19:10:46 -0700 (PDT)
Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 85DFF4C283F0D1E09775 for <netconf@ietf.org>; Tue, 11 Aug 2020 03:10:45 +0100 (IST)
Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:10:45 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:10:44 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:10:39 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities
Thread-Index: AdZvgKDDrRFiNBN5S662w/6KCddT4w==
Date: Tue, 11 Aug 2020 02:10:38 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD8FAC2E@dggeml511-mbs.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.164.151.108]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/aDkHSwRkP5hCieWKE2FhS_i6ZTE>
Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities
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: Tue, 11 Aug 2020 02:10:49 -0000
发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Andy Bierman 发送时间: 2020年8月11日 3:39 收件人: Kent Watsen <kent+ietf@watsen.net> 抄送: netconf@ietf.org 主题: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities Hi, I am trying to understand the problem statement in this draft. It seems to be a way to assign various tags to data node objects. It uses the tags type from ietf-module-tags, which implies that modules and nodes share the same set of tags. [Qin]: It is not the goal to share the same set of tags for module and nodes, nodes could Have their own tags and used to tag management and operation data or telemetry data defined within the module , it is data node level tag, not module level tag. If this will be the issue, we can define tag separately. There is also an assumption that the error/hints mechanism in RFC 8639 and 8641 do not work and this significant amount of proposed metadata could be used to avoid receiving an <rpc-error> for an <establish-subscription> or <edit-config> request. [Qin]: See clarification for data export capability draft, it is designed as server capability exposure, not targeted to replace error handling for <establish-subscription> and <edit-config>. They are used at different phase. The big different with Data export capability, is it doesn’t tell the client how to select transport protocol, encoding, security scheme, etc, it tells the client Which data object is characteristics data or KPI data, which help avoid fetch noise data from the data source and provide comprehensive view of the network quality or network health from different angles. IMO the current approach is sufficient and new mechanisms are not needed. Andy On Wed, Aug 5, 2020 at 3:18 PM Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote: NETCONF WG, Per the previous email sent moments ago, the chairs would like to solicit input on the following draft: Title: Self-explanation data Node tag capability Link: https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities Abstract: Before a client application subscribes to updates from a datastore, server capabilities related to "Subscription to YANG Datastores" can be advertised using YANG Instance Data format. These server capabilities can be documented at implement time or reported at run- time. This document proposes a YANG module for self-explanation data Node tag capability which augments system capabilities model and provide additional self-explanation data node attributes associated with node selectors within per-node capabilities. In particular, please discuss adoption-suitability as it regards to the following questions: 1) is the problem important for the NETCONF WG to solve? 2) is the draft a suitable basis for the work? PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll. NETCONF Chairs _______________________________________________ netconf mailing list netconf@ietf.org<mailto:netconf@ietf.org> https://www.ietf.org/mailman/listinfo/netconf
- [netconf] Adoption-suitability for draft-tao-netc… Kent Watsen
- Re: [netconf] Adoption-suitability for draft-tao-… duzongpeng@foxmail.com
- Re: [netconf] Adoption-suitability for draft-tao-… Andy Bierman
- Re: [netconf] Adoption-suitability for draft-tao-… Qin Wu
- Re: [netconf] Adoption-suitability for draft-tao-… 王巍
- Re: [netconf] Adoption-suitability for draft-tao-… zhangy666@chinatelecom.cn