[netconf] Capability-fetching mechanisms

[Kent Watsen <[e-mail]>]

Dear WG,

One of the outcomes from “https-notif” presentation during the NETCONF 110 session was to what extent all the notif (e.g., https, udp, etc.) drafts should define their own capability-fetching mechanism, or use the mechanism defined by the "data-export-capabilities” draft.

As authors, Mahesh and I discussed some of the PROs and CONs of the approaches as follows:

PROs (for having a shared-mechanism):
Enables a common mechanism spanning multiple notif transports to exist 

CONs (against having a shared mechanism):

Entails each receiver also needing to be a NETCONF and/or RESTCONF server
Whereas a notif-specific solution can be optimized on a per-protocol basis.
FWIW, if RC, the receiver COULD minimally support *just* the single GET request (i.e., not a complete RC server)
Still, networking/firewall would have to support the outbound NC/RC flow, in addition to the base notification flow

Potentially extends the number of capabilities to be more than minimally necessary
e.g., the current "data-export-capabilities” modules define dozens of capabilities supporting RFC 8639 and RFC 8641 that are not needed for https-notif, when RFC 8639 is not in use.
HTTPS-Notif seems to need only three capabilities:
What encodings are supported (json, xml, binary)
If the RFC 8639 state machine is supported.
If bundled messages is supported.
Presumably, UDP-Notif would similarly have a small set of capacities.
In fact, it may be less, as UDP may be unable to support RFC 8639


Thoughts?

Kent and Mahesh  // as authors