Re: [netconf] Capability-fetching mechanisms

[Qin Wu <[e-mail]>]

Thanks Alex for the feedback. Please see my reply inline below.
发件人: Zmail [mailto:[e-mail]]
发送时间: 2021年6月8日 15:21
收件人: Qin Wu <[e-mail]>; [e-mail]
抄送: [e-mail]; maqiufang (A) <[e-mail]>; Pierre Francois <[e-mail]>; [e-mail]
主题: Re: [netconf] Capability-fetching mechanisms

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.

[Qin]: Agree, I think the client is corresponding to receiver while the server is corresponding to the publisher.

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.

[Qin]: That’s a good distinction. In addition, I am thinking, data-export-capabilities focuses on generic data model or data export features in your words, while https-notif focuses on protocol that is used to carry these data export features.

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...)
[Qin]: That’s a good argument on why we should separate data model or data export features definition from protocol defintions.
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
[Qin]: Sort of agree, but http notif also add a statement to say
“
   For publishers using Subscription to YANG Notifications [RFC8639<https://datatracker.ietf.org/doc/html/rfc8639>],
   dynamic discovery of a receiver's supported encoding is necessary
   only when the "/subscriptions/subscription/encoding" leaf is not
   configured
”

As I understood in the precedent mails, Qin is looking for a common protocol to exchange these capabilities over all notifications drafts.

[Qin]: See above, as I clarified, I think we can focus on common data model for data export features instead of common protocol,  we will leave protocol extension to each transport specific notif draft, does this make sense?

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…

[Qin]: Agree. See more clarification above.
Any thoughts ?

Alex Huang Feng
INSA Lyon | Unyte team


Date: Wed, 2 Jun 2021 01:07:05 +0000
From: Qin Wu <[e-mail]<mailto:[e-mail]>>
To: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Cc: Kent Watsen <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>"
<[e-mail]<mailto:[e-mail]>>
Subject: [netconf] ??:  Capability-fetching mechanisms
Message-ID: <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="utf-8"

Hi, Mahesh:

???: Mahesh Jethanandani [mailto:[e-mail]]
????: 2021?6?2? 6:44
???: Qin Wu <[e-mail]<mailto:[e-mail]>>
??: Kent Watsen <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]><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]><mailto:[e-mail]>