Hi, Andy: 发件人: netmod [mailto:[email protected]] 代表 Andy Bierman 发送时间: 2020年8月19日 3:10 收件人: Juergen Schoenwaelder <[email protected]>; Kent Watsen <[email protected]>; [email protected] 主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Hi, On Mon, Aug 17, 2020 at 9:53 PM Juergen Schoenwaelder <[email protected]<mailto:[email protected]>> wrote: On Mon, Aug 17, 2020 at 10:05:27PM +0000, Kent Watsen wrote: > This email begins a 2-week adoption poll for: > > https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-05 > > 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: > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags > > <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags>. > 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. [Qin]: 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. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
