Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities

Qin Wu <> Tue, 11 August 2020 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0325F3A0EDF for <>; Mon, 10 Aug 2020 19:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xCbpo-KUNN8c for <>; Mon, 10 Aug 2020 19:10:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECDD43A0EE2 for <>; Mon, 10 Aug 2020 19:10:46 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 85DFF4C283F0D1E09775 for <>; Tue, 11 Aug 2020 03:10:45 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 11 Aug 2020 03:10:45 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:10:44 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:10:39 +0800
From: Qin Wu <>
To: Andy Bierman <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities
Thread-Index: AdZvgKDDrRFiNBN5S662w/6KCddT4w==
Date: Tue, 11 Aug 2020 02:10:38 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC2Edggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-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: Tue, 11 Aug 2020 02:10:49 -0000

发件人: netconf [] 代表 Andy Bierman
发送时间: 2020年8月11日 3:39
收件人: Kent Watsen <>
主题: Re: [netconf] Adoption-suitability for draft-tao-netconf-notif-node-tag-capabilities


I am trying to understand the problem statement in this draft.
It seems to be a way to assign various tags to data node objects.
It uses the tags type from ietf-module-tags, which implies that modules and nodes
share the same set of tags.
[Qin]: It is not the goal to share the same set of tags for module and nodes, nodes could
Have their own tags and used to tag management and operation data or telemetry data defined within the module , it is data node level tag, not module level tag.
If this will be the issue, we can define tag separately.
There is also an assumption that the error/hints mechanism in RFC 8639 and 8641
do not work and this significant amount of proposed metadata could be used to avoid
receiving an <rpc-error> for an <establish-subscription> or <edit-config> request.

[Qin]: See clarification for data export capability draft, it is designed as server capability exposure, not targeted to replace error handling  for <establish-subscription> and <edit-config>.
They are used at different phase. The big different with Data export capability, is it doesn’t tell the client how to select transport protocol, encoding, security scheme, etc, it tells the client
Which data object is characteristics data or KPI data, which help avoid fetch noise data from the data source and provide comprehensive view of the network quality or network health
from different angles.

IMO the current approach is sufficient and new mechanisms are not needed.


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


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

   Title: Self-explanation data Node tag capability
      Before a client application subscribes to updates from a datastore,
      server capabilities related to "Subscription to YANG Datastores" can
      be advertised using YANG Instance Data format.  These server
      capabilities can be documented at implement time or reported at run-

      This document proposes a YANG module for self-explanation data Node
      tag capability which augments system capabilities model and provide
      additional self-explanation data node attributes associated with node
      selectors within per-node capabilities.

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 mailing list<>