Re: [netconf] Capability-fetching mechanisms

Hi, Kent:
Sorry for late follow up.
On Apr 19, 2021, at 5:39 PM, Kent Watsen <kent@watsen.net<mailto:kent@watsen.net>> wrote:

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:
[Qin]:I am under impression that shared-mechanism has a lot of benefit.:-)

  *   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
                                [Qin]:Is receiver in this context NETCONF/RESTCONF server or client?
                                  I think we mix two things,

a.       one is the server advertise its capability to the client , (i.e., server capability advertisement)

b.       the other is server send the capability query request the client and get capability response from the client. (client capability fetching)
                                I think data-export-capabilities right now focuses on (a), the question you ask here is whether (b) can be defined as shared mechanism which can be part of
                                the "data-export-capabilities” draft. If my understanding is correct, I think it will be nice to have (b) such shared mechanism, i.e., Defining (a) and (b) in a single place.

        *   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
                   [Qin]: "data-export-capabilities " draft uses draft-ietf-netconf-notification-capabilities-16 as basis or foundation. If my understanding is correct, draft-ietf-netconf- notification-capabilities-16 doesn’t
require receiver to support NETCONF or   RESTCONF.

     *   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,
                                     [Qin] Dozens of capabilities defined by the current "data-export-capabilities” modules are all optional capability. It doesn’t require all the capabilities to be supported.
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.
                                  [Qin]: So HTTPs-notif can pick those three capabilities and ignore other capabilities.  I believe HTTP has mechanism to deal with these unhandled capabilities advertised by the network device.  One of such example is unhandled
Namespace defined in (https://datatracker.ietf.org/doc/html/draft-ietf-regext-unhandled-namespaces-07)

           *   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
             [Qin]: See clarification above. For UDP notif, it doesn’t require all the capability to be supported.

Thoughts?

Kent and Mahesh  // as authors

_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf