[netconf] 答复: Capability-fetching mechanisms

[Qin Wu <[e-mail]>]

Hi, Mahesh:

发件人: Mahesh Jethanandani [mailto:[e-mail]]
发送时间: 2021年6月2日 6:44
收件人: Qin Wu <[e-mail]>
抄送: Kent Watsen <[e-mail]>; [e-mail]
主题: 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 <[e-mail]<mailto:[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??

[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
[e-mail]<mailto:[e-mail]>