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

From: Kent Watsen <[email-masked]>
Date: Mon, 17 Aug 2020 22:05:27 +0000

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

Netmod Chairs

---

From: Wang Wei <[email-masked]>
Date: Tue, 18 Aug 2020 01:09:57 +0000

Hi all，

I have reviewed the latest version, my comments are addressed, I support adoption.

Best Regrads,
Wei
发件人: [email-masked]<mailto:[email-masked]>
发送时间: 2020年8月18日 9:08
收件人: Kent Watsen<mailto:[email-masked]>; netmod<mailto:[email-masked]>
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

Hi all，

I have reviewed the latest version, my comments are addressed, I support adoption.

Best Regards,
Wei

From: Kent Watsen<mailto:[email-masked]>
Date: 2020-08-18 06:05
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
This email begins a 2-week adoption poll for:

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.

Netmod Chairs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Aug 2020 06:53:06 +0200

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

/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/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Aug 2020 12:10:11 -0700

Hi,

On Mon, Aug 17, 2020 at 9:53 PM Juergen Schoenwaelder <
[email-masked]> wrote:

> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-tao-netmod-yang-node-tags
> <

I am also against adoption.
This module introduces 9 extension-stmts that represent a huge
administrative burden for
module developers without any proven value.  It is not even clear that such
specific metadata
is even applicable to all instances of the tagged data node.  IMO it is not
likely that a single
metric will apply to all instances, all all times, in any
possible deployment scenario.

There are no standard operations or mechanisms to use module tags.
They have not demonstrated any standards value so far.

/js

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Lou Berger <[email-masked]>
Date: Sat, 29 Aug 2020 14:40:20 -0400

Hi,

A couple of comments:

- As a co-author or YANG Module Tags, I'm thrilled to see it being 
used/augmented by this document, but I'm not clear on how the metric and 
operation type tags are to be used.  To me these seem to be best defined 
by the modules themselves, e.g., does a value represent an average 
/sum/min/max value or the scale of the value, and not as tag meta 
data.   Similarly, the type of vpn supported by a tunnel also seems like 
module data and not tag meta data, as this is a per tunnel instance value.

While the work was previously presented to the WG, I know you didn't 
have the time we all hoped for to discuss this at the last session, so I 
(personally, not as chair) would like to ask you to explain this on the 
list prior to adoption.  I'm hoping I'm just missing something, but from 
the discussion with Juergen an Andy I suspect not.

- Since this work is derived from work that I contributed to, I'd be 
interested in hearing what new mechanism(s) is/are covered by the IPR 
disclosure prior to supporting WG adoption.  I'm not asking in order to 
debate this, as that is something for other venues, I'm merely asking 
that you state for the record what new mechanism is covered.

Thank you

Lou

(as WG contributor and co-author of draft-ietf-netmod-module-tags)