Re: [netconf] Capability-fetching mechanisms

[Kent Watsen <[e-mail]>]

Hi Rob and Qiufang,


> On Jul 20, 2021, at 6:15 AM, maqiufang (A) <[e-mail]> wrote:
> 
> 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.

The issue goes back to RFC 8639 (Subscription to YANG Notifications) where the “encoding” leaf is left optional in case other solutions exist.   Having the inband negotiation is mostly for deployment flexibility.


>  (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.

No, we didn’t consider using an sx:structure, but that would be okay (IMO) as it doesn’t imply at all that the Receiver is a “server”.   Good suggestion.  That said, I’m unsure how an sx:structure would appear in a "YANG instance data document”, or any configuration or state data tree for that matter.


> (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>
I’m unsure if the use of identities was ever discussed.  It seems reasonable and, if not mistaken, would NOT require an IANA registry of any sort…as the identities (on the wire) would be scoped by their modules.   The only “downside” is the “overhead” introduce for custom (non-standard) capabilities, but it doesn’t seem meaningful relative to getting IANA out of having to maintain a registry of any kind.

 
> (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.J


Reading all of Rob’s and Qiufang’s comments above, it seems that we’ve gotten the point where the scales are tipping towards https-notif NOT using the "YANG instance data document” structure to encode a “system-capabilities” node having "data-export-capabilities” augmentations.  Yes?

Thank you Qiufang for taking the time help us understand the proposal fully.  I think that it is fair to say that we understand that the “opportunity” exists, but the extra complexity seems unnecessary for the very limited use-case in mind here.

Kent // contributor


>  
> Best Regards,
> Qiufang Ma
>  
> Trying to close this issue during the NETCONF session (or even over email beforehand) would be great.
>  
> Regards,
> Rob