Re: [netmod] WGLC on node-tags-09

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 04 August 2023 18:56

The use case described in the document is that client A tags nodes and
client B consumes the tags, i.e., two management applications
coordinate their work via tags set on the server's data tree. I am not
sure who orchestrates management applications in this way but those
who do likely do not expect interoperability on the level of the tags
since there is likely additional behaviour implied by setting tags.

If the idea is to standardize general metric tags for documentation or
lookup purposes (or some other yet to be defined purposes), then what
may appear to be simple task may turn out to be much more complex once
you dive into the details what tags really mean. There is a large body
of work on metrics that has been done in the Benchmarking Methodology
WG (bmwg). Work aiming to define a registry of tags for metrics should
surely be reviewed by bmwg people. There is also RFC 8911 produced by
IPPM, which seems to overlap with this effort to define a metrics
registry. Perhaps the whole metrics registry work needs more thought
and cross WG review and it may make sense to move it to a separate
document.


Yes, it was RFC8911/RFC8912 that I had in mind

Tom Petch

/js

On Fri, Aug 04, 2023 at 04:13:50PM +, tom petch wrote:
> From: netmod  on behalf of Kent Watsen 
> 
> Sent: 19 April 2023 02:59
>
> This email begins a two-week WGLC on:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.  
> Favorable comments are especially welcomed.
> 
> I think that this is a bad idea.  It lacks a coherent taxonomy, a bit like 
> setting up a relational database without first considering what classes there 
> will be, what inheritance there is and so on.
>
> It seems to be an ad-hoc collection of categories that are of interest to the 
> authors and are likely to be meaningless in practice in the internet at 
> large.  It should look at what aspects of management it covers and then the 
> data related to each and the provide usable criteria to determine into which 
> category a data item falls.  This is substantial work, but then so is setting 
> up a usable relational database and I see enough of those where the thought 
> has not been put in on the underlying concepts, principles and so have proved 
> more of a hindrance than a help.
>
> Tom Petch
>
>
>
>
> This draft went through a WGLC a year ago.  The authors addressed the 
> comments received and have been were waiting for feedback.   In essence, this 
> draft is presumed to reflect WG consensus and thusly, if no objection is 
> received, the draft will move to the next step in the publication process.
>
> Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
>
> Kent  // co-chair
>
> ___
> 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

--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
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

Re: [netmod] WGLC on node-tags-09

[Jürgen Schönwälder]

The use case described in the document is that client A tags nodes and
client B consumes the tags, i.e., two management applications
coordinate their work via tags set on the server's data tree. I am not
sure who orchestrates management applications in this way but those
who do likely do not expect interoperability on the level of the tags
since there is likely additional behaviour implied by setting tags.

If the idea is to standardize general metric tags for documentation or
lookup purposes (or some other yet to be defined purposes), then what
may appear to be simple task may turn out to be much more complex once
you dive into the details what tags really mean. There is a large body
of work on metrics that has been done in the Benchmarking Methodology
WG (bmwg). Work aiming to define a registry of tags for metrics should
surely be reviewed by bmwg people. There is also RFC 8911 produced by
IPPM, which seems to overlap with this effort to define a metrics
registry. Perhaps the whole metrics registry work needs more thought
and cross WG review and it may make sense to move it to a separate
document.

/js

On Fri, Aug 04, 2023 at 04:13:50PM +, tom petch wrote:
> From: netmod  on behalf of Kent Watsen 
> 
> Sent: 19 April 2023 02:59
> 
> This email begins a two-week WGLC on:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
> 
> Please take time to review this draft and post comments by May 2nd.  
> Favorable comments are especially welcomed.
> 
> I think that this is a bad idea.  It lacks a coherent taxonomy, a bit like 
> setting up a relational database without first considering what classes there 
> will be, what inheritance there is and so on.
> 
> It seems to be an ad-hoc collection of categories that are of interest to the 
> authors and are likely to be meaningless in practice in the internet at 
> large.  It should look at what aspects of management it covers and then the 
> data related to each and the provide usable criteria to determine into which 
> category a data item falls.  This is substantial work, but then so is setting 
> up a usable relational database and I see enough of those where the thought 
> has not been put in on the underlying concepts, principles and so have proved 
> more of a hindrance than a help.
> 
> Tom Petch  
> 
> 
> 
> 
> This draft went through a WGLC a year ago.  The authors addressed the 
> comments received and have been were waiting for feedback.   In essence, this 
> draft is presumed to reflect WG consensus and thusly, if no objection is 
> received, the draft will move to the next step in the publication process.
> 
> Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
> 
> Kent  // co-chair
> 
> ___
> 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

-- 
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on node-tags-09

[tom petch]

From: netmod  on behalf of Kent Watsen 

Sent: 19 April 2023 02:59

This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.

I think that this is a bad idea.  It lacks a coherent taxonomy, a bit like 
setting up a relational database without first considering what classes there 
will be, what inheritance there is and so on.

It seems to be an ad-hoc collection of categories that are of interest to the 
authors and are likely to be meaningless in practice in the internet at large.  
It should look at what aspects of management it covers and then the data 
related to each and the provide usable criteria to determine into which 
category a data item falls.  This is substantial work, but then so is setting 
up a usable relational database and I see enough of those where the thought has 
not been put in on the underlying concepts, principles and so have proved more 
of a hindrance than a help.

Tom Petch  




This draft went through a WGLC a year ago.  The authors addressed the comments 
received and have been were waiting for feedback.   In essence, this draft is 
presumed to reflect WG consensus and thusly, if no objection is received, the 
draft will move to the next step in the publication process.

Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/

Kent  // co-chair

___
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

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

