Re: [netconf] Capability-fetching mechanisms

Kent Watsen <kent+ietf@watsen.net> Mon, 14 June 2021 21:56 UTC

Return-Path: <0100017a0c8674c2-3979d21e-8e8a-4c39-a2ae-e3f110eecc5f-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 E70A13A0E93 for <netconf@ietfa.amsl.com>; Mon, 14 Jun 2021 14:56:19 -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_MSPIKE_H3=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 PTqNaP8FI6xO for <netconf@ietfa.amsl.com>; Mon, 14 Jun 2021 14:56: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 E3CEF3A0E88 for <netconf@ietf.org>; Mon, 14 Jun 2021 14:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1623707776; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BBW44QPFbr/7YoEUymF/QpLxN5s6fnt02VXa7H2nAfs=; b=PPuUZCL0oQOVgg9vxNz+FSoNqsQlgwCMnajnbBR0Y64hWieyo2r2grJ4WSTIZGgo 3bxllNYHt9txu+pA2fwUjO1rHz/0Jq07TmEc7Xy2/nI3JgTI6IG8s1jP59fBbLdM0cD PU2LfJ1rP4ex1gW+iPyDFXtGkffSOAZ9vRsFnZdI=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100017a0c8674c2-3979d21e-8e8a-4c39-a2ae-e3f110eecc5f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CD7F590-5BFA-4BFC-A7ED-4C7DA0AF4BB3"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 14 Jun 2021 21:56:16 +0000
In-Reply-To: <0ca926471ac04ca3a44c0351d5bb0fe3@huawei.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "maqiufang (A)" <maqiufang1@huawei.com>, Qin Wu <bill.wu@huawei.com>, Zmail <alex.huang-feng@insa-lyon.fr>
References: <8c4abbe6e738407194d787612c8a2e9d@huawei.com> <0ca926471ac04ca3a44c0351d5bb0fe3@huawei.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.06.14-54.240.8.33
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Zl3sD78f-6DNOjeE81ZRnD_DXeM>
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, 14 Jun 2021 21:56:20 -0000

Hi Qin, Alex, Qiufang,


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


Mahesh and I generally agree with the idea of a common response payload format that could be conveyed via draft-specific transports.  We further understand that there is a proposal to use the YANG Instance File Format as the common format.  However, we do not yet fully understand what the response might look like for the “https-notif” draft were it to use the YANG Instance File Format.   Could one of you send an example of what that response might look like matching the contents of the example found in Section 3.4 in the "https-notif” draft?

Kent and Mahesh