Juergen: -----邮件原件----- 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder 发送时间: 2020年8月18日 12:53 收件人: Kent Watsen <kent+i...@watsen.net> 抄送: netmod@ietf.org 主题: 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: > > 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). [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. /js -- 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
