Subject: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

From: Kent Watsen <[email-masked]>
Date: Wed, 5 Aug 2020 22:17:37 +0000

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Telemetry Data Export capability
   Link: https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities
   Abstract:

      This document proposes a YANG module for telemetry data export
      capability which augments system Capabilities model and provides
      additional telemetry data export attributes associated with system
      capability for transport dependent capability negotiation.

In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?

PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 10 Aug 2020 15:32:54 +0800

Hi, Chairs

    I would like to contribute to the draft. 

I believe that it is important to enable subscriber and publisher to agree upon transport protocol (e.g., TCP, UDP), encoding format (e.g.,binary encoding,xml, json), encryption, compression mode to be used
and allow the client to select specific transport protocol, encoding format,etc when subscribing datastore node update.
And I also believe that the NETCONF WG is the appropriate WG for this work. draft-ietf-netconf-notification-capabilities provides a good basis for server capabilities advertisement.
Addition data export capability can be built on top of it.

I have read the latest version of the draft and believe it has been in good shape and served as a reasonable good starting point.
If this work gets adopted, I am willing to review this work as contributor and contribute to any discussion needed and
we are interested to implement and plan to deploy this technology.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Kent Watsen
Date: 2020-08-06 06:17
To: [email-masked]
Subject: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities

NETCONF WG,

NETCONF Chairs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2020 12:39:05 -0700

Hi,

I am trying to understand the problem this draft is attempting to solve.
The premise seems to be that the error handling and "hints" mechanism
in RFC 8639 and RFC 8641 do not work and the client needs to retrieve
extensive monitoring info to determine how to setup notifications on the
server.
In theory this data could be used to prevent an <rpc-error> to be returned
for <establish_subscription> or <edit-config>

IMO the current approach is much better than this proposed approach.
The server can provide the hints based on the exact request from the client.
The static "per-node" monitoring data can be quite large, and yet not
provide
the correct answer for a specific combination of subscription parameters.

Andy

On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen <[email-masked]> wrote:

>    Link: https://tools.ietf.org/html/
> draft-tao-netconf-data-export-capabilities
>    Abstract:
>
> PS: this message is itself not an adoption poll, but rather an attempt to
> gauge interest/support for a potential future adoption poll.
>
> NETCONF Chairs
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>