-邮件原件-
发件人: Lou Berger [mailto:lber...@labn.net] 
发送时间: 2023年7月24日 3:12
收件人: Qin Wu 
抄送: netmod@ietf.org; Andy Bierman 
主题: Re: [netmod] WGLC on node-tags-09

Authors,

I may have missed it, but was the point below addressed?

On 7/3/2023 2:23 PM, Andy Bierman wrote:
> YANG authors should not need to tag nodes with specific metrics at all.
> I am not convinced that standard tags like "counter," or "loss," or 
> "delay" are useful.
> IMO it would be better to keep standard tags in their own RFC(s), 
> especially something as complicated as metrics classification.

As contributor, I too have a hard time seeing the value of having tags that map 
directly to attributes such as  delay, jitter, and loss - I'd expect the tags 
to map to classes not instances of attributes.
[Qin]: Yes, it is mapped to classes rather than instance of attributes. I am 
leaning toward separating this out for simplicity reason.
 From a process perspective, can you explain why references in IETF tags, 
section 9.2, are not *normative*? (note some are not even lisyted in the 
references section.)
[Qin]: You are referred to openmetrics references, I can move it as normative 
reference but I am not sure one external document defined by open source 
community can be listed as normative reference.
 Correct me if I am wrong.
Thanks,

Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on node-tags-09

[Lou Berger]

Authors,

I may have missed it, but was the point below addressed?

On 7/3/2023 2:23 PM, Andy Bierman wrote:

YANG authors should not need to tag nodes with specific metrics at all.
I am not convinced that standard tags like "counter," or "loss," or 
"delay" are useful.

IMO it would be better to keep standard tags in their own RFC(s),
especially something as complicated as metrics classification.


As contributor, I too have a hard time seeing the value of having tags 
that map directly to attributes such as  delay, jitter, and loss - I'd 
expect the tags to map to classes not instances of attributes.


From a process perspective, can you explain why references in IETF 
tags, section 9.2, are not *normative*? (note some are not even lisyted 
in the references section.)


Thanks,

Lou

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

--

Apart from being able to deduce it from Section 4.3, it is not absolutely clear 
from Section 4 that the colon has special meaning. That is that all prefixes 
now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish an 
non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator, and 
change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect all registered prefixes to end 
with a colon.

[Qin Wu] That's really a good comment, so Tag = Tag prefix+ Tag Value, Colon is 
part of Tag prefix if you expect all registered prefix to end with a colon.
The question is whether we see colon as separator or portion of the tag prefix.
Do we need to make tag prefix is mandatory to have for a tag?

[AF] I don't really mind.
The closest to what you have is...
- Tag prefix is not mandatory
- All tag prefixes MUST end with a colon
- Colons MUST NOT be used within a prefix
- Colons SHOULD NOT be used in a tag value If you want to, you could specify a 
character to be used as a separator within prefixes and values (such as a 
period).

[Qin Wu-1] That's a good summary. I will incorporate some of these principles 
into the updated draft. In addition, I think Colons can be used within a tag 
value, "entno:vendor-defined-classifier" is one of examples used for vendor tag.

[AF2] Sounds good. 
The colon in a tag value is allowed by "SHOULD NOT", but I wanted to avoid the 
confusion between a tag value that does not use a prefix but contains a colon, 
and a tag that has a prefix and a value.
For example, ietf:foo should be a tag comprising the prefix ietf: and the value 
foo. But a non-prefixed tag could legitimately be ietf:foo. 
That example is a bit silly, but consider that someone makes a non-prefix tag 
iab:bah and deploys the code. Tomorrow the IETF decides that there should be a 
registered prefix iab: Now we have collisions.

[QW2]Your clarification makes sense, I think what we should first avoid is 3 
prefix we defined in this draft appear in the tag value, in addition, one rule 
we have already added is 
" this document is purposefully not specifying any structure on (i.e., 
restricting) the tag values.", do we need to add further restriction to limit 
"iab:" to be part of tag value.
Another choice is to we set rule that it is mandatory to have prefix for each 
data node tag. Is this too restrictive?

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

Briefly in line with [AF2]
Tl;dr  All is good.
Adrian

-Original Message-
From: Qin Wu  
Sent: 05 July 2023 05:14
To: adr...@olddog.co.uk; 'Kent Watsen' ; netmod@ietf.org
Subject: RE: [netmod] WGLC on node-tags-09

Hi, Adrian:
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk] 
发送时间: 2023年6月28日 23:25
收件人: Qin Wu ; 'Kent Watsen' ; 
netmod@ietf.org
主题: RE: [netmod] WGLC on node-tags-09

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity 
node-tag-type to capture the variants defined in the IANA registry shown in 
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of 
introducing node-tag-type identities is to address Jurgen's comment and try to 
make the node tag mechanism generic enough and allow future extension, we did 
provide an example in Appendix A which allow you add additional Auxiliary Data 
Property in the module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA registry, 
but node-tag-type identities will not be registered together with IETF YANG 
Data Node Tags. Secondly, we did use tag as a string, we choose to use the same 
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it doesn't 
allow any future module extension.
2. we keep some of these identities for second level data node classification, 
e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter 
,delay identities from this draft since it seems to  duplicate with what has 
already been defined in IANA registry, in addition, we remove some of IETF yang 
data node tags including summary, counter, gauge and unknown, which is 
redundant with identities  for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be 
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little more 
explanation?).
I think your option 1 would only work if we move the identities to a new module 
(possibly under IANA control - my option 3) Your option 2 looks worthy of 
consideration, but it is a big change at this stage in the process - I don't 
want to cause disruption to the WG process as I am not an implementer of this 
technology.
I wonder whether my options 1 and 2 wouldn't be simpler.

