Subject: Re: [netconf] Capability-fetching mechanisms

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Jun 2021 23:10:05 +0000

Hi Qiufang Ma,

> Hi, Kent,
> Please see my reply inline.
>  
> From my perspective, The data-export-capability does not have to require the receiver to function as a NETCONF/RESTCONF server. The capability discovery mechanism in these two drafts can complement each other in this case. In other cases, data-export-capability provides the receiver with an overall  acquisition of the transport capabilities about the device.
>  
>  
> I’m unclear on each of your sentences above.  Could you, for for sentence, provide more context regarding what you mean?  For instance, how could the data-export-capability draft not imply the receiver be a NC/RC server?  Likewise, how could the two drafts compliment each other?  Also, by mentioning “other cases”, but what is the ”first” case that this contrasts to?  
> [Qiufang Ma] Sorry for being unclear.
> On the one hand, data-export-capability draft  focuses more on discovering a set of capabilities supported by the publisher, and the publisher can learn the capabilities of the receiver through the mechanism defined in http-notif draft. Therefore the capability discovery mechanisms of these two drafts complement each other to realize the capability discovery of both receiver and publisher.

Now I understand what was meant before - thanks.

To be honest, I didn’t realize that "data-export-capability” was primarily for clients to retrieve server-capabilities.  Of course, its obvious now, but somehow I thought it was defining a different way for a server to get client capabilities.

> On the other hand, as Qin has clarified, maybe we can define a shared mechanism to fetch the receiver capability in the data-export-capability draft that does not need the receiver to be a NC/RC server.
> So I do not think it would be necessary for the receiver to be a NC/RC server.

Maybe, but the desire to do so is now less in my mind given the above “revelation” to me.  That said,  let’s see how this matter plays out in the thread between Qin and Mahesh...

> Other cases refer to cases other than capability discovery at the receiver side. For example, the receiver learns capability supported by the publisher(e.g., encoding format), which helps (e.g., in the selection of the encoding format) when establishing a dynamic subscription.

Noted.

K.

---

From: Zmail <[email-masked]>
Date: Tue, 8 Jun 2021 09:21:00 +0200

Hi everyone,

I join this thread to discuss the understanding of the draft data-export-capabilities and how it is confusing with the capabilities export feature of https-notif draft.

I think that the data-export-capabilities draft should change the terms client/server to publisher/receiver. That way, I think it would be clearer in which draft we discuss which case.

As I understood reading this thread, data-export-capabilities discusses how the receiver (client) could get the publisher's (server) capabilities. And on the other side, the HTTPS GET capabilities from https-notif draft defines how the receiver (client) could export its capabilities to the publisher (server). It’s that right ? Please correct me if there is any misunderstanding.

On the other hand, we are discussing how the receiver could expose its capabilities on each notification drafts (https-notif, udp-notif, etc). Notifications drafts defines a protocol to exchange notifications over a transport layer, so from my point of view, the capabilities export feature should not be defined there because :
1. it would be transport dependent (I don't feel confortable putting a HTTPS export capabilities on the udp-notif draft...)
2. for configured notifications from the publisher side, there is no need to know the capabilities for the receiver, they already know them
3. I think we are mixing the configuration part and the notification part

As I understood in the precedent mails, Qin is looking for a common protocol to exchange these capabilities over all notifications drafts. Maybe it is better to define this capabilities export transport dependent protocol on another draft ? Or on the data-export-capabilities draft, but it is defined as transport agnostic…

Any thoughts ?

Alex Huang Feng
INSA Lyon | Unyte team

> Date: Wed, 2 Jun 2021 01:07:05 +0000
> From: Qin Wu <[email-masked]>
> To: Mahesh Jethanandani <[email-masked]>
> Cc: Kent Watsen <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Subject: [netconf] ??:  Capability-fetching mechanisms
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi, Mahesh:
> 
> ???: Mahesh Jethanandani [mailto:[email-masked]]
> ????: 2021?6?2? 6:44
> ???: Qin Wu <[email-masked]>
> ??: Kent Watsen <[email-masked]>; [email-masked]
> ??: Re: [netconf] Capability-fetching mechanisms
> 
> [Trimming down the e-mail to open topics]
> 
> Hi Qin,
> 
> See inline with [mj1]
> 
> 
> On May 18, 2021, at 4:40 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> 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??
> 
> [Qin]:I think UDP notif draft could also use HTTPs channel to carry capability information from the server to the client in the form of YANG instance file format.
> 
> 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?
> 
> [Qin]: I am not sure the RPC is a good design choice, I think we could have 3 options
> ?a?Report capability information from the HTTPs server or the HTTPs client at run-time or implementation- time, per the YANG Instance Data File Format.
> (b) Define one way YANG notification similar to <subscription-started> that is sent from the server to the client
> (c) Report capability information only from NETCONF server using YANG model define in data-export-capaiblities draft
> I think (b) only allow the server advertise the server capability to the client but does not allow the client issue notification and advertise client capability to the server
> (c) is something you envision how it is used, the limitation is to require NETCONF server to be supported by the receiver or the client, but this option is not what we proposed in the data-export-capabilities draft.
> The solution we proposed is (a) which allows report capability information either from the Server or the client using YANG Instance data file. Hope this clarifies.
> 
> Mahesh Jethanandani
> [email-masked]<mailto:[email-masked]>
>