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

From: Qin Wu <[email-masked]>
Date: Sun, 30 Aug 2020 10:40:36 +0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2020年8月30日 18:05
收件人: Qin Wu <[email-masked]>
抄送: Lou Berger <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]; [email-masked]
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

On Sun, Aug 30, 2020 at 09:00:46AM +0000, Qin Wu wrote:
> 
> Regarding operation type tag, take ietf-interfaces in RFC8343 as an 
> example, ietf-interfaces include interface statistics data object 
> which can be seen as performance metric related data objects,

[...]

> however these statistics doesn't tell you whether in-errors is current 
> value or average value or total value,

Wrong. The semantics of the counter types provided by ietf-yang-types are well defined.

[Qin]: I agree counter types in ietf-yang-types are well defined. 
If counter types can help distinguish avg value from min, max, sum value, current value, I am
happy to adopt it, however I fail to see ietf-yang-types can do that and I don't think distinguishing avg from min,max etc 
is the job of ietf-yang-types. It add complexity if going with that direction, in my understanding.

In addition, operation type tag is an optional tag, not all the performance metrics data object need to define such tags.
> so does count related data objects defined in ietf-dhcpv6-server of 
> draft-ietf-dhc-dhcpv6-yang

[...]

These leafs are poorly defined and I expact that this will be fixed before publication. (Standards for counters are relatively useless if everybody implements different counters.)

/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: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 30 Aug 2020 12:51:49 +0200

> is the job of ietf-yang-types. It add complexity if going with that direction, in my understanding.

You miss my point: The specification of a leaf needs to be clear what
it is. If it is not clear, then the specification is buggy.

/js