[Qin Wu-1] My proposal. Removing identityref type from YANG module is aimed at 
avoiding duplication with IETF node tag. In addition, I prefer to align with 
module tag RFC8819 for simplicity. The idea is to use YANG extension to provide 
extensibility,
I will update the draft to reflect this.

[AF2] Simplicity is good. Avoiding duplication is good. Aligning with published 
RFCs is good.

--

I think that Section 1, in introducing the concept of tags, should spend a 
sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG 
tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1 as 
follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just wondered 
about a quick description of what it does.
But I don't insist on this change.

[Qin Wu-1] Here is the proposed change to introduction section
OLD TEXT:
"
For the specific case of YANG data models, a module tag is defined as a string 
that is associated with a module name at the module level
"
NEW TEXT:
"
For the specific case of YANG data models, a module tag has already been 
defined as a string that is associated with a module name at the module level 
for YANG modules classification.
"

[AF2] OK

--

Apart from being able to deduce it from Section 4.3, it is not absolutely clear 
from Section 4 that the colon has special meaning. That is that all prefixes 
now and in the future are delimited by the colon.
(This is important because, absent a colon, 

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

发件人: Andy Bierman [mailto:a...@yumaworks.com]
发送时间: 2023年7月4日 2:24
收件人: Qin Wu 
抄送: Kent Watsen ; netmod@ietf.org
主题: Re: [netmod] WGLC on node-tags-09



On Mon, Jun 26, 2023 at 2:34 AM Qin Wu 
mailto:bill...@huawei.com>> wrote:
Andy:
Sorry for late followup, please see my reply inline below.

发件人: netmod [mailto:netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>] 代表 
Andy Bierman
发送时间: 2023年4月20日 2:39
收件人: Kent Watsen mailto:kent%2bi...@watsen.net>>
抄送: netmod@ietf.org<mailto:netmod@ietf.org>
主题: Re: [netmod] WGLC on node-tags-09



On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.

I have read the latest draft and IMO it needs more work.

1) metrics

The identities to represent system tags are quite vague.
There are no specific guidelines for selecting the correct tag.
There are no references to other RFCs for the metric definitions.
I would expect IPPM WG to define the classification system, not NETMOD WG.

[Qin Wu]
Good comment, the idea of introducing system tags is to classify the data nodes 
or data node instances and identify the characteristics
data or metric data. The identity is associated with ‘type’ leaf for specific 
data node or instance of data node and provides a second
level classification, e.g., we add a system tag for ‘in-octets’ leaf under 
interface list in ietf-interface.yang module, in addition,
we can add a type leaf with the value as ‘summary’ for the same leaf to 
indicate the leaf value is average value.
For packet loss, jitter, delay, similar to what ALTO performance metrics RFC 
(draft-ietf-alto-performance-metrics) is doing, we don’t
define any new metrics and we just reuse the same metrics defined in IPPM, we 
can add similar RFCs to packet loss, jitter, delay described
in this draft. Regarding summary, counter definition, I believe we should 
reference to openmetric draft described in
(https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00) 
which has already been open sourced and well specified and validated.
Regarding guidelines for selecting the correct tag, we did provide guideline 
for model writer to define system tags at the design time,
but similar to what module tag is doing, we will leave freedom to the client to 
decide whether the correct tag is selected.

One more thing I want to clarify is I think identity used to describe the type 
of data node should be limited to summary, counter, unknown,
gauge, etc, the packet loss, delay identities can be removed.



YANG authors should not need to tag nodes with specific metrics at all.
I am not convinced that standard tags like "counter," or "loss," or "delay" are 
useful.
IMO it would be better to keep standard tags in their own RFC(s),
especially something as complicated as metrics classification.


[Qin] We could tag nodes at metrics top level, e.g., we simply classify nodes 
based on FACPS categories, we could also simply identify which nodes are 
texture information which will not change, e.g., software revision, hardware 
revision, or which nodes represent a snapshot of the current state for a set of 
data, not go into specific metrics level (e.g., loss).
but specific metrics provide more fine granularity information.
I think these specific metrics allow you easily collect and correlate the data 
from different data sources, represent them consistently in different 
dimension, whether it is standard module or vendor specific module, e.g.,
data node 1 of vendor A module and data node 2 of vendor B module are defined 
differently, but used to capture data from the similiar data source with the 
same metric type.


2) System tag procedures

There are no procedures defined for YANG model developers.

[Qin Wu] See section 8 for guidelines for YANG model developers.

Are they supposed to add a node-tag extension to almost every leaf in the 
module?
[Qin Wu] The answer is no, we only add node tag extension to characteristics 
data
Related leaf, e.g., leaf used to describe the metric data, e.g., the number of 
inbound
packets that contained errors.


This seems like a huge administrative burden with minimal guidance provided.

[Qin] Comparing with adding node-tag extension to every leaf in the module, 
this design saves the cost. We do provide guidance on which nodes should be
tagged, which nodes should not be tagged (e.g., notification, action), see last 
paragraph of section 9.2, yes, more text is required to add based on your 
comments raised earlier.

Andy


The administration and maintenance of node-tags will be a huge burden.
That was one reason they were not added to the module-tags module in the first 
place.

The YANG extension itself is under-specified since it off

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

