Re: [netconf] Capability-fetching mechanisms

"maqiufang (A)" <maqiufang1@huawei.com> Thu, 10 June 2021 03:57 UTC

Return-Path: <maqiufang1@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468E13A3255; Wed, 9 Jun 2021 20:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJcmyJIYBjuL; Wed, 9 Jun 2021 20:57:10 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF0F3A3254; Wed, 9 Jun 2021 20:57:10 -0700 (PDT)
Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G0qbR66NRz6K69B; Thu, 10 Jun 2021 11:44:19 +0800 (CST)
Received: from dggeml702-chm.china.huawei.com (10.3.17.135) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 10 Jun 2021 05:57:07 +0200
Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeml702-chm.china.huawei.com (10.3.17.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 10 Jun 2021 11:57:05 +0800
Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Thu, 10 Jun 2021 11:57:05 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: Qin Wu <bill.wu@huawei.com>, Zmail <alex.huang-feng@insa-lyon.fr>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
CC: "netconf@ietf.org" <netconf@ietf.org>, Pierre Francois <pierre.francois@insa-lyon.fr>, "weiwang94@foxmail.com" <weiwang94@foxmail.com>
Thread-Topic: [netconf] Capability-fetching mechanisms
Thread-Index: AdddEZ/9CKgMhQir0kaFHGEy5ICHTwAmgMwA
Date: Thu, 10 Jun 2021 03:57:05 +0000
Message-ID: <0ca926471ac04ca3a44c0351d5bb0fe3@huawei.com>
References: <8c4abbe6e738407194d787612c8a2e9d@huawei.com>
In-Reply-To: <8c4abbe6e738407194d787612c8a2e9d@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.93]
Content-Type: multipart/alternative; boundary="_000_0ca926471ac04ca3a44c0351d5bb0fe3huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4F1zJTNGiFX6XIhhzk_rILYU8go>
Subject: Re: [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: Thu, 10 Jun 2021 03:57:15 -0000

Hi, all:

From: Qin Wu
Sent: Wednesday, June 9, 2021 5:38 PM
To: Zmail <alex.huang-feng@insa-lyon.fr>fr>; netconf-chairs@ietf.org
Cc: netconf@ietf.org; maqiufang (A) <maqiufang1@huawei.com>om>; Pierre Francois <pierre.francois@insa-lyon.fr>fr>; weiwang94@foxmail.com
Subject: RE: [netconf] Capability-fetching mechanisms

Thanks Alex for the feedback. Please see my reply inline below.
发件人: Zmail [mailto:alex.huang-feng@insa-lyon.fr]
发送时间: 2021年6月8日 15:21
收件人: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>; netconf-chairs@ietf.org<mailto:netconf-chairs@ietf.org>
抄送: netconf@ietf.org<mailto:netconf@ietf.org>; maqiufang (A) <maqiufang1@huawei.com<mailto:maqiufang1@huawei.com>>; Pierre Francois <pierre.francois@insa-lyon.fr<mailto:pierre.francois@insa-lyon.fr>>; weiwang94@foxmail.com<mailto:weiwang94@foxmail.com>
主题: Re: [netconf] Capability-fetching mechanisms

Hi everyone,

I join this thread to discuss the understanding of the draft data-export-capabilities and how it is confusing with the capabilities export feature of https-notif draft.

I think that the data-export-capabilities draft should change the terms client/server to publisher/receiver.

[Qin]: Agree, I think the client is corresponding to receiver while the server is corresponding to the publisher.

That way, I think it would be clearer in which draft we discuss which case.

As I understood reading this thread, data-export-capabilities discusses how the receiver (client) could get the publisher's (server) capabilities. And on the other side, the HTTPS GET capabilities from https-notif draft defines how the receiver (client) could export its capabilities to the publisher (server). It’s that right ? Please correct me if there is any misunderstanding.

[Qin]: That’s a good distinction. In addition, I am thinking, data-export-capabilities focuses on generic data model or data export features in your words, while https-notif focuses on protocol that is used to carry these data export features.

On the other hand, we are discussing how the receiver could expose its capabilities on each notification drafts (https-notif, udp-notif, etc). Notifications drafts defines a protocol to exchange notifications over a transport layer, so from my point of view, the capabilities export feature should not be defined there because :

1.  it would be transport dependent (I don't feel confortable putting a HTTPS export capabilities on the udp-notif draft...)
[Qin]: That’s a good argument on why we should separate data model or data export features definition from protocol defintions.
2. for configured notifications from the publisher side, there is no need to know the capabilities for the receiver, they already know them
3. I think we are mixing the configuration part and the notification part
[Qin]: Sort of agree, but http notif also add a statement to say
“
   For publishers using Subscription to YANG Notifications [RFC8639<https://datatracker.ietf.org/doc/html/rfc8639>]9>],
   dynamic discovery of a receiver's supported encoding is necessary
   only when the "/subscriptions/subscription/encoding" leaf is not
   configured
”

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 ?

Alex Huang Feng
INSA Lyon | Unyte team

Date: Wed, 2 Jun 2021 01:07:05 +0000
From: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
To: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>, "netconf@ietf.org<mailto:netconf@ietf.org>"
<netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: [netconf] ??:  Capability-fetching mechanisms
Message-ID: <d3e28c3359b34352b42c6f99ce881405@huawei.com<mailto:d3e28c3359b34352b42c6f99ce881405@huawei.com>>
Content-Type: text/plain; charset="utf-8"

Hi, Mahesh:

???: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
????: 2021?6?2? 6:44
???: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
??: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>; netconf@ietf.org<mailto: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><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
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com><mailto:mjethanandani@gmail.com>