Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

"Wubo (lana)" <> Tue, 11 August 2020 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46FCE3A0FA8 for <>; Tue, 11 Aug 2020 04:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MOF50S9Lt0G0 for <>; Tue, 11 Aug 2020 04:10:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDBA73A0FA7 for <>; Tue, 11 Aug 2020 04:10:28 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 36A79DE209F5BF7E338D for <>; Tue, 11 Aug 2020 12:10:24 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 12:10:23 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 11 Aug 2020 19:10:21 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Tue, 11 Aug 2020 19:10:21 +0800
From: "Wubo (lana)" <>
To: Kent Watsen <>, "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities
Thread-Index: AdZvtJ0vWgensLp3RCq6eyZ+MPcrHA==
Date: Tue, 11 Aug 2020 11:10:21 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_19459f2761bd4571a3ebe8e35c567e29huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Aug 2020 11:10:31 -0000

Hi all,

1) is the problem important for the NETCONF WG to solve?

Yes, I think the extended per-node notification capability in this draft, including timer-based-trigger and threshold-based trigger,
could complement RFC8641 existing generic trigger mechanism.
And I believe that the NETCONF WG is the appropriate WG for this work, since these capability extends from notification capability model
defined in draft-ietf-netconf-notification-capabilities, which provides a good basis for server capabilities advertisement.

2) is the draft a suitable basis for the work?

I have reviewed the draft and it provides a good basis. If this work gets adopted, I am happy to review any version of this work
and contribute to any discussion and help move this work forward.

Best regards,

发件人: netconf [] 代表 Kent Watsen
发送时间: 2020年8月6日 6:18
主题: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities


Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Telemetry Data Export capability
      This document proposes a YANG module for telemetry data export
      capability which augments system Capabilities model and provides
      additional telemetry data export attributes associated with system
      capability for transport dependent capability negotiation.

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.