Re: [netconf] Capability-fetching mechanisms

"maqiufang (A)" <> Thu, 01 July 2021 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59BBE3A0883 for <>; Thu, 1 Jul 2021 06:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 mYaVukpOBF-w for <>; Thu, 1 Jul 2021 06:42:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD8A53A098C for <>; Thu, 1 Jul 2021 06:41:48 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4GFzh12QLpz6G8Lv; Thu, 1 Jul 2021 21:33:53 +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; Thu, 1 Jul 2021 15:41:41 +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; Thu, 1 Jul 2021 21:41:40 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Thu, 1 Jul 2021 21:41:39 +0800
From: "maqiufang (A)" <>
To: Mahesh Jethanandani <>, Qin Wu <>
CC: Kent Watsen <>, Zmail <>, "" <>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: Addh4dN4CKgMhQir0kaFHGEy5ICHTwKSdQAAAJLpKcA=
Date: Thu, 01 Jul 2021 13:41:39 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_63f192192a3f4750ac9e6dddeb8145e5huaweicom_"
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: Thu, 01 Jul 2021 13:42:07 -0000

Hi, Mahesh:
    Please see my reply inline.
From: Mahesh Jethanandani []
Sent: Tuesday, June 29, 2021 6:41 AM
To: Qin Wu <>
Cc: Kent Watsen <>; maqiufang (A) <>; Zmail <>;
Subject: Re: [netconf] Capability-fetching mechanisms

Hi Qin,

Thank you for sharing an example. We now understand better what was intended. After discussing some, three things come to mind.

1)      We do not have a particular requirement for an off-line format, and find it an unnecessary overhead of having to wrap the data with yang-instance-data.
[Qiufang Ma] We understand that http-notif has no requirement for an off-line format, but why reject an extra mechanism to get the receiver capabilities without a need for a live receiver side?
YANG-instance-file is made up of a header part and content-data. The header part carries metadata most of which are optional, and the content data carries our necessary capabilities.

2)      There seems to be an implication of the receiver being a NETCONF server, something that we made an effort to avoid in the first place.
[Qiufang Ma] The capabilities of the receiver side can be documented in offline yang-instance-file so that the publisher can access the files in any accessible way. There is no additional requirement that the receiver side be the NETCONF or RESTCONF server. We do not even require that the receiver side be the HTTP server. Hopefully this clarifies.

3)      The data export capabilities other leafs that we do not care about. How do we restrict the response to data that is pertinent to our transport draft? In the example you shared, we see capabilities for udp-notif being returned in addition to http-notif.
[Qiufang Ma] Our mechanism is to discover the full capabilities of the publisher/receiver side, not just http-notif-related. I understand that http-notif does not care about other transport capabilities, I think udp-notif is the same. Repeated capability queries for each individual transport protocol seem inflexible and incur unnecessary overhead.

Best Regards,
Qiufang Ma

For these reasons, we feel the that the value proposition is limited, while increasing complexity.

Mahesh & Kent

On Jun 15, 2021, at 5:27 AM, Qin Wu <<>> wrote:

[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": [