Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Qin Wu <> Wed, 19 August 2020 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 910EF3A1090 for <>; Tue, 18 Aug 2020 18:34:19 -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 VT3ty9fRvBsH for <>; Tue, 18 Aug 2020 18:34:17 -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 85B833A108B for <>; Tue, 18 Aug 2020 18:34:17 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 85748A7B2CD1327CF340; Wed, 19 Aug 2020 02:34:11 +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; Wed, 19 Aug 2020 02:34:11 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 19 Aug 2020 02:34:10 +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; Wed, 19 Aug 2020 02:34:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Wed, 19 Aug 2020 09:34:04 +0800
From: Qin Wu <>
To: Andy Bierman <>, Juergen Schoenwaelder <>, Kent Watsen <>, "" <>
Thread-Topic: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Thread-Index: AdZ1yMtxrcoJP21tTkq2oWw6HmdRjg==
Date: Wed, 19 Aug 2020 01:34:03 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD92A503dggeml531mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Aug 2020 01:34:20 -0000

Hi, Andy:
发件人: netmod [] 代表 Andy Bierman
发送时间: 2020年8月19日 3:10
收件人: Juergen Schoenwaelder <>de>; Kent Watsen <>et>;
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags


On Mon, Aug 17, 2020 at 9:53 PM Juergen Schoenwaelder <<>> wrote:
On Mon, Aug 17, 2020 at 10:05:27PM +0000, Kent Watsen wrote:
> This email begins a 2-week adoption poll for:
> Please voice your support or objections on list before August 31.
> Notes:
>    1)  -03 was presented during the 108 session, hence the I-D has been updated twice since then.
>    2) Please be aware that IPR has been filed for this I-D:
> <>.

I am against adoption. I am against introducing a collection of
standards-track extension statements without answering the question
who controls, enforces and reviews the usage of these extension
statements (when and how are they used). Some statements and tags are
either addressing issues caused by underspecified YANG modules or they
overlap with the deviation mechanism that we have in place since day
one of YANG. Others are very vaguely specified, it is unclear how they
will lead to interoperable behavior. If module authors are too lazy
to use existing YANG mechanisms properly, does it make sense to add
more mechanism to the YANG eco system? I doubt it.

I am also against adoption.
This module introduces 9 extension-stmts that represent a huge administrative burden for
module developers without any proven value.

[Qin]: Not all 9 extension stmts needs to be mandatory supported at the same time,  the key value of these tags is to capture performance metric data or KPI data.
If the number of extension-stmts is the concern, we could reduce down to two or three performance metric related extension stmts, opm tag focuses on telemetry data
Classification and operational type which identify statistics operations such as sum, avg,min.
It is not even clear that such specific metadata
is even applicable to all instances of the tagged data node.
OPM tag and operation type are not targeted to apply to all instance of the tagged data node, instead, it aims at sorting out characteristics data, KPI data within the module,
such as counter, statistics, performance metrics.
For context information related tag, e.g., service tag, data source tag can be applicable to all instance of the tagged data nodes since it provide another angle operation and management data classification.
IMO it is not likely that a single
metric will apply to all instances, all all times, in any possible deployment scenario.
[Qin]:You might misunderstand, it is not our goal to make a single metric apply to all instance, instead, these tags will be used to sort out all performance metric related data node or data objects.
There are no standard operations or mechanisms to use module tags.
They have not demonstrated any standards value so far.
[Qin]: Understand, IETF focus on developing many generic building blocks, they can used by developer and operator to build a complete solution.
demonstrating standard value or deploying all of them always need to step by step and will take time. It apply to all other newly published building blocks in OPS area, not limited to module tags.



Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>

netmod mailing list<>