Re: [netconf] Capability-fetching mechanisms

[Mahesh Jethanandani <[e-mail]>]

[Trimming down the e-mail to open topics]

Hi Qin,

See inline with [mj1]

> On May 18, 2021, at 4:40 AM, Qin Wu <[e-mail]> wrote:
> 
> Hi, Mahesh:
>  
> 
> The question is whether the receiver needs to be a NETCONF/RESTCONF server. As maqiufang wrote in his response, if the receiver supports the data-export-capabilities draft, then it would need to be a NETCONF/RESTCONF server, whereas with the https-notif draft that is not the case. This is the case whether the receiver supports RFC 8639 or not.
> [Qin]:My understanding is data-export-capabilities doesn’t require receiver to be tied with NETCONF/RESTCONF server. I assume the management system (i.e., receiver) and network device (i.e., publisher) can use HTTPS to exchange advertised data.
> In addition, Maybe what is missing in the data-export-capabilities draft is to define RPC to allow the publisher get capability from receiver through HTTPS channel, similar to what is get-bootstrapping-data RPC defined in RFC8572.

[mj1] Stipulating a HTTPs channel works for the HTTPS notif draft. But what will other transport type drafts use? e.g. the UDP notif draft?? 

>  
> Please note that RFC 8639 receivers do not have to be NETCONF/RESTCONF servers for configured subscriptions. RFC 8639, Section 2.7 defines the control messages such as <subscription-started> using one-way YANG “notification” statements.
>  
> [Qin]: Understand this case, Do you think we should define a new notification in the data-export-capabilities draft instead of considering to define RPC?

[mj1] I do not understand this statement. Can you expand?


Mahesh Jethanandani
[e-mail]