Re: [netconf] Capability-fetching mechanisms

"maqiufang (A)" <> Tue, 18 May 2021 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC5663A130D for <>; Tue, 18 May 2021 06:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 up2BazA-Cees for <>; Tue, 18 May 2021 06:53:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 784FD3A1318 for <>; Tue, 18 May 2021 06:53:42 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Fky421gxNz6W0cY for <>; Tue, 18 May 2021 21:47:30 +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, 18 May 2021 15:53:37 +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, 18 May 2021 21:53:35 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Tue, 18 May 2021 21:53:35 +0800
From: "maqiufang (A)" <>
To: Kent Watsen <>
CC: Wei Wang <>, Qin Wu <>, "" <>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: AddG0HdnSNhQPyUmB0iwqeRmQPitBf//uS2A//9kl9CACYs2gP/+ctag
Date: Tue, 18 May 2021 13:53:35 +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_257b1be7eb5044ae9654c0104f31bf6dhuaweicom_"
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, 18 May 2021 13:53:50 -0000

Hi, Kent,
Please see my reply inline.

From: Kent Watsen []
Sent: Tuesday, May 18, 2021 6:00 AM
To: maqiufang (A) <>
Cc: Wei Wang <>; Qin Wu <>;
Subject: Re: [netconf] Capability-fetching mechanisms

Hi Qiufang Ma,

Since data-export-capability draft defines a mechanism to discover a set of capabilities supported by the NETCONF/RESTCONF server(the network device, actually).
But in the http-notif draft, what we need to discover is the receiver's capabilities, rather than the device’s.
So I think the reason Kent said that the receiver must also be a NETCONF and/or RESTCONF server is that only in this case can the data-export-capability draft be used as capability discovery on the http-receiver side.
Please correct me if there exists any misunderstanding.-:)

I think that your understanding of the https-notif draft is correct.
[Qiufang Ma] Thanks.

From my perspective, The data-export-capability does not have to require the receiver to function as a NETCONF/RESTCONF server. The capability discovery mechanism in these two drafts can complement each other in this case. In other cases, data-export-capability provides the receiver with an overall  acquisition of the transport capabilities about the device.

I’m unclear on each of your sentences above.  Could you, for for sentence, provide more context regarding what you mean?  For instance, how could the data-export-capability draft not imply the receiver be a NC/RC server?  Likewise, how could the two drafts compliment each other?  Also, by mentioning “other cases”, but what is the ”first” case that this contrasts to?
[Qiufang Ma] Sorry for being unclear.
On the one hand, data-export-capability draft  focuses more on discovering a set of capabilities supported by the publisher, and the publisher can learn the capabilities of the receiver through the mechanism defined in http-notif draft. Therefore the capability discovery mechanisms of these two drafts complement each other to realize the capability discovery of both receiver and publisher.
On the other hand, as Qin has clarified, maybe we can define a shared mechanism to fetch the receiver capability in the data-export-capability draft that does not need the receiver to be a NC/RC server.
So I do not think it would be necessary for the receiver to be a NC/RC server.

Other cases refer to cases other than capability discovery at the receiver side. For example, the receiver learns capability supported by the publisher(e.g., encoding format), which helps (e.g., in the selection of the encoding format) when establishing a dynamic subscription.