Re: [netconf] data-export-capabilities: insert hint into the error response

Qin Wu <> Wed, 10 March 2021 02:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 305753A176F for <>; Tue, 9 Mar 2021 18:59:00 -0800 (PST)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 qL4o5XIfeeJH for <>; Tue, 9 Mar 2021 18:58:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BA093A176B for <>; Tue, 9 Mar 2021 18:58:57 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4DwGmD14xmz67w3V for <>; Wed, 10 Mar 2021 10:50:52 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 03:58:54 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Mar 2021 03:58:53 +0100
Received: from ([]) by ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0513.000; Wed, 10 Mar 2021 10:58:47 +0800
From: Qin Wu <>
To: Alexander Clemm <>, "" <>
Thread-Topic: data-export-capabilities: insert hint into the error response
Thread-Index: AdcVVo6M1s/th9K1TDGJylbruWtopQ==
Date: Wed, 10 Mar 2021 02:58:47 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] data-export-capabilities: insert hint into the error response
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: Wed, 10 Mar 2021 02:59:00 -0000

Hi, Alex:
发件人: netconf [] 代表 Alexander Clemm
发送时间: 2021年3月10日 7:39
主题: Re: [netconf] data-export-capabilities: insert hint into the error response

Hi Qin, and authors,

On this particular issue: presumably, when there is something about the subscription that the server does not support, they would simply return an error response with identity establish-subscription-error as base. Now it is true that a client would need to send a subsequent request.  However, I am not sure how big an issue this is, as you would presumably not need to do this repeatedly upon each establishment of a new subscription, only upon the first time.   Of course, it is true that convergence might still need a couple of cycles depending on the number of options there are.  

[Qin]:Good point, I am proposing to replace one or another, or blame the protocol breaks. I think new mechanism proposed in this draft is complementary to existing solution in RFC8639.

Regardless of this, I do think there is a strong conceptual argument to be made that it still makes sense for all capabilities to be discoverable.  This makes solutions a bit more "elegant" and allows them to be fully data-driven.  There may be also collateral benefits such as the return of successive errors causing to risk of confusion legitimate subscription requests e.g. with someone trying to launch bogus invalid requests.  


So, I do think the data model defined in this draft will be clearly useful and a straightforward thing to support regardless of the other argument.   Perhaps one thing to do as well would be to review whether there are any new establish-subscription-errors needed beyond the ones already defined and if so, also define those as part of this draft.

[Qin]:Good suggestion,  we can add new child identities derived from establish-subscription-errors base identity.

--- Alex

-----Original Message-----
From: netconf <> On Behalf Of Qin Wu
Sent: Monday, March 8, 2021 7:43 PM
Subject: [netconf] data-export-capabilities: insert hint into the error response

One of open issues we discuss in the netconf session is related to necessity of data export capability in the draft-tao-netconf-data-export-capabilities
Is there any alternative way?
One of alternative way we investigate is one proposed in RFC8639, i.e., insert hint into the error response
Pro: Accept the failure the first RPC request attempt, but increases the likelihood of success for subsequent RPC requests
Con: Such likelihood of success for subsequent RPC requests is not guaranteed since hint needs to be specified every time we have new hint, otherwise the client who initiate the RPC request may not understand what hint means.

With data export capability advertisement,
Pro: increase likelihood of success for the first RPC request, doesn’t need to wait for the second round RPC exchange The cost is to introduce new parameter in the notification capability message in the draft-ietf-netconf-notification-capabilities-14.
Given the notification capability has been well accepted and stable for publication, I think it layer foundation for new capability definitions.

-Qin (on behalf of authors)
发件人: netconf [] 代表 maqiufang (A)
发送时间: 2021年1月20日 21:01
主题: [netconf] New Version Notification for draft-tao-netconf-data-export-capabilities-03.txt

Hi, all:
 We have updated the draft,;;sdata=BfJi5fpibbXklJxiR42qAiUBfk7FHiBsXtMiBf47q1U%3D&amp;reserved=0  .
The main changes are following :
   o  Change 'data-export-capabilities' into list type to support
      multiple transport protocol, encoding on the server.
   o  Add Usage Example of interaction with UDP based Transport for
      Configured Subscription.
   o  Add Thomas Graf as a contributor;
   o  Update motivation in the introduction to clarify why this work is
   o  Support udp notif and http notif as two optional transport in the
      YANG data model.

Any suggestions and comments would be greatly appreciated!

Qiufang Ma(On behalf of authors)

-----Original Message-----
From: []
Sent: Wednesday, January 20, 2021 8:46 PM
To: Peng Liu <>; Qin Wu <>; Qin Wu <>; maqiufang (A) <>
Subject: New Version Notification for draft-tao-netconf-data-export-capabilities-03.txt

A new version of I-D, draft-tao-netconf-data-export-capabilities-03.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:		draft-tao-netconf-data-export-capabilities
Revision:	03
Title:		Telemetry Data Export capability
Document date:	2021-01-20
Group:		Individual Submission
Pages:		18
URL:  ;;sdata=BfJi5fpibbXklJxiR42qAiUBfk7FHiBsXtMiBf47q1U%3D&amp;reserved=0
Diff: ;;sdata=pp%2Bh675Ut6RtrTapFM5U2GWSch6vkRQ5kM%2BY8BuSuj0%3D&amp;reserved=0

   This document proposes a YANG module for telemetry data export
   capabilities which augments system Capabilities model and provides
   additional telemetry data export attributes associated with system
   capabilities for transport dependent capability advertisement.


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

The IETF Secretariat

netconf mailing list;;sdata=0FeLv9PmDdz8HKRh%2F%2Bvmqof%2B6U9To3amxFBMn85yIBc%3D&amp;reserved=0
netconf mailing list;;sdata=0FeLv9PmDdz8HKRh%2F%2Bvmqof%2B6U9To3amxFBMn85yIBc%3D&amp;reserved=0
netconf mailing list