Hi, Adrian:
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk] 
发送时间: 2023年6月28日 23:25
收件人: Qin Wu ; 'Kent Watsen' ; 
netmod@ietf.org
主题: RE: [netmod] WGLC on node-tags-09

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity 
node-tag-type to capture the variants defined in the IANA registry shown in 
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of 
introducing node-tag-type identities is to address Jurgen's comment and try to 
make the node tag mechanism generic enough and allow future extension, we did 
provide an example in Appendix A which allow you add additional Auxiliary Data 
Property in the module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA registry, 
but node-tag-type identities will not be registered together with IETF YANG 
Data Node Tags. Secondly, we did use tag as a string, we choose to use the same 
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it doesn't 
allow any future module extension.
2. we keep some of these identities for second level data node classification, 
e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter 
,delay identities from this draft since it seems to  duplicate with what has 
already been defined in IANA registry, in addition, we remove some of IETF yang 
data node tags including summary, counter, gauge and unknown, which is 
redundant with identities  for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be 
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little more 
explanation?).
I think your option 1 would only work if we move the identities to a new module 
(possibly under IANA control - my option 3) Your option 2 looks worthy of 
consideration, but it is a big change at this stage in the process - I don't 
want to cause disruption to the WG process as I am not an implementer of this 
technology.
I wonder whether my options 1 and 2 wouldn't be simpler.
[Qin Wu-1] My proposal. Removing identityref type from YANG module is aimed at 
avoiding duplication with IETF node tag. In addition, I prefer to align with 
module tag RFC8819 for simplicity. The idea is to use YANG extension to provide 
extensibility,
I will update the draft to reflect this.
--

I think that Section 1, in introducing the concept of tags, should spend a 
sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG 
tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1 as 
follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just wondered 
about a quick description of what it does.
But I don't insist on this change.

[Qin Wu-1] Here is the proposed change to introduction section
OLD TEXT:
"
For the specific case of YANG data models, a module tag is defined as a string 
that is associated with a module name at the module level
"
NEW TEXT:
"
For the specific case of YANG data models, a module tag has already been 
defined as a string that is associated with a module name at the module level 
for YANG modules classification.
"
--

Apart from being able to deduce it from Section 4.3, it is not absolutely clear 
from Section 4 that the colon has special meaning. That is that all prefixes 
now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish an 
non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg

Re: [netmod] WGLC on node-tags-09

[Andy Bierman]

On Mon, Jun 26, 2023 at 2:34 AM Qin Wu  wrote:

> Andy:
>
> Sorry for late followup, please see my reply inline below.
>
>
>
> *发件人:* netmod [mailto:netmod-boun...@ietf.org] *代表 *Andy Bierman
> *发送时间:* 2023年4月20日 2:39
> *收件人:* Kent Watsen 
> *抄送:* netmod@ietf.org
> *主题:* Re: [netmod] WGLC on node-tags-09
>
>
>
>
>
>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:
>
> This email begins a two-week WGLC on:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.
> Favorable comments are especially welcomed.
>
>
>
> I have read the latest draft and IMO it needs more work.
>
>
>
> 1) metrics
>
>
>
> The identities to represent system tags are quite vague.
>
> There are no specific guidelines for selecting the correct tag.
>
> There are no references to other RFCs for the metric definitions.
>
> I would expect IPPM WG to define the classification system, not NETMOD WG.
>
>
>
> [Qin Wu]
>
> Good comment, the idea of introducing system tags is to classify the data
> nodes or data node instances and identify the characteristics
>
> data or metric data. The identity is associated with ‘type’ leaf for
> specific data node or instance of data node and provides a second
>
> level classification, e.g., we add a system tag for ‘in-octets’ leaf under
> interface list in ietf-interface.yang module, in addition,
>
> we can add a type leaf with the value as ‘summary’ for the same leaf to
> indicate the leaf value is average value.
>
> For packet loss, jitter, delay, similar to what ALTO performance metrics
> RFC (draft-ietf-alto-performance-metrics) is doing, we don’t
>
> define any new metrics and we just reuse the same metrics defined in IPPM,
> we can add similar RFCs to packet loss, jitter, delay described
>
> in this draft. Regarding summary, counter definition, I believe we should
> reference to openmetric draft described in
>
> (https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00)
> which has already been open sourced and well specified and validated.
>
> Regarding guidelines for selecting the correct tag, we did provide
> guideline for model writer to define system tags at the design time,
>
> but similar to what module tag is doing, we will leave freedom to the
> client to decide whether the correct tag is selected.
>
>
>
> One more thing I want to clarify is I think identity used to describe the
> type of data node should be limited to summary, counter, unknown,
>
> gauge, etc, the packet loss, delay identities can be removed.
>
>
>


YANG authors should not need to tag nodes with specific metrics at all.
I am not convinced that standard tags like "counter," or "loss," or "delay"
are useful.
IMO it would be better to keep standard tags in their own RFC(s),
especially something as complicated as metrics classification.




>
> 2) System tag procedures
>
>
>
> There are no procedures defined for YANG model developers.
>
>
>
> [Qin Wu] See section 8 for guidelines for YANG model developers.
>
>
>
> Are they supposed to add a node-tag extension to almost every leaf in the
> module?
>
> [Qin Wu] The answer is no, we only add node tag extension to
> characteristics data
>
> Related leaf, e.g., leaf used to describe the metric data, e.g., the
> number of inbound
>
> packets that contained errors.
>
>
>

This seems like a huge administrative burden with minimal guidance provided.



Andy



