Subject: Re: [netconf] Capability-fetching mechanisms

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jun 2021 12:27:40 +0000

发件人: Kent Watsen [mailto:[email-masked]]
发送时间: 2021年6月15日 5:56
收件人: maqiufang (A) <[email-masked]>; Qin Wu <[email-masked]>; Zmail <[email-masked]>
抄送: [email-masked]
主题: Re: [netconf] Capability-fetching mechanisms

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?
[Qin Wu] Here is the example:
   The publisher can send the following request to learn the receiver
   capabilities.

   GET HTTP 1.1 /some/path/capabilities/acme-receiver-capabilities.json
   Host: example.com
   Accept: application/xml, application/json

   If the receiver is unable to reply using "application/xml",

the response might look like this:

   HTTP/1.1 200 OK

   Date: Wed, 26 Feb 2020 20:33:30 GMT

   Server: example-server

   Cache-Control: no-cache

   Content-Type: application/json

   Content-Length: nnn

   {

     "ietf-yang-instance-data:instance-data-set": {

       "name": "acme-receiver-capabilities",

       "content-schema": {

         "module": "ietf-data-export-capabilities"

       },

       "timestamp": "2018-01-25T17:00:38Z",

       "description": [

         "Receiver capability"

       ],

       "content-data": {

         "system-capabilities": {

           "ietf-data-export-capabilities:data-export-capabilities": [

             {

               "transport-protocol": "http-notif",

               "encoding-format": [

                 "json",

                 "xml",

                 "rfc8639-enabled"

               ]

             },

             {

               "transport-protocol": "udp-notif",

               "encoding-format": [

                 "binary"

               ]

             }

           ]

         }

       }

     }

}

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 28 Jun 2021 15:41:18 -0700

Hi Qin,

Thank you for sharing an example. We now understand better what was intended. After discussing some, three things come to mind.

1) We do not have a particular requirement for an off-line format, and find it an unnecessary overhead of having to wrap the data with yang-instance-data.

2) There seems to be an implication of the receiver being a NETCONF server, something that we made an effort to avoid in the first place. 

3) The data export capabilities other leafs that we do not care about. How do we restrict the response to data that is pertinent to our transport draft? In the example you shared, we see capabilities for udp-notif being returned in addition to http-notif.

For these reasons, we feel the that the value proposition is limited, while increasing complexity.

Mahesh & Kent

> On Jun 15, 2021, at 5:27 AM, Qin Wu <[email-masked]> wrote:
> 
>    Host: example.com <http://example.com/>