Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities

"zhangy666@chinatelecom.cn" <zhangy666@chinatelecom.cn> Tue, 18 August 2020 16:24 UTC

Return-Path: <zhangy666@chinatelecom.cn>
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 62A0E3A0EA4 for <netconf@ietfa.amsl.com>; Tue, 18 Aug 2020 09:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 1FuudwPptOrI for <netconf@ietfa.amsl.com>; Tue, 18 Aug 2020 09:24:00 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 29B453A0EAE for <netconf@ietf.org>; Tue, 18 Aug 2020 09:23:52 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.218:21234.1840317111
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-116.232.12.105?logid-9bdd04c15fdb420a9f4a4f3fe13d6f8e (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 5BB442800A1; Wed, 19 Aug 2020 00:23:43 +0800 (CST)
X-189-SAVE-TO-SEND: 31100443@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id 9bdd04c15fdb420a9f4a4f3fe13d6f8e for netconf@ietf.org; Wed Aug 19 00:23:45 2020
X-Transaction-ID: 9bdd04c15fdb420a9f4a4f3fe13d6f8e
X-filter-score: filter<0>
X-Real-From: zhangy666@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: zhangy666@chinatelecom.cn
Date: Wed, 19 Aug 2020 00:23:45 +0800
From: "zhangy666@chinatelecom.cn" <zhangy666@chinatelecom.cn>
To: "netconf@ietf.org" <netconf@ietf.org>
X-Priority: 3
X-GUID: C2627684-010A-4266-AAAD-C2CE6AB89B84
X-Has-Attach: no
X-Mailer: Foxmail 7.2.16.188[cn]
Mime-Version: 1.0
Message-ID: <20200819002344774581107@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart544808438733_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/2YIob-xOflXy-SeIUbzGhCdhbPE>
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, 18 Aug 2020 16:24:03 -0000

Dear all, 

Regarding the two questions, the comments are as follows:

1. Is the problem important for the NETCONF WG to solve?
I believe that it is important to retrieve different KPI data from various different data source and correlate them together and provide comprehensive view of the network quality or network health from different angles. In addition, it is important to eliminate noise data to be exported to the management plane. Telemetry data tagging and classification is crucial to help capture characteristics data and reduce amount of streamed data to the destination. And I also believe that the NETCONF WG is the appropriate WG for this work. draft-ietf-netconf-notification-capabilities separate notification capability model into system capability model and ietf-notification-capabilities model which serve as a good basis for telemetry data node capabilities definitions.

2. Is the draft a suitable basis for the work?
I have been aware MDT Telemetry tagging Hackathon project in IETF 106 which was demonstrated in both IETF 106 Hakcathon meeting and Hackdemo Happy Hour. I think this draft is mature enough and provide a solid basis for starting point. If this work gets adopted, I will be glad to review any update of this draft and contribute to relate discussion.

I believe it should move forward.

Best regards,


Yuan ZHANG 张园 

China Telecom Research Institute 中国电信研究院
Tel: +86-18918588990
Email: zhangy666@chinatelecom.cn