Re: [netconf] Configured receiver capability exchange

[Mahesh Jethanandani <[e-mail]>]

Hi Balazs,

It is clear that the WG does not want to fixed to a single type of encoding for notifications, particularly since the desired one, e.g. binary encoding, is not widely deployed. If the capability has to be discovered as it is incrementally deployed, I do not see how one can avoid a roundtrip, whether it is Eric’s suggestion on <subscription-started> or our suggestion on doing a GET. You could cache on the receiver capabilities to avoid discovery, but that will lead into not discovering capabilities till that cache is timed-out.

Cheers.

> On Jan 17, 2020, at 4:27 AM, Balázs Lengyel <[e-mail]> wrote:
> 
> Hello,
> I would like a discovery mechanism that does not include a mandatory additional message roundtrip. 
>  
> Most of the times the subscriber will be aware of the receivers capabilities, in these cases so discovery is not needed; so don’t add overhead.
>  
> Customers also indicated that they anticipate that TCP/TLS will often be used only for a few notifications broken down and later reestablished so any overhead we add will be added for each (many) session setup. 
>  
> Regards Balazs
>  
> From: netconf <[e-mail]> On Behalf Of Eric Voit (evoit)
> Sent: 2020. január 15., szerda 21:23
> To: Mahesh Jethanandani <[e-mail]>
> Cc: [e-mail]
> Subject: [netconf] Configured receiver capability exchange
>  
> Hi Mahesh,
>  
> During the IETF 106 session, there was discussion on how both a publisher might know if there is receiver support for draft-ietf-netconf-notification-messages <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>.  Section 6 highlights several of the considerations.   Relevant are the following:
>  
> (a) Remote device capability discovery from the point of view of the Publisher needs to be enhanced to know if the far end can interpret notification messages type beyond RFC-5277, Section 4.
>  
> (b) This capability discovery question is relevant for both configured subscription receivers and dynamic subscribers.  
>  
> (c) The capability discovery question can be generalized beyond subscriptions, as there are many reasons to know the available capabilities of the far end.   
>  
> (d) Capability discovery advertisement has traditionally been discussed within transport documents (e.g. RFC-6241 Section 8.1).   
>  
>  
> Based on (a)-(d), coming up with a transport independent point-solution within draft-ietf-netconf-notification-messages <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> *just* to discover this single element of client functionality seems overkill/heavyweight.
>  
> I was fine with letting this remote capabilities discovery question sit for a while.   However draft-ietf-netconf-https-notif <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> shows that we now must address this question.  Specifically should the diagram section 1.4.1 show this capability exchange?  
>  
> It turns out that independent of draft-ietf-netconf-notification-messages, there several questions in draft-ietf-netconf-https-notif which need to be answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG defined notification #1" anyway.  These questions are:
>   (1) Does the targeted HTTPS receiver support configured subscriptions?
>   (2) Can the targeted HTTP@ receiver accept a new subscription as described in a <subscription-started>?
> Only if these questions are "yes", should the <subscription-started> be responded to with an "OK".
>  
> Add to this a third question driven from (a)-(d):
>   (3) Does the receiver support the message type within "draft-ietf-netconf-notification-messages"?
>  
> A strawman way to handle the all three questions within draft-ietf-netconf-https-notif would be to respond to a <subscription-started> notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 would include body elements listing supported receiver resources.  Maybe something YANG encoded via ietf-yang-structure-ext containing:
>  
>       <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>         <capabilities>
>           <capability>
>             urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0
>           </capability>
>         </capabilities>
>       </foo>
>  
> What do you think of this approach?
>  
> Eric

Mahesh Jethanandani
[e-mail]