Re: [netconf] Capability-fetching mechanisms

["maqiufang (A)" <[e-mail]>]

Hi, Mahesh:
    Please see my reply inline.
From: Mahesh Jethanandani [mailto:[e-mail]]
Sent: Tuesday, June 29, 2021 6:41 AM
To: Qin Wu <[e-mail]>
Cc: Kent Watsen <[e-mail]>; maqiufang (A) <[e-mail]>; Zmail <[e-mail]>; [e-mail]
Subject: Re: [netconf] Capability-fetching mechanisms

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.
[Qiufang Ma] We understand that http-notif has no requirement for an off-line format, but why reject an extra mechanism to get the receiver capabilities without a need for a live receiver side?
YANG-instance-file is made up of a header part and content-data. The header part carries metadata most of which are optional, and the content data carries our necessary capabilities.


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.
[Qiufang Ma] The capabilities of the receiver side can be documented in offline yang-instance-file so that the publisher can access the files in any accessible way. There is no additional requirement that the receiver side be the NETCONF or RESTCONF server. We do not even require that the receiver side be the HTTP server. Hopefully this clarifies.



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.
[Qiufang Ma] Our mechanism is to discover the full capabilities of the publisher/receiver side, not just http-notif-related. I understand that http-notif does not care about other transport capabilities, I think udp-notif is the same. Repeated capability queries for each individual transport protocol seem inflexible and incur unnecessary overhead.

Best Regards,
Qiufang Ma

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 <[e-mail]<mailto:[e-mail]>> wrote:

[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<http://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"

               ]

             }

           ]

         }

       }

     }

}