Re: [netconf] Capability-fetching mechanisms

Qin Wu <> Tue, 15 June 2021 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 326BB3A2DE4 for <>; Tue, 15 Jun 2021 05:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ypqHPT9sbdZ6 for <>; Tue, 15 Jun 2021 05:27:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 487593A2DE1 for <>; Tue, 15 Jun 2021 05:27:46 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4G46gy5tqhz6H8XR for <>; Tue, 15 Jun 2021 20:14:38 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Tue, 15 Jun 2021 14:27:42 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 15 Jun 2021 20:27:40 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Tue, 15 Jun 2021 20:27:40 +0800
From: Qin Wu <>
To: Kent Watsen <>, "maqiufang (A)" <>, Zmail <>
CC: "" <>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: Addh4dN4MmAPJjV0Sjy0XXGIk3+1WQ==
Date: Tue, 15 Jun 2021 12:27:40 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7527caa444da49d5bce2608512c668dfhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] Capability-fetching mechanisms
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, 15 Jun 2021 12:27:51 -0000

发件人: Kent Watsen []
发送时间: 2021年6月15日 5:56
收件人: maqiufang (A) <>om>; Qin Wu <>om>; Zmail <>
主题: Re: [netconf] Capability-fetching mechanisms

Hi Qin, Alex, Qiufang,

As I understood in the precedent mails, Qin is looking for a common protocol to exchange these capabilities over all notifications drafts.

[Qin]: See above, as I clarified, I think we can focus on common data model for data export features instead of common protocol,  we will leave protocol extension to each transport specific notif draft, does this make sense?

[Qiufang Ma] There is one more point that I would like to add here, please note that the capability exposure mechanism defined in data-export-capability draft is leveraged by YANG instance file.
 That's to say, the capabilities are documented in a standard-format file which could be accessed by any file access method and protocol.

Maybe it is better to define this capabilities export transport dependent protocol on another draft ? Or on the data-export-capabilities draft, but it is defined as transport agnostic…

[Qin]: Agree. See more clarification above.
Any thoughts ?

Mahesh and I generally agree with the idea of a common response payload format that could be conveyed via draft-specific transports.  We further understand that there is a proposal to use the YANG Instance File Format as the common format.  However, we do not yet fully understand what the response might look like for the “https-notif” draft were it to use the YANG Instance File Format.   Could one of you send an example of what that response might look like matching the contents of the example found in Section 3.4 in the "https-notif” draft?
[Qin Wu] Here is the example:
   The publisher can send the following request to learn the receiver

   GET HTTP 1.1 /some/path/capabilities/acme-receiver-capabilities.json
   Accept: application/xml, application/json

   If the receiver is unable to reply using "application/xml",

the response might look like this:

   HTTP/1.1 200 OK

   Date: Wed, 26 Feb 2020 20:33:30 GMT

   Server: example-server

   Cache-Control: no-cache

   Content-Type: application/json

   Content-Length: nnn


     "ietf-yang-instance-data:instance-data-set": {

       "name": "acme-receiver-capabilities",

       "content-schema": {

         "module": "ietf-data-export-capabilities"


       "timestamp": "2018-01-25T17:00:38Z",

       "description": [

         "Receiver capability"


       "content-data": {

         "system-capabilities": {

           "ietf-data-export-capabilities:data-export-capabilities": [


               "transport-protocol": "http-notif",

               "encoding-format": [







               "transport-protocol": "udp-notif",

               "encoding-format": [