Re: [netconf] Capability-fetching mechanisms

Kent Watsen <kent+ietf@watsen.net> Mon, 17 May 2021 22:00 UTC

Return-Path: <010001797c58025b-fb6d6a97-d7bc-4161-90f6-a0fad771f6ee-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 39C793A4591 for <netconf@ietfa.amsl.com>; Mon, 17 May 2021 15:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_H2=-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 LTyTAGKjBPN7 for <netconf@ietfa.amsl.com>; Mon, 17 May 2021 15:00:18 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B775C3A46A5 for <netconf@ietf.org>; Mon, 17 May 2021 15:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1621288813; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=a/4HB0IApoLJgx31NOcMxklRamLmvLl0JGm+aATXfxY=; b=NmpMJWbevOI8cfz4ssu6oKX54nYO5dOC2NrnF5L8Zi8BTJsJefV/fasFWc5OagWx gsRUUuzwXl9A9WvHRGijom2sX8fLRwEYwwSic2kj2tYfyWhJScXJ+41XYxSsZdaX7ri DOXKqikZqujiDzpHdIAIl4I7PSgUCR+diMJjnCXg=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001797c58025b-fb6d6a97-d7bc-4161-90f6-a0fad771f6ee-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_54A79F4D-EDF2-4A04-953A-1E14EFBD5CCE"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 17 May 2021 22:00:13 +0000
In-Reply-To: <3a058efa22df47239b8d016c6ba9e431@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>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.05.17-54.240.8.33
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/kBKgmnxusTuhTBhUlfK1KTaAIDE>
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: Mon, 17 May 2021 22:00:20 -0000

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.


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

Thanks

K.