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

Qin Wu <> Tue, 18 August 2020 07:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CE013A180C for <>; Tue, 18 Aug 2020 00:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MKLRgtqSPBpm for <>; Tue, 18 Aug 2020 00:24:33 -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 73A273A1809 for <>; Tue, 18 Aug 2020 00:24:33 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 7E819E804A30C14C034D; Tue, 18 Aug 2020 08:24:29 +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, 18 Aug 2020 08:24:29 +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, 18 Aug 2020 08:24:28 +0100
Received: from ([]) by ([]) with mapi id 14.03.0487.000; Tue, 18 Aug 2020 15:24:22 +0800
From: Qin Wu <>
To: Juergen Schoenwaelder <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Thread-Index: AdZ1J8OaFWJEloQESriMylME0vOKIA==
Date: Tue, 18 Aug 2020 07:24:22 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
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: Tue, 18 Aug 2020 07:24:35 -0000

发件人: netmod [] 代表 Juergen Schoenwaelder
发送时间: 2020年8月18日 12:53
收件人: Kent Watsen <>
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

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). 

[Qin]: As clarified earlier, these extension statements will be used in the same way as module tag does which is defined in draft-ietf-netmod-module-tags-10, the difference is module tag is at module level while data object tag is at data node level which provide fine granularity of tag management. draft-ietf-netmod-module-tags-10 clearly clarify who controls, enforces usages of the extension statements.
   Tags may be defined and associated at module design time, at
   implementation time, or via user administrative control.  As the main
   consumer of tags are users, users may also remove any tag, no matter
   how the tag became associated with a module.
So does this draft.
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. 
[Qin]: Data object tag is not tag everything, instead it will only tag performance related data, context related tag is motivated by ETSI Context Information Management (CIM) effort.
Others are very vaguely specified, it is unclear how they will lead to interoperable behavior. 
[Qin]: The mechanism defined here is targeted generic mechanism, can be applicable to not only standard model, but also vendor specific model or user specific models, the big value is to increase interoperability since it can be used multi-vendor environment, and provide consistent reporting and representation.
One of example, is two vendors deploy different vendor specific QoS model for the same functionality, data object tag can point to different data object name with same functionality, which provide 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.
[Qin]: It is not about lazy, similar to module tag defined in draft-ietf-netmod-module-tags-10, it provides operation and management data classification and help you quickly capture KPI data and further provide data object correlation by using context information.

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