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

Andy Bierman <> Mon, 10 August 2020 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F5AF3A0CA4 for <>; Mon, 10 Aug 2020 12:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IEbApyGRC7sN for <>; Mon, 10 Aug 2020 12:39:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B5483A0C9C for <>; Mon, 10 Aug 2020 12:39:18 -0700 (PDT)
Received: by with SMTP id v9so10921699ljk.6 for <>; Mon, 10 Aug 2020 12:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kw1kQwroDwpAqF3aJz4tsw5jb7HZsCEcIf7ZO69PJNw=; b=bpqSeKKa450cr64E3SbiamkOPiC8sLsxVE06xEbjLNJbbc+wLndKmt4Y/5F1sRNIlf eSWyed+Go+gD035r5ArT8yUx0NVzL+duzDHffsb5PJ9IqBcxLsK9jSH3fXFL3KA0l6AZ fPyC56jDteoKMh7yt/VY6GgTjSsL6DOhYAsTVu0PlT+2uqsjvnBLOAdFW4LOrI0oyg8M oVIuoO9haw2qqjXGOcFthjhGYh32Tdw+Vu6d73MV3xAMkT2sYMrxYykwPP/4ouDC9FNd JpZ9uxLctcqKx7cQOh/tUW+7rrXJN/8xC6XO41KCsU3VjMbebssE8uLcVWSKHIPD5UT1 MutA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kw1kQwroDwpAqF3aJz4tsw5jb7HZsCEcIf7ZO69PJNw=; b=Wnxr0rPrL3o7I3NCUhQo2Ux4KIBmXXYOUWAODFrxm4SHy/3AsN9vHQ6Q2oVEdFtrhH Vp/sRn8uC7ENQcjB+oqJJMr3RQTShpPo+WOj+ZmqTRbQWh5PBV5H54WRm39+oHVfp/7x VR/yjPE/QEjy0pc4E0VY5HtH+kjobZdrYJyjGSN/OLZRNr1Egt39xcUyL2kTa1D5Vbj4 d2RYui5uCBDsIkps/MsREqYtvMif5oy7wQXjw+1chqLCEkto9e0KfG6akKlEBU+B37Qg omocwjZwtugA/Ijoh9VAQXG0EbI84UiBb3n4BlNErojbZXIb2XBhHYR2hiuWzJEzbuTd 1J+Q==
X-Gm-Message-State: AOAM533gO6mTnIRqF2C/ROqBhVQOv9QZdG9IgdnP/FMHaRhGDSVumwVv XWA9SZu2d2YUTiVzt+uDZ4Tq1uTHomcowsmqlLKxVA==
X-Google-Smtp-Source: ABdhPJycq4ucfv4myuPr9C6wD9Mfl9ktgZWpx7DMS8hNd+pIE4aqyRmPZxcD8dtMYQBEWyN7KnFpQlR5Wp5tiKyd0Ik=
X-Received: by 2002:a2e:9d17:: with SMTP id t23mr1279339lji.456.1597088356298; Mon, 10 Aug 2020 12:39:16 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Mon, 10 Aug 2020 12:39:05 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000027337c05ac8b1c51"
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-data-export-capabilities
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2020 19:39:22 -0000


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
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
the correct answer for a specific combination of subscription parameters.


On Wed, Aug 5, 2020 at 3:17 PM Kent Watsen <> wrote:

> Per the previous email sent moments ago, the chairs would like to solicit
> input on the following draft:
>    Title: Telemetry Data Export capability
>    Link:
> 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
> _______________________________________________
> netconf mailing list