[netconf] 答复: Capability-fetching mechanisms

Qin Wu <bill.wu@huawei.com> Wed, 02 June 2021 01:07 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CF8333A2E42 for <netconf@ietfa.amsl.com>; Tue, 1 Jun 2021 18:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6U9TltNxvp0P for <netconf@ietfa.amsl.com>; Tue, 1 Jun 2021 18:07:09 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FA43A2E1B for <netconf@ietf.org>; Tue, 1 Jun 2021 18:07:09 -0700 (PDT)
Received: from fraeml735-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FvrCS64Crz6K5VQ; Wed, 2 Jun 2021 08:54:44 +0800 (CST)
Received: from dggeml703-chm.china.huawei.com ( by fraeml735-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 2 Jun 2021 03:07:07 +0200
Received: from dggeml753-chm.china.huawei.com ( by dggeml703-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 2 Jun 2021 09:07:05 +0800
Received: from dggeml753-chm.china.huawei.com ([]) by dggeml753-chm.china.huawei.com ([]) with mapi id 15.01.2176.012; Wed, 2 Jun 2021 09:07:05 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: AddL2HWsR2fQuKr/T2WNMl8IjZzG7ALHAwYAABUslUA=
Date: Wed, 02 Jun 2021 01:07:05 +0000
Message-ID: <d3e28c3359b34352b42c6f99ce881405@huawei.com>
References: <a8eaedd45bb94109ae4ab48c4c4ec872@huawei.com> <3F555FC1-F19E-4BAB-A23A-AA70A935BFBB@gmail.com>
In-Reply-To: <3F555FC1-F19E-4BAB-A23A-AA70A935BFBB@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d3e28c3359b34352b42c6f99ce881405huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8lV83WaqWCw9lVrc4U0GQfQfTGc>
Subject: [netconf] 答复: Capability-fetching mechanisms
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 01:07:15 -0000

Hi, Mahesh:

发件人: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
发送时间: 2021年6月2日 6:44
收件人: Qin Wu <bill.wu@huawei.com>
抄送: Kent Watsen <kent+ietf@watsen.net>; netconf@ietf.org
主题: Re: [netconf] Capability-fetching mechanisms

[Trimming down the e-mail to open topics]

Hi Qin,

See inline with [mj1]

On May 18, 2021, at 4:40 AM, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:

Hi, Mahesh:

The question is whether the receiver needs to be a NETCONF/RESTCONF server. As maqiufang wrote in his response, if the receiver supports the data-export-capabilities draft, then it would need to be a NETCONF/RESTCONF server, whereas with the https-notif draft that is not the case. This is the case whether the receiver supports RFC 8639 or not.
[Qin]:My understanding is data-export-capabilities doesn’t require receiver to be tied with NETCONF/RESTCONF server. I assume the management system (i.e., receiver) and network device (i.e., publisher) can use HTTPS to exchange advertised data.

In addition, Maybe what is missing in the data-export-capabilities draft is to define RPC to allow the publisher get capability from receiver through HTTPS channel, similar to what is get-bootstrapping-data RPC defined in RFC8572.

[mj1] Stipulating a HTTPs channel works for the HTTPS notif draft. But what will other transport type drafts use? e.g. the UDP notif draft??

[Qin]:I think UDP notif draft could also use HTTPs channel to carry capability information from the server to the client in the form of YANG instance file format.

Please note that RFC 8639 receivers do not have to be NETCONF/RESTCONF servers for configured subscriptions. RFC 8639, Section 2.7 defines the control messages such as <subscription-started> using one-way YANG “notification” statements.

[Qin]: Understand this case, Do you think we should define a new notification in the data-export-capabilities draft instead of considering to define RPC?

[mj1] I do not understand this statement. Can you expand?

[Qin]: I am not sure the RPC is a good design choice, I think we could have 3 options
(a)Report capability information from the HTTPs server or the HTTPs client at run-time or implementation- time, per the YANG Instance Data File Format.
(b) Define one way YANG notification similar to <subscription-started> that is sent from the server to the client
(c) Report capability information only from NETCONF server using YANG model define in data-export-capaiblities draft
I think (b) only allow the server advertise the server capability to the client but does not allow the client issue notification and advertise client capability to the server
(c) is something you envision how it is used, the limitation is to require NETCONF server to be supported by the receiver or the client, but this option is not what we proposed in the data-export-capabilities draft.
The solution we proposed is (a) which allows report capability information either from the Server or the client using YANG Instance data file. Hope this clarifies.

Mahesh Jethanandani