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

Qin Wu <> Tue, 11 August 2020 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D23AD3A0ECF for <>; Mon, 10 Aug 2020 19:09:15 -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 JCVcaJ7MBIvx for <>; Mon, 10 Aug 2020 19:09:14 -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 DEA483A0EC2 for <>; Mon, 10 Aug 2020 19:09:13 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 71E8D401E26BDA7AFF70 for <>; Tue, 11 Aug 2020 03:09:11 +0100 (IST)
Received: from ( by ( 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:09:11 +0100
Received: from ( by ( 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:09:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:09:06 +0800
From: Qin Wu <>
To: Andy Bierman <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities
Thread-Index: AdZveVGk4XmdPOMeTNuJrLeH7HLIGQ==
Date: Tue, 11 Aug 2020 02:09:06 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC16dggeml511mbschi_"
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 02:09:16 -0000

发件人: netconf [] 代表 Andy Bierman
发送时间: 2020年8月11日 3:39
收件人: Kent Watsen <>
主题: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities


I am trying to understand the problem this draft is attempting to solve.
The premise seems to be that the error handling and "hints" mechanism
in RFC 8639 and RFC 8641 do not work
[Qin]: The data export capabilities is not designed to replace error handling and is positioned as capability negotiation and used before netconf connection to be setup,  they are complementary,
error handling will be the last resort
When dynamic subscription request is declined or rejected. Error handling is only applicable to dynamic subscription
based on section 3.2 of RFC8641.

Our argument is why not prevent the problem to happen in the first place instead of waiting for the server making mistake and remedy it.
One of principle set by RFC8641 is:
minimize the number of subscription iterations between subscriber and publisher, discourage Random guessing of different parameters by a subscriber.

The solution being provided is generic, targeted to address this challenge, not only applicable to dynamic subscription, but also configured subscription.

and the client needs to retrieve
extensive monitoring info to determine how to setup notifications on the server.

In theory this data could be used to prevent an <rpc-error> to be returned
for <establish_subscription> or <edit-config>

IMO the current approach is much better than this proposed approach.
The server can provide the hints based on the exact request from the client.
[Qin]: It may be late, still require multiple subscription iterations between subscriber and publisher. But data export has no intention to replace it. Error handling have its value in many different cases.
The static "per-node" monitoring data can be quite large, and yet not provide
the correct answer for a specific combination of subscription parameters..

[Qin]: It is server capability exposure, check early implantation time information of the capability what the server support (e.g., GRPC transport, TCP support, UDP transport support),
not targeted to keep track of dynamic change data.
These capabilities seldom change. In addition, to allow the client compose various different subscription policy (e.g., adaptive subscription), we require the server to indicate whether specific data object supports
Thresholds handling.
This is missing pieces to support event based telemetry solution.


On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen <<>> wrote:


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.

netconf mailing list<>