Re: [netconf] Capability-fetching mechanisms

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

Hi, Rob,

Please see my reply inline.
From: Rob Wilton (rwilton) [mailto:[e-mail]]
Sent: Monday, July 19, 2021 10:30 PM
To: maqiufang (A) <[e-mail]>; Mahesh Jethanandani <[e-mail]>; Qin Wu <[e-mail]>; Kent Watsen <[e-mail]>
Cc: [e-mail]
Subject: RE: [netconf] Capability-fetching mechanisms

Hi,

I think that it would be good if we could somehow get to a conclusion on this thread, so that we are able to progress draft-ietf-netconf-https-notif.


(1) My first question is whether we definitely need a dynamic mechanism to discover an HTTPS receiver’s capabilities?

I would have thought that in most cases, the management entity configuring the subscription would also know what format the receiver is able to handle those notifications.  Given that there are two solutions on how to handle to share this dynamic receiver encoding parameters, I assume that there is a demand and use case for this, but I can also see an argument that any such mechanism should be optional to implement and the mechanism being lightweight seems like a benefit.


(2) Regarding the capability mechanism in draft-ietf-netconf-https-notif:
This mechanism looks pretty lightweight to me.  I did have a couple of questions though.

(i)                  Did you consider using rfc8791 to define the receiver-capabilities?  This could allow it to be put into a YANG module, which could also easily allow the information to be made available a YANG instance data document, allowing it to be used for offline purposes.

(ii)                I wasn’t sure why you used inet:uri’s for the capabilities rather than YANG identities.  I guess that this would be a bit more work because it would require both an IANA maintained registry of capabilities and also a derived IANA registry of YANG identities that would be automatically updated by IANA whenever a new capability is added to the registry.  E.g., following the approach for say for iana-routing-types YANG Module<https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml>


(3) After reading draft-tao-netconf-data-export-capabilities and this thread, I’m still somewhat struggling to understand exactly where/how the YANG module that this draft defines would be used:


(i)                  I can see how it can be used to provide additional information about what capabilities a server (i.e., publisher) supports, and it leverages draft-ietf-netconf-notification-capabilities.  I can see how it can be used to export server capabilities to a management client either via regular NETCONF/RESTCONF requests or as an offline YANG instance data file.  However, this is not documenting the capabilities that the receiver can handle, but instead is only documenting what encodings a server is capable of encoding the notifications in.
[Qiufang Ma] As you said, we originally focus on exposing server capabilities to a management client via NETCONF/RESTCONF message exchange. We also investigate how server capabilities can be advertised using offline yang instance data file and how client capability can be learnt using offline yang instance data file. Based on our analysis, it looks the client capability discovery lacks a good use case. Therefore we decide to focus only on server capability discovery in draft-tao-netconf-data-export-capabilities. If https-notif does have a requirement for discovering the capabilities that the receiver can handle, we leave it to https-notif draft to define.


(ii)                But Qin’s example suggests that the same YANG module could be used by a receiver to advertise the receiver capabilities encoded as a YANG instance data document.  Making the receive capabilities available in an offline format is potentially helpful but using the same instance data format during a dynamic exchange seems a bit more complex, and if it was receiving the full capabilities from a receiver (e.g., if the receiver was a NETCONF/RESTCONF server) then this could end up being a much larger file compared with the approach proposed in draft-ietf-netconf-https-notif.
[Qiufang Ma] As we clarified above, we think draft-tao-netconf-data-export-capabilities focuses on server capability fetching rather than client capability fetching.
Therefore we believe https-notif looks into different use case. But for UDP-notif and other potential transport protocols, they can use NETCONF/RESTCONF protocol fetch transport related capabilities.
Comparing client capability fetching mechanism in the https-notif with server capability fetching defined in draft-tao-netconf-data-export-capabilities doesn't make sense, agreed?

(4) There is a question about whether these capabilities should be defined on a per transport basis, or generically, agnostic to the transport mechanism.  My instincts here are that not all capabilities will necessarily be supported by all transports, nor do I think that there will either be that many transports nor that many capabilities.  This would seem to suggest that defining these on a per transport basis probably isn’t likely to be a problem.
[Qiufang Ma] Based on capability fetching discussion on this thread, we believe the agreement is we should focus on a common data model rather than common protocol.
In addition, all capabilities are optional attributes, for some capabilities, we define it as empty type, therefore you don't need to specify all capabilities for each transport.
if https-notif doesn't require any server capabilities to be fetched, that is fine. The model proposed in this draft works for other server capabilities advertisement cases, e.g., UDP-Notif, YANG Notifications defined in RFC8639, RFC8641.
Hopefully this clarifies.☺


Best Regards,
Qiufang Ma

Trying to close this issue during the NETCONF session (or even over email beforehand) would be great.

Regards,
Rob


From: netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of maqiufang (A)
Sent: 01 July 2021 14:42
To: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] Capability-fetching mechanisms


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]<mailto:[e-mail]>>
Cc: Kent Watsen <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>; Zmail <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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"

               ]

             }

           ]

         }

       }

     }

}