> The administration and maintenance of node-tags will be a huge burden.
>
> That was one reason they were not added to the module-tags module in the
> first place.
>
>
>
> The YANG extension itself is under-specified since it offers no guidance on
>
> which YANG statements are allowed to have this extension as a
> sub-statement.
>
>
>
> [Qin Wu] See last paragraph of section 9.2
>
> “
>
>A data node can contain one or multiple node tags.Data node to be
>
>tagged with the initial value in Table 2 can be one of 'container',
>
>'leaf-list', 'list', or 'leaf' data node.  All tag values described
>
>in Table 2 can be inherited down the containment hierarchy if Data
>
>nodes tagged with those tag values is one of 'container', 'leaf-
>
>list', 'list'.
>
>
>
> ”
>
> Note that we don’t allow add system tag to notification or action
> statement. We can make this clear in the updated text.
>
>
>
> IMO all the metrics (tag type identities) should be removed from this
> document and moved to separate work
>
>

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown in
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of
introducing
node-tag-type identities is to address Jurgen's comment and try to make the
node tag mechanism 
generic enough and allow future extension, we did provide an example in
Appendix A which allow you add additional Auxiliary Data Property in the
module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA
registry, but 
node-tag-type identities will not be registered together with IETF YANG Data
Node Tags. Secondly, we did use tag as a string, we choose to use the same
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it
doesn't allow any future module extension.
2. we keep some of these identities for second level data node
classification, e.g., summary, counter, gauge, unknown, etc but remove
packet loss ,jitter ,delay identities from this draft since it seems to
 duplicate with what has already been defined in IANA registry, in addition,
we remove some of IETF yang data node tags including summary, counter, gauge
and unknown, which is redundant with identities
 for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little
more explanation?).
I think your option 1 would only work if we move the identities to a new
module (possibly under IANA control - my option 3)
Your option 2 looks worthy of consideration, but it is a big change at this
stage in the process - I don't want to cause disruption to the WG process as
I am not an implementer of this technology.
I wonder whether my options 1 and 2 wouldn't be simpler.

--

I think that Section 1, in introducing the concept of tags, should spend a
sentence describing YANG Module Tags [RFC8819] so that we can see how the
YANG tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1
as follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just
wondered about a quick description of what it does.
But I don't insist on this change.

--

Apart from being able to deduce it from Section 4.3, it is not absolutely
clear from Section 4 that the colon has special meaning. That is that all
prefixes now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish
an non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator,
and change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect all registered prefixes to end
with a colon.

[Qin Wu] That's really a good comment, so Tag = Tag prefix+ Tag Value,
Colon is part of Tag prefix if you expect all registered prefix to end with
a colon.
The question is whether we see colon as separator or portion of the tag
prefix.
Do we need to make tag prefix is mandatory to have for a tag?

[AF] I don't really mind.
The closest to what you have is...

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

Hi, Adrian:

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Adrian Farrel
发送时间: 2023年4月26日 6:10
收件人: 'Kent Watsen' ; netmod@ietf.org
主题: Re: [netmod] WGLC on node-tags-09

Hi,

I have reviewed this draft during the normal working group process, and I just 
re-read it as part of working group last call. I believe the function defined 
is useful, and
 I think the draft is ready to advance towards publication once my list of 
small points have been addressed.

Cheers,
Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity 
node-tag-type to capture the variants defined in the IANA registry shown in 
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of 
introducing
node-tag-type identities is to address Jurgen’s comment and try to make the 
node tag mechanism 
generic enough and allow future extension, we did provide an example in 
Appendix A which allow you add additional Auxiliary Data Property in the module 
extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA registry, 
but 
node-tag-type identities will not be registered together with IETF YANG Data 
Node Tags. Secondly, we did use tag as a string, we choose to use the same 
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it doesn’t 
allow any future module extension.
2. we keep some of these identities for second level data node classification, 
e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter 
,delay identities from this draft since it seems to
 duplicate with what has already been defined in IANA registry, in addition, we 
remove some of IETF yang data node tags including summary, counter, gauge and 
unknown, which is redundant with identities
 for second level data node classification.

== Minor ==

idnits reports some minor issues...

  ** There are 4 instances of too long lines in the document, the longest one
 being 7 characters in excess of 72.

  == Unused Reference: 'RFC6022' is defined on line 834, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8641' is defined on line 871, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC9195' is defined on line 880, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC9196' is defined on line 884, but no explicit
 reference was found in the text

[Qin Wu] Fixed, thanks
--

I think that Section 1, in introducing the concept of tags, should spend a 
sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG 
tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1 as 
follows:
“
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
”
--

Apart from being able to deduce it from Section 4.3, it is not absolutely clear 
from Section 4 that the colon has special meaning. That is that all prefixes 
now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish an 
non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator, and 
change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

Hi

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Andy Bierman
发送时间: 2023年4月20日 4:22
收件人: Kent Watsen 
抄送: netmod@ietf.org
主题: Re: [netmod] WGLC on node-tags-09

Hi,

Adding a couple missed comments inline...

On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman 
mailto:a...@yumaworks.com>> wrote:


On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.

I have read the latest draft and IMO it needs more work.

1) metrics

The identities to represent system tags are quite vague.
There are no specific guidelines for selecting the correct tag.
There are no references to other RFCs for the metric definitions.
I would expect IPPM WG to define the classification system, not NETMOD WG.

2) System tag procedures

There are no procedures defined for YANG model developers.
Are they supposed to add a node-tag extension to almost every leaf in the 
module?
The administration and maintenance of node-tags will be a huge burden.
That was one reason they were not added to the module-tags module in the first 
place.

The YANG extension itself is under-specified since it offers no guidance on
which YANG statements are allowed to have this extension as a sub-statement.


There is no way to specify the 'type' property using this extension.
There is no way to report this value in  for system entries.
The "standard" tags (e.g. "ietf:loss" have no formal linkage to the identity 
'loss' in the module.
It is not clear what value the 'type' identityref leaf provides at all.

[Qin Wu] One of reason to introduce ‘type’identityref leaf is to based on 
Jurgen’s comment and make the node tag
generic enough to apply all possible scenarios. As I clarified earlier, I think 
'type' identityref leaf provide a second
level classification and further can indicate what metric type we are using, 
the metric type is well specified in
section 3.2 of draft-richih-opsawg-openmetrics-00.

In addition, ‘type’ identityref leaf is an optional leaf, it can be ignored if 
it doesn’t need.

IMO all the metrics (tag type identities) should be removed from this document 
and moved to separate work
that is properly defined using IPPM metrics.

3) YANG module issues

