Re: [netconf] Capability-fetching mechanisms

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

Hi, Kent,
Please see my reply inline.

From: Kent Watsen [mailto:[e-mail]]
Sent: Tuesday, May 18, 2021 6:00 AM
To: maqiufang (A) <[e-mail]>
Cc: Wei Wang <[e-mail]>; Qin Wu <[e-mail]>; [e-mail]
Subject: Re: [netconf] Capability-fetching mechanisms

Hi Qiufang Ma,


Since data-export-capability draft defines a mechanism to discover a set of capabilities supported by the NETCONF/RESTCONF server(the network device, actually).
But in the http-notif draft, what we need to discover is the receiver's capabilities, rather than the device’s.
So I think the reason Kent said that the receiver must also be a NETCONF and/or RESTCONF server is that only in this case can the data-export-capability draft be used as capability discovery on the http-receiver side.
Please correct me if there exists any misunderstanding.-:)

I think that your understanding of the https-notif draft is correct.
[Qiufang Ma] Thanks.


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

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.

Thanks

K.