Re: [netconf] Capability-fetching mechanisms

Kent Watsen <kent+ietf@watsen.net> Tue, 01 June 2021 23:10 UTC

Return-Path: <01000179c9d75c90-d8a3b4c8-0339-4a53-a719-9c7366b16455-000000@amazonses.watsen.net>
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 480483A2AFC for <netconf@ietfa.amsl.com>; Tue, 1 Jun 2021 16:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 R9rJfzS7ZUbH for <netconf@ietfa.amsl.com>; Tue, 1 Jun 2021 16:10:06 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9E13A2AFB for <netconf@ietf.org>; Tue, 1 Jun 2021 16:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1622589005; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mll62Bwntj5j3hirayeFTMDEyCXy9eJYim2m6ETFLM8=; b=UjumhILV0TQ1ckp2EMvfuo3IhvY4jdYEcGKxyc1x1MMSQE+JApuw7WRhHigZ15ga FbOYR5no0JE3lQub75iDMaN1V/k8IlV+Bo2Vo+HLIjQtHHQHVkHfrfSIajR1e4O5RX2 h+9DK2q2sSwh848/rGwvxFAogZXJ+SZ6M74P3MUk=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000179c9d75c90-d8a3b4c8-0339-4a53-a719-9c7366b16455-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2DA8EFA-52A8-4F79-8A9E-B76252C9B086"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 01 Jun 2021 23:10:05 +0000
In-Reply-To: <257b1be7eb5044ae9654c0104f31bf6d@huawei.com>
Cc: Wei Wang <weiwang94@foxmail.com>, Qin Wu <bill.wu@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
To: "maqiufang (A)" <maqiufang1@huawei.com>
References: <fe4d6fca7cc34ffc8611bf0c94352b33@huawei.com> <tencent_1EAAB36DA33D542F6FEE723E8ECD21533405@qq.com> <3a058efa22df47239b8d016c6ba9e431@huawei.com> <010001797c58025b-fb6d6a97-d7bc-4161-90f6-a0fad771f6ee-000000@email.amazonses.com> <257b1be7eb5044ae9654c0104f31bf6d@huawei.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.06.01-54.240.8.31
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/uCKFTWJ3bsH-HW7lJu3-1cW0DAQ>
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: Tue, 01 Jun 2021 23:10:11 -0000

Hi Qiufang Ma,


> Hi, Kent,
> Please see my reply inline.
>  
> 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.

Now I understand what was meant before - thanks.

To be honest, I didn’t realize that "data-export-capability” was primarily for clients to retrieve server-capabilities.  Of course, its obvious now, but somehow I thought it was defining a different way for a server to get client capabilities.


> 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.

Maybe, but the desire to do so is now less in my mind given the above “revelation” to me.  That said,  let’s see how this matter plays out in the thread between Qin and Mahesh...


> 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.

Noted.


K.