- what module entry is used if the node is from a module that augments another 
one?
   I would assume the augmented module not the base module.  Specify which one

-  nacm:node-instance-identifier as a list key is complex to implement
   - not sure a canonical representation is possible or required
   - syntax allows notification and action nodes to be tagged. Are these 
allowed in thislist?


There is no canonical form possible for an instance-identifier.
Yet this module MUST define the procedures for storing and comparing 2 
instances of this key leaf.
[Qin Wu] I am wondering whether adding one more leaf as a new key leaf is a 
better choice.
The new leaf is string type and need to be global unique.

The draft says RESTCONF is supported.  It should also say that JSON is not 
supported
since the instance-identifier data type is used in a configuration data node.

IMO the instance-identifier encoding in RFC 7951 is a much better choice.
E.g., make a NACM schema-node-identifier typedef based on 7951, not 7950.

BTW, the same problem also exists if a list key is type identityref.
The encoding in 7951 is a better choice here as well.

[Qin Wu] Do you suggest we should use instance-identifier instead of 
nacm:node-instance-identifier
For list key? How instance-identifier can represent both data node and instance 
of data node?

Sec 4.3:

Any tag with the prefix "user:" is a user tag. Furthermore, any tag that 
does not contain a colon
(":", i.e., has no prefix) is also a user tag. Users are not required to 
use the "user:" prefix; however,
doing so is RECOMMENDED.

How does this text impact the key leaf 'tag' in the YANG module?
Do the key leaf values "user:foo" and "foo" match or not?
If yes, there needs to be a canonical format . If no, then not a good design.

[Qin Wu] I think it is the former, whether you enter “user:foo” or “foo”, they 
are equivalent,
I think both should be stored as “user:foo”, in other words, if we enter “foo”, 
it will be automatically
add “user:” before “foo” and store consistently, is this what you are looking 
for?


Andy

-  it is possible for multiple 'tags' entries to represent the same data node 
instances.
   Figuring out precedence and enforcing masked-tag rules seems complicated.
   NACM has ordered by-user semantics.  This module has "all entries at once" 
semantics.
   Not that easy to implement or deploy.

- What if a tag value appears in the masked-tag leaf-list that has the same 
value as the 'tag' key le

Re: [netmod] WGLC on node-tags-09

[Qin Wu]

Andy:
Sorry for late followup, please see my reply inline below.

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Andy Bierman
发送时间: 2023年4月20日 2:39
收件人: Kent Watsen 
抄送: netmod@ietf.org
主题: Re: [netmod] WGLC on node-tags-09



On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.

I have read the latest draft and IMO it needs more work.

1) metrics

The identities to represent system tags are quite vague.
There are no specific guidelines for selecting the correct tag.
There are no references to other RFCs for the metric definitions.
I would expect IPPM WG to define the classification system, not NETMOD WG.

[Qin Wu]
Good comment, the idea of introducing system tags is to classify the data nodes 
or data node instances and identify the characteristics
data or metric data. The identity is associated with ‘type’ leaf for specific 
data node or instance of data node and provides a second
level classification, e.g., we add a system tag for ‘in-octets’ leaf under 
interface list in ietf-interface.yang module, in addition,
we can add a type leaf with the value as ‘summary’ for the same leaf to 
indicate the leaf value is average value.
For packet loss, jitter, delay, similar to what ALTO performance metrics RFC 
(draft-ietf-alto-performance-metrics) is doing, we don’t
define any new metrics and we just reuse the same metrics defined in IPPM, we 
can add similar RFCs to packet loss, jitter, delay described
in this draft. Regarding summary, counter definition, I believe we should 
reference to openmetric draft described in
(https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00) 
which has already been open sourced and well specified and validated.
Regarding guidelines for selecting the correct tag, we did provide guideline 
for model writer to define system tags at the design time,
but similar to what module tag is doing, we will leave freedom to the client to 
decide whether the correct tag is selected.

One more thing I want to clarify is I think identity used to describe the type 
of data node should be limited to summary, counter, unknown,
gauge, etc, the packet loss, delay identities can be removed.


2) System tag procedures

There are no procedures defined for YANG model developers.

[Qin Wu] See section 8 for guidelines for YANG model developers.

Are they supposed to add a node-tag extension to almost every leaf in the 
module?
[Qin Wu] The answer is no, we only add node tag extension to characteristics 
data
Related leaf, e.g., leaf used to describe the metric data, e.g., the number of 
inbound
packets that contained errors.

The administration and maintenance of node-tags will be a huge burden.
That was one reason they were not added to the module-tags module in the first 
place.

The YANG extension itself is under-specified since it offers no guidance on
which YANG statements are allowed to have this extension as a sub-statement.

[Qin Wu] See last paragraph of section 9.2
“
   A data node can contain one or multiple node tags.Data node to be
   tagged with the initial value in Table 2 can be one of 'container',
   'leaf-list', 'list', or 'leaf' data node.  All tag values described
   in Table 2 can be inherited down the containment hierarchy if Data
   nodes tagged with those tag values is one of 'container', 'leaf-
   list', 'list'.

”
Note that we don’t allow add system tag to notification or action statement. We 
can make this clear in the updated text.

IMO all the metrics (tag type identities) should be removed from this document 
and moved to separate work
that is properly defined using IPPM metrics.

3) YANG module issues

- what module entry is used if the node is from a module that augments another 
one?
   I would assume the augmented module not the base module.  Specify which one

[Qin Wu]
As you can see, ietf-node-tags module augments from module list within 
ietf-module-tag module, the module entry will be
decided by the name key leaf under module list
   module: ietf-module-tags
 +--rw module-tags
+--rw module* [name]
   +--rw name  yang:yang-identifier

-  nacm:node-instance-identifier as a list key is complex to implement
[Qin Wu] The reason to select nacm:node-instance-identifier as a list key is to 
represent both data node and instance of
data node, any other choice we can make?

   - not sure a canonical representation is possible or required
   - syntax allows notification and action nodes to be tagged. Are these 
allowed in thislist?
[Qin Wu]: See above, the answer is no.

-  it is possible for multiple 'tags' entries to represent the same data node 
instances.
   Figuring out precedence and enforcing masked-tag rules seems complicated.
   NACM has o

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

--


8.1 is intended as a new section of RFC 8407 so I think it should be 
possible to read it like that. I suggest re-writing as follows.
Note:
- Leaving out the figure number to be consistent with RFC 8407
- Making the reference to Section 9.2 point to this document explicitly

8.1.  Define Standard Tags

   A module MAY indicate, using node tag extension statements, a set of
   node tags that are to be automatically associated with nodes within
   the module (i.e., not added through configuration).  For example:

   module example-module-A {
 //...
 import ietf-node-tags { prefix ntags; }

 container top {
   list X {
 leaf foo {
ntags:node-tag "ietf:summary";
 }
 leaf bar {
   ntags:node-tag "ietf:loss";
 }
   }
 }
 // ...
   }

   The module writer can use existing standard node tags, or use new
   node tags defined in the data node definition, as appropriate.  For
   IETF standardized modules, new node tags MUST be assigned in the IANA
   registry defined in Section 9.2 of RFC .

---

9.2

Since you want the DE to look at this, I think you need:

OLD
   The allocation policy for this subregistry is IETF Review [RFC8126].
NEW
   The allocation policy for this subregistry is IETF Review with Expert
   Review [RFC8126].
END

--

11.

I think 5198 is a normative reference as you require ietf: tags to 
comply.

== Nits ==

Section 1

   This document defines tags for both nodes in the schema tree and
   instance nodes in the data tree and shows how they can be associated
   with nodes within a YANG module, which:

   *  Provide dictionary meaning for specific targeted data nodes;
   ...

Slightly confusing. I think the bullets are intended to apply to the
tags. I.e., the tags provide dictionary meaning...
But the text reads like it is the nodes (or possibly the YANG module)
which provides the meaning.
So possibly you need:

   This document defines tags for both nodes in the schema tree and
   instance nodes in the data tree, and shows how the tags can be
   associated with nodes within a YANG module, to:

   *  Provide dictionary meaning for specific targeted data nodes;
   ...

--

1.

OLD
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
NEW
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to which add node tags or from which to remove node tags, as
   well as a way to view the set of node tags associated with specific
   data nodes or instance of data nodes within YANG modules.

--

3.

s/data nodes repositories/data node repositories/

--

4.

   Initially, three prefixes are defined.

Maybe...

   Three prefixes are defined in the subsections that follow.

--

6.1

s/is as follows/as shown in Figure 1/

--

7.

s/"RFC 8819: YANG Module Tags ";/"RFC 8819: YANG Module Tags";/

--

8.1

s/associated with node/associated with nodes/

--

9.2 

Figure 4 has some text alignment issues

--

9.2

OLD
   A data node can contain one or multiple node tags.Data node to be
   tagged with the initial value in Table 2 can be one of 'container',
   'leaf-list', 'list', or 'leaf' data node.  All tag values described
   in Table 2 can be inherited down the containment hierarchy if Data
   nodes tagged with those tag values is one of 'container', 'leaf-
   list', 'list'.
NEW
   A data node can contain one or multiple node tags.  A data node to be
   tagged with an initial value from Table 2 can be one of 'container',
   'leaf-list', 'list', or 'leaf'.  All tag values described in Table 2
   can be inherited down the containment hierarchy if the data nodes
   tagged with those tag values is one of 'container', 'leaf-list', or 
   'list'.
END

--

11.

s/Berger,Jaehoon/Berger, Jaehoon/

== Petty comments ==

Section 1

"fairly ubiquitous"
Ubiquitous is an absolute state. You cannot be "somewhat pregnant" or
"slightly dead".

You probably want "widespread" or "used extensively".

--

3.

   The following lists a set of use cases to illustrate the use of node
   tags.

It's not really a list. It's OK that it is not many examples, but the 
text implies we might be going to see a few. How about:

   The following describes some use cases to illustrate the use of node
   tags.

--

9.2

Why does "IETF Node Tags" have a capital 'N' when "YANG node Tag" and 
"YANG node Tag Prefixes" use a lower case 'n'?

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 19 April 2023 03:00
To: netmod@ietf.org
Subject: [netmod] WGLC on node-tags-09

This email begins a two

Re: [netmod] WGLC on node-tags-09

[Andy Bierman]

Hi,

Adding a couple missed comments inline...

On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman  wrote:

>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:
>
>> This email begins a two-week WGLC on:
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>>
>> Please take time to review this draft and post comments by May 2nd.
>> Favorable comments are especially welcomed.
>>
>>
> I have read the latest draft and IMO it needs more work.
>
> 1) metrics
>
> The identities to represent system tags are quite vague.
> There are no specific guidelines for selecting the correct tag.
> There are no references to other RFCs for the metric definitions.
> I would expect IPPM WG to define the classification system, not NETMOD WG.
>
> 2) System tag procedures
>
> There are no procedures defined for YANG model developers.
> Are they supposed to add a node-tag extension to almost every leaf in the
> module?
> The administration and maintenance of node-tags will be a huge burden.
> That was one reason they were not added to the module-tags module in the
> first place.
>
> The YANG extension itself is under-specified since it offers no guidance on
> which YANG statements are allowed to have this extension as a
> sub-statement.
>
>
There is no way to specify the 'type' property using this extension.
There is no way to report this value in  for system entries.
The "standard" tags (e.g. "ietf:loss" have no formal linkage to the
identity 'loss' in the module.
It is not clear what value the 'type' identityref leaf provides at all.

IMO all the metrics (tag type identities) should be removed from this
> document and moved to separate work
> that is properly defined using IPPM metrics.
>
> 3) YANG module issues
>
> - what module entry is used if the node is from a module that augments
> another one?
>I would assume the augmented module not the base module.  Specify which
> one
>
> -  nacm:node-instance-identifier as a list key is complex to implement
>- not sure a canonical representation is possible or required
>- syntax allows notification and action nodes to be tagged. Are these
> allowed in thislist?
>
>

There is no canonical form possible for an instance-identifier.
Yet this module MUST define the procedures for storing and comparing 2
instances of this key leaf.
The draft says RESTCONF is supported.  It should also say that JSON is not
supported
since the instance-identifier data type is used in a configuration data
node.

IMO the instance-identifier encoding in RFC 7951 is a much better choice.
E.g., make a NACM schema-node-identifier typedef based on 7951, not 7950.

BTW, the same problem also exists if a list key is type identityref.
The encoding in 7951 is a better choice here as well.

Sec 4.3:

Any tag with the prefix "user:" is a user tag. Furthermore, any tag
that does not contain a colon
(":", i.e., has no prefix) is also a user tag. Users are not required
to use the "user:" prefix; however,
doing so is RECOMMENDED.


How does this text impact the key leaf 'tag' in the YANG module?
Do the key leaf values "user:foo" and "foo" match or not?
If yes, there needs to be a canonical format . If no, then not a good
design.


Andy

-  it is possible for multiple 'tags' entries to represent the same data
> node instances.
>Figuring out precedence and enforcing masked-tag rules seems
> complicated.
>NACM has ordered by-user semantics.  This module has "all entries at
> once" semantics.
>Not that easy to implement or deploy.
>
> - What if a tag value appears in the masked-tag leaf-list that has the
> same value as the 'tag' key leaf?
>
> - the indentation in the YANG module is wrong for masked-tag
>
> - the list and key naming (tags/tag) is not consistent with other IETF
> modules .
>   Maybe should be list tag and key leaf id.
>
>
>
> Andy
>
>
>
>> This draft went through a WGLC a year ago.  The authors addressed the
>> comments received and have been were waiting for feedback.   In essence,
>> this draft is presumed to reflect WG consensus and thusly, if no objection
>> is received, the draft will move to the next step in the publication
>> process.
>>
>> Ref:
>> https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
>>
>> Kent  // co-chair
>>
>> ___
>> 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

Re: [netmod] WGLC on node-tags-09

[Andy Bierman]

On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen  wrote:

> This email begins a two-week WGLC on:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
>
> Please take time to review this draft and post comments by May 2nd.
> Favorable comments are especially welcomed.
>
>
I have read the latest draft and IMO it needs more work.

1) metrics

The identities to represent system tags are quite vague.
There are no specific guidelines for selecting the correct tag.
There are no references to other RFCs for the metric definitions.
I would expect IPPM WG to define the classification system, not NETMOD WG.

2) System tag procedures

There are no procedures defined for YANG model developers.
Are they supposed to add a node-tag extension to almost every leaf in the
module?
The administration and maintenance of node-tags will be a huge burden.
That was one reason they were not added to the module-tags module in the
first place.

The YANG extension itself is under-specified since it offers no guidance on
which YANG statements are allowed to have this extension as a sub-statement.

IMO all the metrics (tag type identities) should be removed from this
document and moved to separate work
that is properly defined using IPPM metrics.

3) YANG module issues

- what module entry is used if the node is from a module that augments
another one?
   I would assume the augmented module not the base module.  Specify which
one

-  nacm:node-instance-identifier as a list key is complex to implement
   - not sure a canonical representation is possible or required
   - syntax allows notification and action nodes to be tagged. Are these
allowed in thislist?

-  it is possible for multiple 'tags' entries to represent the same data
node instances.
   Figuring out precedence and enforcing masked-tag rules seems complicated.
   NACM has ordered by-user semantics.  This module has "all entries at
once" semantics.
   Not that easy to implement or deploy.

- What if a tag value appears in the masked-tag leaf-list that has the same
value as the 'tag' key leaf?

- the indentation in the YANG module is wrong for masked-tag

- the list and key naming (tags/tag) is not consistent with other IETF
modules .
  Maybe should be list tag and key leaf id.



Andy



> This draft went through a WGLC a year ago.  The authors addressed the
> comments received and have been were waiting for feedback.   In essence,
> this draft is presumed to reflect WG consensus and thusly, if no objection
> is received, the draft will move to the next step in the publication
> process.
>
> Ref:
> https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
>
> Kent  // co-chair
>
> ___
> 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

[netmod] WGLC on node-tags-09

[Kent Watsen]

This email begins a two-week WGLC on:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09

Please take time to review this draft and post comments by May 2nd.  Favorable 
comments are especially welcomed.  

This draft went through a WGLC a year ago.  The authors addressed the comments 
received and have been were waiting for feedback.   In essence, this draft is 
presumed to reflect WG consensus and thusly, if no objection is received, the 
draft will move to the next step in the publication process.

Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/

Kent  // co-chair 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod