Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

Dear Qiufang,

I did not ask for an extended-tag-type. I do not think you really
understood my concerns. I do not understand the whole object,
property, metric business nor has my question how this relates to the
NETCONF I-D providing another meta-data retrieval mechanism been
answered. There are authors who are on both documents so someone
should have an answer hy we need multiple mechanisms.

We should focus on a generic mechanism to convey meta-information and
not confuse that with the semantics of the different kinds of tags.  I
am looking for a generic mechanims that can be used for A, B, and C
instead of a solution for A, a different solution for B, and yet
another for C.

/js

On Fri, Apr 29, 2022 at 10:35:42AM +, Qin Wu wrote:
> Hi, Qiufang:
> First, the metric-tag defined in this draft allow you add more metric-tag 
> values in the metric-tag subregistry. See usage example in the Appendix B.
> To make the data node tags module even more extensible, I think adding one 
> leaf in the type of enumeration is still limited,
> a. the enumeration type is not extensible and doesn't allow you add new 
> enumeration values.
> b. how do you introduce other auxiliary data associated with new introduced 
> tag type, therefore here is my proposal:
> module: ietf-data-node-tags
> augment /tags:module-tags/tags:module:
>   +--rw data-node-tags
>  +--rw data-node* [ni-id]
> +--rw ni-idnacm:node-instance-identifier
> +--rw tag* tags:tag
> +--rw masked-tag*  tags:tag  
> +--rw extended-tag-type?   identityref 
> As you can see, we introduce extended-tag-type in the base module,
> which allows you further add auxiliary data in the extension to the base 
> module, see Appendix A for example.
> See more details in v-07
> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/
> 
> -Qin
> -邮件原件-
> 发件人: maqiufang (A) 
> 发送时间: 2022年4月13日 19:19
> 收件人: Jürgen Schönwälder ; Qin Wu 
> 
> 抄送: netmod@ietf.org
> 主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> Hi, Juergen, Qin
> How about defining a more general mechanism to cover your proposal:
>   module: ietf-data-node-tags
>   augment /tags:module-tags/tags:module:
> +--rw data-object-tags
>+--rw data-node* [ni-id]
>   +--rw ni-id  nacm:node-instance-identifier
>   +--rw tag-list* [tag]
>   |  +--rw tagtags:tag
>   |  +--rw value?  enumeration
>   +--rw masked-tag*   tags:tag
> So that the users can define any tag(e.g., corresponding-mib-oid, 
> related-node...) they’re interested in and the corresponding value(if any).
> 
> Best Regards,
> Qiufang
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder
> Sent: Wednesday, April 13, 2022 2:37 PM
> To: Qin Wu 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> Hi,
> 
> I believe the NETMOD WG should work out a single mechanism to convey 
> metadata. I see no value in developing N use case specific mechanisms spread 
> over several WGs. If this document is not aiming to provide a generic 
> solution, then I believe it should not be published.
> 
> /js
> 
> On Tue, Apr 12, 2022 at 03:27:03PM +, Qin Wu wrote:
> > Hi, Jurgen:
> > I understand your comment, is to investigate more use cases and see how one 
> > mechanism can be generalized to cover more use cases.
> > But the idea of this draft is to capture characteristics data (e.g., KPI 
> > data ) using data node tag. Data node tag module can only convey enumerated 
> > tag valued defined in section 9.2, that is why Balazs clarify the essence 
> > of data nod tag are not metadata based on RFC7950 but data properties.
> > 
> > I did investigate meta-data-collection draft. I think meta-data 
> > collection draft extends from ietf-system-capabilities module defined in 
> > RFC9196 while draft-ietf-netmod-node-tags-06 extends from ietf-module-tags 
> > defined in RFC8819 I believe observable-period related parameter in 
> > metadata-collection module is not suited to be redefined in Data node tag 
> > module since they are really system capability related parameters.
> > For three other parameters such as corresponding-mib-oid, related-node, 
> > optimized-measurement-point, not every data node has these three 
> > parameters, the value of corresponding-mib-oid, related-node can be any 
> > value it is hard to be listed as tag values, for 
> > optimized-measutement-point, it is empty type, it seem to fine, but add 
> > corresponding-mib-oid, related-node make data node tag module design very 
> > ugly, also t

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Balazs:
Thank for clarification, I feel whether this extension statement is 
backwards-compatible changes are generic issue that are applicable to all YANG 
extension related documents and standards.
Maybe it is worth writing a separate document to talk about backward 
compatibility of those yang extensions. 
For yang extension introduced in this draft is just for data classification, 
the impact of adding or removing data node tag is just to influence the 
precision or granularity of data classification.
Therefore I think changing these extension is just backwards-compatible change.

-Qin
-邮件原件-
发件人: Balázs Lengyel [mailto:balazs.lengyel=40ericsson@dmarc.ietf.org] 
发送时间: 2022年4月19日 16:04
收件人: Qin Wu ; Jürgen Schönwälder 

抄送: netmod@ietf.org
主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>- for each extension statement the following should be described
>   + Changing this extension statement is a backwards-compatible change  
>yes/no/editorial-only
[Qin Wu] Can you provide an example for this issue or reference document, I can 
not find any guideline in RFC7950.

BALAZS: It is the first question you get from a customer at any model 
update/upgrade: are the changes backwards compatible?
The modeler and the customer needs to understand whether a change in the 
extension statements is backwards compatible or not. 
The new YANG versioning drafts also require this knowledge.
E.g. 
Removing the nacm:default-deny-all extension from a leaf is backwards 
compatible as all earlier operations will still work Adding the 
nacm:default-deny-all extension to a leaf is not  backwards compatible as 
writing to the leaf might not work anymore.

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Qiufang:
First, the metric-tag defined in this draft allow you add more metric-tag 
values in the metric-tag subregistry. See usage example in the Appendix B.
To make the data node tags module even more extensible, I think adding one leaf 
in the type of enumeration is still limited,
a. the enumeration type is not extensible and doesn't allow you add new 
enumeration values.
b. how do you introduce other auxiliary data associated with new introduced tag 
type, therefore here is my proposal:
module: ietf-data-node-tags
augment /tags:module-tags/tags:module:
  +--rw data-node-tags
 +--rw data-node* [ni-id]
+--rw ni-idnacm:node-instance-identifier
+--rw tag* tags:tag
+--rw masked-tag*  tags:tag  
+--rw extended-tag-type?   identityref 
As you can see, we introduce extended-tag-type in the base module,
which allows you further add auxiliary data in the extension to the base 
module, see Appendix A for example.
See more details in v-07
https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/

-Qin
-邮件原件-
发件人: maqiufang (A) 
发送时间: 2022年4月13日 19:19
收件人: Jürgen Schönwälder ; Qin Wu 

抄送: netmod@ietf.org
主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi, Juergen, Qin
How about defining a more general mechanism to cover your proposal:
  module: ietf-data-node-tags
  augment /tags:module-tags/tags:module:
+--rw data-object-tags
   +--rw data-node* [ni-id]
  +--rw ni-id  nacm:node-instance-identifier
  +--rw tag-list* [tag]
  |  +--rw tagtags:tag
  |  +--rw value?  enumeration
  +--rw masked-tag*   tags:tag
So that the users can define any tag(e.g., corresponding-mib-oid, 
related-node...) they’re interested in and the corresponding value(if any).

Best Regards,
Qiufang

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder
Sent: Wednesday, April 13, 2022 2:37 PM
To: Qin Wu 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi,

I believe the NETMOD WG should work out a single mechanism to convey metadata. 
I see no value in developing N use case specific mechanisms spread over several 
WGs. If this document is not aiming to provide a generic solution, then I 
believe it should not be published.

/js

On Tue, Apr 12, 2022 at 03:27:03PM +, Qin Wu wrote:
> Hi, Jurgen:
> I understand your comment, is to investigate more use cases and see how one 
> mechanism can be generalized to cover more use cases.
> But the idea of this draft is to capture characteristics data (e.g., KPI data 
> ) using data node tag. Data node tag module can only convey enumerated tag 
> valued defined in section 9.2, that is why Balazs clarify the essence of data 
> nod tag are not metadata based on RFC7950 but data properties.
> 
> I did investigate meta-data-collection draft. I think meta-data 
> collection draft extends from ietf-system-capabilities module defined in 
> RFC9196 while draft-ietf-netmod-node-tags-06 extends from ietf-module-tags 
> defined in RFC8819 I believe observable-period related parameter in 
> metadata-collection module is not suited to be redefined in Data node tag 
> module since they are really system capability related parameters.
> For three other parameters such as corresponding-mib-oid, related-node, 
> optimized-measurement-point, not every data node has these three parameters, 
> the value of corresponding-mib-oid, related-node can be any value it is hard 
> to be listed as tag values, for optimized-measutement-point, it is empty 
> type, it seem to fine, but add corresponding-mib-oid, related-node make data 
> node tag module design very ugly, also the value of corresponding-mib-oid, 
> related-node are read only value and can not be configured by the user.
> module: ietf-data-node-tags
> augment /tags:module-tags/tags:module:
>   +--rw data-node-tags
>  +--rw data-node* [ni-id]
> +--rw ni-id  nacm:node-instance-identifier
> +--rw tag* tags:tag
> +--rw masked-tag*  tags:tag  
> +--rw corresponding-mib-oid? yang:object-identifier-128
> +--rw related-node? yang:node-instance-identifier
> In addition, we may need to introduce new yang extension for these two 
> parameters and consider to use when statement to decide when 
> corresponding-mib-oid or related-node should not appear or otherwise, I feel 
> designing this kind of model is not generic. Please correct me if I am wrong.
> 
> -Qin
> -邮件原件-
> 发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2022年4月11日 21:32
> 收件人: Qin Wu 
> 抄送: Kent Watsen ; netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> It seems like we confuse use cases with mechanisms. We should IMHO focus on 
&

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Andy Bierman]

On Tue, Apr 19, 2022 at 1:26 AM Jan Lindblad  wrote:

> Balázs, Qin, WG,
>
> >> - for each extension statement the following should be described
> >>  + Changing this extension statement is a backwards-compatible change
> >> yes/no/editorial-only
> > [Qin Wu] Can you provide an example for this issue or reference
> document, I can not find any guideline in RFC7950.
> >
> > BALAZS: It is the first question you get from a customer at any model
> update/upgrade: are the changes backwards compatible?
> > The modeler and the customer needs to understand whether a change in the
> extension statements is backwards compatible or not.
> > The new YANG versioning drafts also require this knowledge.
> > E.g.
> > Removing the nacm:default-deny-all extension from a leaf is backwards
> compatible as all earlier operations will still work
> > Adding the nacm:default-deny-all extension to a leaf is not  backwards
> compatible as writing to the leaf might not work anymore.
>
> This is a great example of why backwards compatibility is a really hard
> subject.
>
> A manager relying on nacm:default-deny-all might not be injecting the
> right NACM rules to make the managed system secure after the version
> change. While all management operations will succeed, the change opens up a
> security hole for managers unaware of the change. I believe such a change
> should not be described as backwards compatible.
>
> My point is that while in the YANG versioning design team are working to
> define hard and fast rules for what constitutes backwards compatibility,
> reality is a few magnitudes more complex than any viable rule set.
>
>

+1

Classifying a change and encoding the classification into a semver does not
actually fix anything.
Only advancements in tooling and protocols will fix anything. There needs
to be standardized warnings.

1) YANG compiler
   - standard extensions to trigger deprecation and NBC warnings
   - needed at the definition-level, not the module level

2) NETCONF and RESTCONF protocols
- need standard error-tag to allow error-serverity=warning
- need standard warnings reports


As a developer, I want to see warnings about a specific issue, and
suggestions on how to fix it,
just like I get from my C++ compiler.  The YANG language and YANG-based
protocols are
still quite primitive compared to modern tools.



> Best Regards,
> /jan
>
>
Andy


> ___
> 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 draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

-Original Message-
From: netmod  On Behalf Of Jan Lindblad
Sent: Tuesday, 19 April, 2022 10:26
To: Balázs Lengyel 
Cc: netmod@ietf.org; Qin Wu 
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Balázs, Qin, WG,

>> - for each extension statement the following should be described  + 
>> Changing this extension statement is a backwards-compatible change 
>> yes/no/editorial-only
> [Qin Wu] Can you provide an example for this issue or reference document, I 
> can not find any guideline in RFC7950.
> 
> BALAZS: It is the first question you get from a customer at any model 
> update/upgrade: are the changes backwards compatible?
> The modeler and the customer needs to understand whether a change in the 
> extension statements is backwards compatible or not. 
> The new YANG versioning drafts also require this knowledge.
> E.g. 
> Removing the nacm:default-deny-all extension from a leaf is backwards 
> compatible as all earlier operations will still work Adding the 
> nacm:default-deny-all extension to a leaf is not  backwards compatible as 
> writing to the leaf might not work anymore.

This is a great example of why backwards compatibility is a really hard subject.

A manager relying on nacm:default-deny-all might not be injecting the right 
NACM rules to make the managed system secure after the version change. While 
all management operations will succeed, the change opens up a security hole for 
managers unaware of the change. I believe such a change should not be described 
as backwards compatible.

My point is that while in the YANG versioning design team are working to define 
hard and fast rules for what constitutes backwards compatibility, reality is a 
few magnitudes more complex than any viable rule set.

Best Regards,
/jan

BALAZS2: Practically any change can cause operational problems if  a client 
depends on it, still not saying anything about it will be a problem. Even if we 
only consider RFC7950  terminology: Is it allowed to change this extension: 
yes, no, in what manner? This should be stated.
IMHO this is a great example of why we cannot consider all secondary effects of 
a change when considering compatibility. If we do, no change will be 
compatible. We should say allowed (compatible) changes are the ones that allow 
existing operations to succeed.

___
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 draft-ietf-netmod-node-tags-06

[Jan Lindblad]

Balázs, Qin, WG,

>> - for each extension statement the following should be described
>>  + Changing this extension statement is a backwards-compatible change 
>> yes/no/editorial-only
> [Qin Wu] Can you provide an example for this issue or reference document, I 
> can not find any guideline in RFC7950.
> 
> BALAZS: It is the first question you get from a customer at any model 
> update/upgrade: are the changes backwards compatible?
> The modeler and the customer needs to understand whether a change in the 
> extension statements is backwards compatible or not. 
> The new YANG versioning drafts also require this knowledge.
> E.g. 
> Removing the nacm:default-deny-all extension from a leaf is backwards 
> compatible as all earlier operations will still work
> Adding the nacm:default-deny-all extension to a leaf is not  backwards 
> compatible as writing to the leaf might not work anymore.

This is a great example of why backwards compatibility is a really hard subject.

A manager relying on nacm:default-deny-all might not be injecting the right 
NACM rules to make the managed system secure after the version change. While 
all management operations will succeed, the change opens up a security hole for 
managers unaware of the change. I believe such a change should not be described 
as backwards compatible.

My point is that while in the YANG versioning design team are working to define 
hard and fast rules for what constitutes backwards compatibility, reality is a 
few magnitudes more complex than any viable rule set.

Best Regards,
/jan

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

>- for each extension statement the following should be described
>   + Changing this extension statement is a backwards-compatible change 
> yes/no/editorial-only
[Qin Wu] Can you provide an example for this issue or reference document, I can 
not find any guideline in RFC7950.

BALAZS: It is the first question you get from a customer at any model 
update/upgrade: are the changes backwards compatible?
The modeler and the customer needs to understand whether a change in the 
extension statements is backwards compatible or not. 
The new YANG versioning drafts also require this knowledge.
E.g. 
Removing the nacm:default-deny-all extension from a leaf is backwards 
compatible as all earlier operations will still work
Adding the nacm:default-deny-all extension to a leaf is not  backwards 
compatible as writing to the leaf might not work anymore.

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
发送时间: 2022年4月14日 3:18
收件人: Qin Wu ; 'Kent Watsen' ; 
netmod@ietf.org
主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi Qin,

Very good. Thanks for this. Almost perfect convergence.

Just one point left…

9.1

   This registry allocates tag prefixes.  All YANG Data Object Tags
   should begin with one of the prefixes in this registry.

That's not quite true, is it?

[Qin Wu] I think this is recommendation for all YANG data node tags beginning 
with one of prefixed in this registry,
Maybe we should use RFC2119 language,e.g., replace ‘should’with ‘SHOULD’?

Ah, sorry, I wasn’t clear.
The user tags are Data Objects Tags, but they don’t have to begin with a prefix.
Since this section is IANA instructions, it isn’t really appropriate to use 
2119 language.

I think, re-reading the whole of Section 9.1 again, maybe this paragraph isn’t 
actually necessary at all. It doesn’t tell IANA anything they need to know, and 
it doesn’t cover anything that isn’t already covered elsewhere in the document.
[Qin Wu] Your argument in this context is reasonable to me, I will take it out, 
thanks for your suggestion.
Best,
Adrian
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Adrian Farrel]

Hi Qin,

 

Very good. Thanks for this. Almost perfect convergence.

 

Just one point left.

 

9.1

 

   This registry allocates tag prefixes.  All YANG Data Object Tags

   should begin with one of the prefixes in this registry.

 

That's not quite true, is it? 

 

[Qin Wu] I think this is recommendation for all YANG data node tags
beginning with one of prefixed in this registry,

Maybe we should use RFC2119 language,e.g., replace 'should'with 'SHOULD'?

 

Ah, sorry, I wasn't clear.

The user tags are Data Objects Tags, but they don't have to begin with a
prefix. 

Since this section is IANA instructions, it isn't really appropriate to use
2119 language.

 

I think, re-reading the whole of Section 9.1 again, maybe this paragraph
isn't actually necessary at all. It doesn't tell IANA anything they need to
know, and it doesn't cover anything that isn't already covered elsewhere in
the document.

 

Best,

Adrian

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Thanks Adrian for valuable review, I have integrated your comments in 
https://github.com/billwuqin/draft-ietf-netmod-node-tags/blob/main/draft-ietf-netmod-node-tags-07.txt
Please also see my reply inline below.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Adrian Farrel
发送时间: 2022年4月13日 5:36
收件人: 'Kent Watsen' ; netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi,

I had previously provided a review of this document (at revision -04),
and the authors worked to address my comments through the subsequent
revisions.

I have now re-read this document during WG last call. Most of my
comments are nits, but there are a few suggestions of substance.

Once these are all resolved the document will, in my opinion, be
ready for publication.

Best,
Adrian



The document needs a note somewhere near the top.

[RFC Editor Note: Please replace  in the text with the RFC number
assigned to this document, and remove this note.]
[Qin Wu]  thanks, have added them in several places.
---

Abstract

s/characteristics/characteristic/
s/the module definition/the definition of the module/

[Qin Wu] Fixed, thank.
---

Introduction

s/represent a portion/represent only a portion/

OLD
   there is no consistent classification criteria or
   representation
NEW
   there are no consistent classification criteria or
   representations
END

   This document defines self-describing data object tags and associates
   them with data objects within a YANG module, which:
I think that may be s/associates them/shows how they may be associated/

s/by the NETCONF/by a NETCONF/

[Qin Wu] Good wording and proposed changes, have accepted them all.
---

4.

   All data object tags SHOULD begin with a prefix indicating who owns
   their definition.  An IANA registry (Section 9.1) is used to register
   data object tag prefixes.  Initially, three prefixes are defined.

I'm not sure who you are binding with this use of uppercase SHOULD or
what variance you are allowing.

I think you are probably giving instructions to the authors of future
documents that define new tags (since the ones you define do all have
a prefix - ietf:, vendor:, and user:).

But the reason you have "SHOULD" not "MUST" is because of the text in
4.3 (and see below for a comment on that).

So how about being more explicit with something like:

   All data object tags (except in some cases of user tags as described
   in Section 4.3) begin with a prefix indicating who owns their
   definition.  An IANA registry (Section 9.1) is used to register data
   object tag prefixes.  Initially, three prefixes are defined.

[Qin Wu] Your understanding is correct, the proposed change looks good.
---

4.2

   These tags are defined by the vendor that implements the module, and
   are not registered with IANA.  However, it is RECOMMENDED that the
   vendor includes extra identification in the tag to avoid collisions,
   such as using the enterprise or organization name following the
   "vendor:" prefix (e.g., vendor:example.com:vendor-defined-
   classifier).

I'm still not really happy with the disambiguation achieved using "the
enterprise or organization name". There is no registry of enterprise or
organisation names, so there is no way to be sure of uniqueness. But if
you recommended the use of an enterprise number (possibly with the
secondary prefix entno:) then things would be cleaner.

This would also enable you to have an example that did not use a URN
which is not really an example of an enterprise name or organization
name. (There is an enterprise number reserved for documentation - 32743)

[Qin Wu] Good improvement, I am happy to replace the original text
With “vendor:entno:vendor-defined-classifier”, yes, RFC5612 provides
Enterprise Number for Documentation Use, which is 32743.
---

4.3

The ambiguity in this section needs to be sorted out. It's clear to me
that you:
- prefer user tags to have the prefix "user:"
- you allow user tags without that prefix provided they do not contain
  a colon

However, you have...

   A user tag is any tag that has the prefix "user:".  For the avoidance
   of confusion, the colon (":") when it appears for the first time, is
   always assumed to be the separator between a prefix and the rest of
   the tag.  And so, when a user tag does not have a prefix, it MUST NOT
   contain a colon.

   These tags are defined by a user/administrator and are not meant to
   be registered with IANA.  Users are not required to use the "user:"
   prefix; however, doing so is RECOMMENDED as it helps avoid
   collisions.

The first sentence defines a user tag to have the prefix "user:" which
is then contradicted. Further, I don't think that there will be
collisions because of the no-colon rule.

Maybe this could be sorted out by replacing the text as:

   User tags are defined by a user/administrator and are not registered
   by IANA.

   Any

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[maqiufang (A)]

Hi, Juergen, Qin
How about defining a more general mechanism to cover your proposal:
  module: ietf-data-node-tags
  augment /tags:module-tags/tags:module:
+--rw data-object-tags
   +--rw data-node* [ni-id]
  +--rw ni-id  nacm:node-instance-identifier
  +--rw tag-list* [tag]
  |  +--rw tagtags:tag
  |  +--rw value?  enumeration
  +--rw masked-tag*   tags:tag
So that the users can define any tag(e.g., corresponding-mib-oid, 
related-node...) they’re interested in and the corresponding value(if any).

Best Regards,
Qiufang

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder
Sent: Wednesday, April 13, 2022 2:37 PM
To: Qin Wu 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi,

I believe the NETMOD WG should work out a single mechanism to convey metadata. 
I see no value in developing N use case specific mechanisms spread over several 
WGs. If this document is not aiming to provide a generic solution, then I 
believe it should not be published.

/js

On Tue, Apr 12, 2022 at 03:27:03PM +, Qin Wu wrote:
> Hi, Jurgen:
> I understand your comment, is to investigate more use cases and see how one 
> mechanism can be generalized to cover more use cases.
> But the idea of this draft is to capture characteristics data (e.g., KPI data 
> ) using data node tag. Data node tag module can only convey enumerated tag 
> valued defined in section 9.2, that is why Balazs clarify the essence of data 
> nod tag are not metadata based on RFC7950 but data properties.
> 
> I did investigate meta-data-collection draft. I think meta-data 
> collection draft extends from ietf-system-capabilities module defined in 
> RFC9196 while draft-ietf-netmod-node-tags-06 extends from ietf-module-tags 
> defined in RFC8819 I believe observable-period related parameter in 
> metadata-collection module is not suited to be redefined in Data node tag 
> module since they are really system capability related parameters.
> For three other parameters such as corresponding-mib-oid, related-node, 
> optimized-measurement-point, not every data node has these three parameters, 
> the value of corresponding-mib-oid, related-node can be any value it is hard 
> to be listed as tag values, for optimized-measutement-point, it is empty 
> type, it seem to fine, but add corresponding-mib-oid, related-node make data 
> node tag module design very ugly, also the value of corresponding-mib-oid, 
> related-node are read only value and can not be configured by the user.
> module: ietf-data-node-tags
> augment /tags:module-tags/tags:module:
>   +--rw data-node-tags
>  +--rw data-node* [ni-id]
> +--rw ni-id  nacm:node-instance-identifier
> +--rw tag* tags:tag
> +--rw masked-tag*  tags:tag  
> +--rw corresponding-mib-oid? yang:object-identifier-128
> +--rw related-node? yang:node-instance-identifier
> In addition, we may need to introduce new yang extension for these two 
> parameters and consider to use when statement to decide when 
> corresponding-mib-oid or related-node should not appear or otherwise, I feel 
> designing this kind of model is not generic. Please correct me if I am wrong.
> 
> -Qin
> -邮件原件-
> 发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2022年4月11日 21:32
> 收件人: Qin Wu 
> 抄送: Kent Watsen ; netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> It seems like we confuse use cases with mechanisms. We should IMHO focus on 
> defining one mechanism to convey metadata and ideally that mechanism than 
> supports multiple use cases.
> 
> /js
> 
> On Mon, Apr 11, 2022 at 01:14:08PM +, Qin Wu wrote:
> > Hi, Jurgen:
> > Thank for bringing this issue up.
> > Generally, I feel two drafts are orthogonal to each other. 
> > Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data 
> > classification while draft-claise-netconf-metadata-for-collection-03 
> > focuses on telemetry related server capability exposure, e.g., how frequent 
> > you can use YANG push mechanism to send the telemetry data, from where to 
> > collect the specific interested data, how to inform the client or collector 
> > when the server compute a new observable period, in other words, 
> > draft-claise-netconf-metadata-for-collection-03 more focuses on data 
> > collection protocol (e.g., yang push) related metadata.
> > 
> > In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
> > notification capability defined in RFC9196 since ietf-data-object-tags in 
> > draft-ietf-netmod-node-tags-06 defines data objects list under 
> > /tags:module-tag

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

Hi,

I believe the NETMOD WG should work out a single mechanism to convey
metadata. I see no value in developing N use case specific mechanisms
spread over several WGs. If this document is not aiming to provide a
generic solution, then I believe it should not be published.

/js

On Tue, Apr 12, 2022 at 03:27:03PM +, Qin Wu wrote:
> Hi, Jurgen:
> I understand your comment, is to investigate more use cases and see how one 
> mechanism can be generalized to cover more use cases.
> But the idea of this draft is to capture characteristics data (e.g., KPI data 
> ) using data node tag. Data node tag module can only convey enumerated tag 
> valued defined in section 9.2, that is why Balazs clarify the essence of data 
> nod tag are not metadata based on RFC7950 but data properties.
> 
> I did investigate meta-data-collection draft. I think meta-data collection 
> draft extends from ietf-system-capabilities module defined in RFC9196 while 
> draft-ietf-netmod-node-tags-06 extends from ietf-module-tags defined in 
> RFC8819
> I believe observable-period related parameter in metadata-collection module 
> is not suited to be redefined in Data node tag module since they are really 
> system capability related parameters.
> For three other parameters such as corresponding-mib-oid, related-node, 
> optimized-measurement-point, not every data node has these three parameters, 
> the value of corresponding-mib-oid, related-node can be any value it is hard 
> to be listed as tag values, for optimized-measutement-point, it is empty 
> type, it seem to fine, but add corresponding-mib-oid, related-node make data 
> node tag module design very ugly, also the value of corresponding-mib-oid, 
> related-node are read only value and can not be configured by the user.
> module: ietf-data-node-tags
> augment /tags:module-tags/tags:module:
>   +--rw data-node-tags
>  +--rw data-node* [ni-id]
> +--rw ni-id  nacm:node-instance-identifier
> +--rw tag* tags:tag
> +--rw masked-tag*  tags:tag  
> +--rw corresponding-mib-oid? yang:object-identifier-128
> +--rw related-node? yang:node-instance-identifier
> In addition, we may need to introduce new yang extension for these two 
> parameters and consider to use when statement to decide when 
> corresponding-mib-oid or related-node should not appear or otherwise,
> I feel designing this kind of model is not generic. Please correct me if I am 
> wrong.
> 
> -Qin
> -邮件原件-
> 发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de] 
> 发送时间: 2022年4月11日 21:32
> 收件人: Qin Wu 
> 抄送: Kent Watsen ; netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> It seems like we confuse use cases with mechanisms. We should IMHO focus on 
> defining one mechanism to convey metadata and ideally that mechanism than 
> supports multiple use cases.
> 
> /js
> 
> On Mon, Apr 11, 2022 at 01:14:08PM +, Qin Wu wrote:
> > Hi, Jurgen:
> > Thank for bringing this issue up.
> > Generally, I feel two drafts are orthogonal to each other. 
> > Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data 
> > classification while draft-claise-netconf-metadata-for-collection-03 
> > focuses on telemetry related server capability exposure, e.g., how frequent 
> > you can use YANG push mechanism to send the telemetry data, from where to 
> > collect the specific interested data, how to inform the client or collector 
> > when the server compute a new observable period, in other words, 
> > draft-claise-netconf-metadata-for-collection-03 more focuses on data 
> > collection protocol (e.g., yang push) related metadata.
> > 
> > In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
> > notification capability defined in RFC9196 since ietf-data-object-tags in 
> > draft-ietf-netmod-node-tags-06 defines data objects list under 
> > /tags:module-tags/tags:module. Therefore the client can look for these tags 
> > from the ,  also can be used since yang extension 
> > is defined for these tags in the ietf-data-object-tags.
> > 
> > Please correct me if I am wrong. 
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> > 发送时间: 2022年4月11日 15:55
> > 收件人: Kent Watsen 
> > 抄送: netmod@ietf.org
> > 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> > 
> > During the NETCONF meeting at IETF 113, Benoit presented an I-D titled
> > 
> >  Per-Node Capabilities for Optimum Operational Data Collection
> > draft-claise-netconf-metadata-for-collection-03
> > 
> > and I asked why we need an

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Adrian Farrel]

Hi,

 

I had previously provided a review of this document (at revision -04),

and the authors worked to address my comments through the subsequent

revisions.

 

I have now re-read this document during WG last call. Most of my 

comments are nits, but there are a few suggestions of substance.

 

Once these are all resolved the document will, in my opinion, be

ready for publication.

 

Best,

Adrian

 



 

The document needs a note somewhere near the top.

 

[RFC Editor Note: Please replace  in the text with the RFC number

assigned to this document, and remove this note.]

 

---

 

Abstract

 

s/characteristics/characteristic/

s/the module definition/the definition of the module/

 

---

 

Introduction

 

s/represent a portion/represent only a portion/

 

OLD

   there is no consistent classification criteria or

   representation

NEW

   there are no consistent classification criteria or

   representations

END

 

   This document defines self-describing data object tags and associates

   them with data objects within a YANG module, which:

I think that may be s/associates them/shows how they may be associated/

 

s/by the NETCONF/by a NETCONF/

 

---

 

4.

 

   All data object tags SHOULD begin with a prefix indicating who owns

   their definition.  An IANA registry (Section 9.1) is used to register

   data object tag prefixes.  Initially, three prefixes are defined.

 

I'm not sure who you are binding with this use of uppercase SHOULD or

what variance you are allowing.

 

I think you are probably giving instructions to the authors of future

documents that define new tags (since the ones you define do all have

a prefix - ietf:, vendor:, and user:).

 

But the reason you have "SHOULD" not "MUST" is because of the text in

4.3 (and see below for a comment on that).

 

So how about being more explicit with something like:

 

   All data object tags (except in some cases of user tags as described

   in Section 4.3) begin with a prefix indicating who owns their

   definition.  An IANA registry (Section 9.1) is used to register data

   object tag prefixes.  Initially, three prefixes are defined.

 

---

 

4.2

 

   These tags are defined by the vendor that implements the module, and

   are not registered with IANA.  However, it is RECOMMENDED that the

   vendor includes extra identification in the tag to avoid collisions,

   such as using the enterprise or organization name following the

   "vendor:" prefix (e.g., vendor:example.com:vendor-defined- 

   classifier).

 

I'm still not really happy with the disambiguation achieved using "the

enterprise or organization name". There is no registry of enterprise or 

organisation names, so there is no way to be sure of uniqueness. But if

you recommended the use of an enterprise number (possibly with the 

secondary prefix entno:) then things would be cleaner.

 

This would also enable you to have an example that did not use a URN

which is not really an example of an enterprise name or organization

name. (There is an enterprise number reserved for documentation - 32743)

 

---

 

4.3

 

The ambiguity in this section needs to be sorted out. It's clear to me 

that you:

- prefer user tags to have the prefix "user:"

- you allow user tags without that prefix provided they do not contain

  a colon

 

However, you have...

 

   A user tag is any tag that has the prefix "user:".  For the avoidance

   of confusion, the colon (":") when it appears for the first time, is

   always assumed to be the separator between a prefix and the rest of

   the tag.  And so, when a user tag does not have a prefix, it MUST NOT

   contain a colon.

 

   These tags are defined by a user/administrator and are not meant to

   be registered with IANA.  Users are not required to use the "user:"

   prefix; however, doing so is RECOMMENDED as it helps avoid

   collisions.

 

The first sentence defines a user tag to have the prefix "user:" which

is then contradicted. Further, I don't think that there will be

collisions because of the no-colon rule. 

 

Maybe this could be sorted out by replacing the text as:

 

   User tags are defined by a user/administrator and are not registered

   by IANA.   

 

   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.

 

---

 

4.4 conflicts with 4.3. That is, 4.3 says that tags can start without

any of those three prefixes without being reserved.

 

I don't think "reserved in the context of specifications" has a clear

meaning.

 

I think you need...

 

4.4.  Reserved Prefixes

 

   Section 9.1 describes the IANA registry of tag prefixes.  Any prefix

   not included in that registry is reserved for future use, but tags

   starting with such a prefix are still valid tags.

 

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Jurgen:
I understand your comment, is to investigate more use cases and see how one 
mechanism can be generalized to cover more use cases.
But the idea of this draft is to capture characteristics data (e.g., KPI data ) 
using data node tag. Data node tag module can only convey enumerated tag valued 
defined in section 9.2, that is why Balazs clarify the essence of data nod tag 
are not metadata based on RFC7950 but data properties.

I did investigate meta-data-collection draft. I think meta-data collection 
draft extends from ietf-system-capabilities module defined in RFC9196 while 
draft-ietf-netmod-node-tags-06 extends from ietf-module-tags defined in RFC8819
I believe observable-period related parameter in metadata-collection module is 
not suited to be redefined in Data node tag module since they are really system 
capability related parameters.
For three other parameters such as corresponding-mib-oid, related-node, 
optimized-measurement-point, not every data node has these three parameters, 
the value of corresponding-mib-oid, related-node can be any value it is hard to 
be listed as tag values, for optimized-measutement-point, it is empty type, it 
seem to fine, but add corresponding-mib-oid, related-node make data node tag 
module design very ugly, also the value of corresponding-mib-oid, related-node 
are read only value and can not be configured by the user.
module: ietf-data-node-tags
augment /tags:module-tags/tags:module:
  +--rw data-node-tags
 +--rw data-node* [ni-id]
+--rw ni-id  nacm:node-instance-identifier
+--rw tag* tags:tag
+--rw masked-tag*  tags:tag  
+--rw corresponding-mib-oid? yang:object-identifier-128
+--rw related-node? yang:node-instance-identifier
In addition, we may need to introduce new yang extension for these two 
parameters and consider to use when statement to decide when 
corresponding-mib-oid or related-node should not appear or otherwise,
I feel designing this kind of model is not generic. Please correct me if I am 
wrong.

-Qin
-邮件原件-
发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de] 
发送时间: 2022年4月11日 21:32
收件人: Qin Wu 
抄送: Kent Watsen ; netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

It seems like we confuse use cases with mechanisms. We should IMHO focus on 
defining one mechanism to convey metadata and ideally that mechanism than 
supports multiple use cases.

/js

On Mon, Apr 11, 2022 at 01:14:08PM +, Qin Wu wrote:
> Hi, Jurgen:
> Thank for bringing this issue up.
> Generally, I feel two drafts are orthogonal to each other. 
> Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data 
> classification while draft-claise-netconf-metadata-for-collection-03 focuses 
> on telemetry related server capability exposure, e.g., how frequent you can 
> use YANG push mechanism to send the telemetry data, from where to collect the 
> specific interested data, how to inform the client or collector when the 
> server compute a new observable period, in other words, 
> draft-claise-netconf-metadata-for-collection-03 more focuses on data 
> collection protocol (e.g., yang push) related metadata.
> 
> In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
> notification capability defined in RFC9196 since ietf-data-object-tags in 
> draft-ietf-netmod-node-tags-06 defines data objects list under 
> /tags:module-tags/tags:module. Therefore the client can look for these tags 
> from the ,  also can be used since yang extension is 
> defined for these tags in the ietf-data-object-tags.
> 
> Please correct me if I am wrong. 
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> 发送时间: 2022年4月11日 15:55
> 收件人: Kent Watsen 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> During the NETCONF meeting at IETF 113, Benoit presented an I-D titled
> 
>  Per-Node Capabilities for Optimum Operational Data Collection
> draft-claise-netconf-metadata-for-collection-03
> 
> and I asked why we need another metadata export mechanism given that node 
> tags is been worked on in the NETMOD WG. The reaction during the meeting was 
> to followup on the mailing list, i.e., there was no conclusive answer during 
> the meeting.
> 
> I suggest that this document does not proceed until we know that it provides 
> all mechanisms needed to support the use case described in the above 
> mentioned I-D. If any functionality is lacking, the WG may want to 
> investigate whether this can be addressed generically.
> 
> /js
> 
> On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
> > This message begins a Working Group Last Call (WGLC) on 
> > draft-ietf-netmod-node-tags-06, per the chair-action from the 113 sess

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Balazs:
Thanks for your valuable comments, I have incorporated your comments into 
https://github.com/billwuqin/draft-ietf-netmod-node-tags/blob/main/draft-ietf-netmod-node-tags-07.txt
please see reply inline below.
-邮件原件-
>发件人: Balázs Lengyel [mailto:balazs.lengyel=40ericsson@dmarc.ietf.org] 
>发送时间: 2022年4月12日 0:38
>收件人: Qin Wu ; Jürgen Schönwälder 
>
>抄送: netmod@ietf.org
>主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>Hello,
>Sorry for the late comments as I am not very familiar with the topic, but some 
>questions:
>- What makes a tag "self-describing" ? Unless this "self-describing" has a 
>specific meaning, it would be easier not use it. I personally would prefer 
>instead of "self-describing  data object tags" some simpler name like "data 
>properties".
[Qin Wu] I have been discussing with Jurgen about the naming, we have reached 
agreement to change the title. Thanks for your proposal, data properties is a 
good naming, but have a little bit naming conflict with opm tag, since opm tag 
can be assigned with the 'property' value. 
>- In the YANG module I found the sentence: " The argument 'tag' is of type 
>'tag' "  Where is the "type tag" defined ?  If you mean from RFC 8819 indicate 
>that e.g. by using the yang prefix: tags:tag.
[Qin Wu] Your understanding is correct, I will use prefix tags: tag as you 
suggested. Good catch, thanks.
>- Reserved Tags: As I understand other SDOs may register their own prefix with 
>IANA in which case the list of :reserved for future use" is not the correct 
>characterization.
[Qin Wu] How about change into the following:
"
Any tag not starting with the prefix "ietf:", "vendor:", "user:" or being 
reserved by other SDOs is reserved by IETF for future use ...
"
>- tags can be associated with "data-objects" - RFC7950 does not use the 
>terminology "data object". Please call this "data nodes" or "data node 
>instances" and define in the terminology section if you use it. 
[Qin Wu] Good suggestion, thanks.
>- is the tag (property) inherited down the containment hierarchy? If a 
>container is marked with a tag, do all its contained leaves inherit the tag ? 
[Qin Wu] Very good comments. We define 3 data node tags in this draft, for 
metric-type and multi-source-tag tags, will be inherited down the containment 
hierarchy. For OPM tag, object tag value can not be inherited down but property 
tag and metric tag can be inherited down the containment hierarchy. I have add 
text to clarify this in section 5.1.
>- for each extension statement the following should be described
>   +  It can be a substatement of which parent statement, with what 
> cardinality?
[Qin Wu] Again good comment, object tag value will be associated with 
'container', 'leaf-list', and 'list'. Property tag value will be associated 
only with the leaf node. Metric tag value can be associated with 'container', 
'leaf-list', and 'list', leaf node.
For metric-type tag, it will be associated with 'container', 'leaf-list', and 
'list', leaf node tagged with 'metric' tag. For multi-source tag, similarly, it 
will be associated with 'container', 'leaf-list', and 'list', leaf node tagged 
with 'metric' tag.

For cardinality, I think opm tag have 3 fixed values and multi-source-tag tag 
have 2 fixed values. For metric-type value, it can be extensible and we list 7 
possible values, but not limited to those values.
>+ Can it have substatements
[Qin Wu] As described in section 7, each tag can only take one argument. No 
other substatments.
>   + Changing this extension statement is a backwards-compatible change 
> yes/no/editorial-only
[Qin Wu] Can you provide an example for this issue or reference document, I can 
not find any guideline in RFC7950.
>   + Define the type as yang type. Is the list of possible values closed or 
> can any string be used that fulfills the type-tag
[Qin Wu] See above, only opm tag and multi-source tag has possible value closed.
>- Security considerations calls these tags met-data. While from a broader 
>perspective that may be true, these tags are not metadata according to RFC 
>7952. Avoid using this terminology or clarify this.
[Qin Wu] I agree to remove meta-data based on RFC7952 metadata definition. It 
is not metadata.
>- "name" is not a very good name for a leaf containing an 
>node-instance-identifier.
[Qin Wu] How about change into 'ni-id'?
 
>-IMHO module ietf-data-object-tags-state should augment ietf-module-tags-state 
>not ietf-module-tags
[Qin Wu] Good catch, have fixed this.
>- Why does ietf-data-object-tags-state redefine the extensions? Duplication is 
>bad.
[Qin Wu] Good catch, have fixed this.
>- Shoudn't there be an editor's note about replacing XXXX with the 

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Balázs Lengyel]

Hello,
Sorry for the late comments as I am not very familiar with the topic, but some 
questions:
- What makes a tag "self-describing" ? Unless this "self-describing" has a 
specific meaning, it would be easier not use it. I personally would prefer 
instead of "self-describing  data object tags" some simpler name like "data 
properties".
- In the YANG module I found the sentence: " The argument 'tag' is of type 
'tag' "  Where is the "type tag" defined ?  If you mean from RFC 8819 indicate 
that e.g. by using the yang prefix: tags:tag.
- Reserved Tags: As I understand other SDOs may register their own prefix with 
IANA in which case the list of :reserved for future use" is not the correct 
characterization.
- tags can be associated with "data-objects" - RFC7950 does not use the 
terminology "data object". Please call this "data nodes" or "data node 
instances" and define in the terminology section if you use it. 
- is the tag (property) inherited down the containment hierarchy? If a 
container is marked with a tag, do all its contained leaves inherit the tag ? 
- for each extension statement the following should be described
   +  It can be a substatement of which parent statement, with what cardinality?
+ Can it have substatements
   + Changing this extension statement is a backwards-compatible change 
yes/no/editorial-only
   + Define the type as yang type. Is the list of possible values closed or can 
any string be used that fulfills the type-tag
- Security considerations calls these tags met-data. While from a broader 
perspective that may be true, these tags are not metadata according to RFC 
7952. Avoid using this terminology or clarify this.
- "name" is not a very good name for a leaf containing an 
node-instance-identifier. 
-IMHO module ietf-data-object-tags-state should augment ietf-module-tags-state 
not ietf-module-tags
- Why does ietf-data-object-tags-state redefine the extensions? Duplication is 
bad.
- Shoudn't there be an editor's note about replacing  with the RFC number?
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Qin Wu
Sent: Monday, 11 April, 2022 15:43
To: Jürgen Schönwälder 
Cc: netmod@ietf.org
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Hi, Jurgen:
-邮件原件-
发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2022年4月11日 20:18
收件人: Qin Wu 
抄送: Kent Watsen ; netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Mon, Apr 11, 2022 at 11:52:10AM +, Qin Wu wrote:
> >I have not read the document in detail yet but I find the notion of 
> >data objects and subobjects confusing. I also do not know what "massive" 
> >data object collections are or why both objects and subobjects can be 
> >modeled as YANG data nodes, or what the purpose of this statement is.
> 
> [Qin Wu] massive data collection might consume large amount of network 
> bandwidth resource and computation resource. the data node tag help us 
> capture characteristics data (e.g., KPI data) and greatly reduce the data to 
> exported to the collectors.
> Take example-module-A as an example:
>module example-module-A {
>  //...
>  container top {
>list X {
>  leaf foo {
>  }
>  leaf bar {
>  }
>}
>  }
>  // ...
>}
> The top level node will be seen as data object while leaf foo and leaf bar 
> will be seen as subobject, the top level node will be tagged with Object tag, 
> the child node will be tagged with other tag such as metric tag or metric 
> type tags.
> Note that the notion of data objects and subobjects is only used in the usage 
> example in section 3. Do you think it is confusing to introduce new 
> terminologies, if yes, I will see how to fix this.

I strongly disagree with introducing new terminology. The notion of a data 
object or a subobject does not exist in YANG. All the YANG model does is to 
associate tags with yang-node-identifiers. That's it and I think the document 
should restrict itself to explain that.
[Qin Wu] Fair point, I will remove these new terms. Thanks!
My comment was actually more about words like "massive" being a purely 
subjective term. Marketing people may use them but in technical writing or even 
scientific writing, they have no real meaning. 
[Qin Wu] Thanks for pointing this out, I didn't realize this is an issue before 
you flag this, what I emphasize large amount of data you need to collect, maybe 
should choose the better term, thanks.
If you are worried about scalability (and I would), then the question to ask 
may be whether a single flat list is scalable to large numbers of tags, i.e., 
how many queries do I need to find all relevant tags and how do the queries 
scale.
[Qi

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Jurgen:
-邮件原件-
发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de] 
发送时间: 2022年4月11日 20:18
收件人: Qin Wu 
抄送: Kent Watsen ; netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Mon, Apr 11, 2022 at 11:52:10AM +, Qin Wu wrote:
> >I have not read the document in detail yet but I find the notion of 
> >data objects and subobjects confusing. I also do not know what "massive" 
> >data object collections are or why both objects and subobjects can be 
> >modeled as YANG data nodes, or what the purpose of this statement is.
> 
> [Qin Wu] massive data collection might consume large amount of network 
> bandwidth resource and computation resource. the data node tag help us 
> capture characteristics data (e.g., KPI data) and greatly reduce the data to 
> exported to the collectors.
> Take example-module-A as an example:
>module example-module-A {
>  //...
>  container top {
>list X {
>  leaf foo {
>  }
>  leaf bar {
>  }
>}
>  }
>  // ...
>}
> The top level node will be seen as data object while leaf foo and leaf bar 
> will be seen as subobject, the top level node will be tagged with Object tag, 
> the child node will be tagged with other tag such as metric tag or metric 
> type tags.
> Note that the notion of data objects and subobjects is only used in the usage 
> example in section 3. Do you think it is confusing to introduce new 
> terminologies, if yes, I will see how to fix this.

I strongly disagree with introducing new terminology. The notion of a data 
object or a subobject does not exist in YANG. All the YANG model does is to 
associate tags with yang-node-identifiers. That's it and I think the document 
should restrict itself to explain that.
[Qin Wu] Fair point, I will remove these new terms. Thanks!
My comment was actually more about words like "massive" being a purely 
subjective term. Marketing people may use them but in technical writing or even 
scientific writing, they have no real meaning. 
[Qin Wu] Thanks for pointing this out, I didn't realize this is an issue before 
you flag this, what I emphasize large amount of data you need to collect, maybe 
should choose the better term, thanks.
If you are worried about scalability (and I would), then the question to ask 
may be whether a single flat list is scalable to large numbers of tags, i.e., 
how many queries do I need to find all relevant tags and how do the queries 
scale.
[Qin Wu] Again those tags defined in this draft are used to classify the data, 
the number of standard tag defined in this draft is not too many. At the schema 
level, I think the scale is not a problem, since the tag at the schema level 
help find where to get these interested data. At the data node instance level, 
using tag will help filter and quickly identify specific category data, e.g., 
KPI data, the query scale and cost is not greater than
Retrieving all the operational data and figuring out later on which one are 
useful data itself.
> >When I look at ietf-data-object-tags (likely also a misnomer), then what I 
> >see is a list associating tags to anything identifiable by a 
> >nacm:node-instance-identifier. It feels like this document has a lot of hot 
> >air around something that is at the end rather basic.
> 
> [Qin Wu] Please note that RFC9196 also defines node-selector as 
> node-instance-identifier. See the definition of node-instance-identifier in 
> RFC8341 "
>  typedef node-instance-identifier {
>type yang:xpath1.0;
>description
>  "Path expression used to represent a special
>   data node, action, or notification instance-identifier
>   string.
> 
>   A node-instance-identifier value is an
>   unrestricted YANG instance-identifier expression.
>   All the same rules as an instance-identifier apply,
>   except that ***predicates for keys are optional.
>   If a key
>   predicate is missing, then the node-instance-identifier
>   represents all possible server instances for that key. "
> It can represent one specific node instance,e.g.,
>  /* instance-identifier for a list entry */
>  /ex:system/ex:user[ex:name='fred']
> or all possible node instance if the predicates is not specified, e.g.,
>  /* instance-identifier for all list entry/
> /ex:system/ex:user
> For the latter case, it can also be seen as at node level or schema node 
> level if my understanding is correct.

I can't tell right now whether RFC 9196 makes proper use of 
nacm:node-instance-identifier. Anyway, this is important material to explain, 
not the data objects massive kind of marketing text.
[Qin Wu] Okay, will 

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

It seems like we confuse use cases with mechanisms. We should IMHO
focus on defining one mechanism to convey metadata and ideally that
mechanism than supports multiple use cases.

/js

On Mon, Apr 11, 2022 at 01:14:08PM +, Qin Wu wrote:
> Hi, Jurgen:
> Thank for bringing this issue up.
> Generally, I feel two drafts are orthogonal to each other. 
> Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data classification 
> while draft-claise-netconf-metadata-for-collection-03 focuses on telemetry 
> related server capability exposure, e.g.,
> how frequent you can use YANG push mechanism to send the telemetry data, from 
> where to collect the specific interested data, how to inform the client or 
> collector when the server compute a new observable period, in other words, 
> draft-claise-netconf-metadata-for-collection-03 more focuses on data 
> collection protocol (e.g., yang push) related metadata.
> 
> In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
> notification capability defined in RFC9196 since ietf-data-object-tags in 
> draft-ietf-netmod-node-tags-06 defines data objects list under 
> /tags:module-tags/tags:module. Therefore the client can look for these tags 
> from the ,  also can be used since yang extension is 
> defined for these tags in the ietf-data-object-tags.
> 
> Please correct me if I am wrong. 
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
> 发送时间: 2022年4月11日 15:55
> 收件人: Kent Watsen 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
> 
> During the NETCONF meeting at IETF 113, Benoit presented an I-D titled
> 
>  Per-Node Capabilities for Optimum Operational Data Collection
> draft-claise-netconf-metadata-for-collection-03
> 
> and I asked why we need another metadata export mechanism given that node 
> tags is been worked on in the NETMOD WG. The reaction during the meeting was 
> to followup on the mailing list, i.e., there was no conclusive answer during 
> the meeting.
> 
> I suggest that this document does not proceed until we know that it provides 
> all mechanisms needed to support the use case described in the above 
> mentioned I-D. If any functionality is lacking, the WG may want to 
> investigate whether this can be addressed generically.
> 
> /js
> 
> On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
> > This message begins a Working Group Last Call (WGLC) on 
> > draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session 
> > (minutes 
> > <https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>). 
> >  The WGLC will close in two-weeks (Apr 22).  Here is a direct link to the 
> > HTML version of the draft:
> > 
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags 
> > <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags>
> > 
> > Positive comments, e.g., "I've reviewed this document and believe it is 
> > ready for publication", are welcome!  This is useful and important, even 
> > from authors. Objections, concerns, and suggestions are also welcomed at 
> > this time.
> > 
> > Please be aware that this draft has declared IPR 
> > <https://datatracker.ietf.org/ipr/4216> indicating that license may entail 
> > possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 
> > (mailman 
> > <https://mailarchive.ietf.org/arch/msg/netmod/SC6zfdYVmvlkquWOzP1qZszxWgs/>):
> > 
> > [Lou] 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.
> > 
> > [Qin] Thanks for asking, different from module level tag defined in 
> > draft-ietf-netmod-module-tags , this work provide data node level tag 
> > definition, use these data node level tag definition to provide hint or 
> > indication to selection filter in the YANG push and tell the collector or 
> > subscriber which specific category data objects needs to fetched.
> > 
> > 
> > Kent (as co-chair)
> > 
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 2875

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Jurgen:
Thank for bringing this issue up.
Generally, I feel two drafts are orthogonal to each other. 
Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data classification 
while draft-claise-netconf-metadata-for-collection-03 focuses on telemetry 
related server capability exposure, e.g.,
how frequent you can use YANG push mechanism to send the telemetry data, from 
where to collect the specific interested data, how to inform the client or 
collector when the server compute a new observable period, in other words, 
draft-claise-netconf-metadata-for-collection-03 more focuses on data collection 
protocol (e.g., yang push) related metadata.

In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on 
notification capability defined in RFC9196 since ietf-data-object-tags in 
draft-ietf-netmod-node-tags-06 defines data objects list under 
/tags:module-tags/tags:module. Therefore the client can look for these tags 
from the ,  also can be used since yang extension is 
defined for these tags in the ietf-data-object-tags.

Please correct me if I am wrong. 

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
发送时间: 2022年4月11日 15:55
收件人: Kent Watsen 
抄送: netmod@ietf.org
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

During the NETCONF meeting at IETF 113, Benoit presented an I-D titled

 Per-Node Capabilities for Optimum Operational Data Collection
draft-claise-netconf-metadata-for-collection-03

and I asked why we need another metadata export mechanism given that node tags 
is been worked on in the NETMOD WG. The reaction during the meeting was to 
followup on the mailing list, i.e., there was no conclusive answer during the 
meeting.

I suggest that this document does not proceed until we know that it provides 
all mechanisms needed to support the use case described in the above mentioned 
I-D. If any functionality is lacking, the WG may want to investigate whether 
this can be addressed generically.

/js

On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
> This message begins a Working Group Last Call (WGLC) on 
> draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session 
> (minutes 
> <https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>).  
> The WGLC will close in two-weeks (Apr 22).  Here is a direct link to the HTML 
> version of the draft:
> 
>   https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags 
> <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags>
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors. Objections, concerns, and suggestions are also welcomed at this time.
> 
> Please be aware that this draft has declared IPR 
> <https://datatracker.ietf.org/ipr/4216> indicating that license may entail 
> possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 
> (mailman 
> <https://mailarchive.ietf.org/arch/msg/netmod/SC6zfdYVmvlkquWOzP1qZszxWgs/>):
> 
> [Lou] 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.
> 
> [Qin] Thanks for asking, different from module level tag defined in 
> draft-ietf-netmod-module-tags , this work provide data node level tag 
> definition, use these data node level tag definition to provide hint or 
> indication to selection filter in the YANG push and tell the collector or 
> subscriber which specific category data objects needs to fetched.
> 
> 
> Kent (as co-chair)
> 

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


-- 
Jürgen Schönwälder  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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

On Mon, Apr 11, 2022 at 11:52:10AM +, Qin Wu wrote:
> >I have not read the document in detail yet but I find the notion of data 
> >objects and subobjects confusing. I also do not know what "massive" data 
> >object collections are or why both objects and subobjects can be modeled as 
> >YANG data nodes, or what the 
> >purpose of this statement is. 
> 
> [Qin Wu] massive data collection might consume large amount of network 
> bandwidth resource and computation resource. the data node tag help us 
> capture characteristics data (e.g., KPI data) and greatly reduce the data to 
> exported to the collectors.
> Take example-module-A as an example:
>module example-module-A {
>  //...
>  container top {
>list X {
>  leaf foo {
>  }
>  leaf bar {
>  }
>}
>  }
>  // ...
>}
> The top level node will be seen as data object while leaf foo and leaf bar 
> will be seen as subobject, the top level node will be tagged with Object tag, 
> the child node will be tagged with other tag such as metric tag or metric 
> type tags.
> Note that the notion of data objects and subobjects is only used in the usage 
> example in section 3. Do you think it is confusing to introduce new 
> terminologies, if yes, I will see how to fix this.

I strongly disagree with introducing new terminology. The notion of a
data object or a subobject does not exist in YANG. All the YANG model
does is to associate tags with yang-node-identifiers. That's it and I
think the document should restrict itself to explain that.

My comment was actually more about words like "massive" being a purely
subjective term. Marketing people may use them but in technical
writing or even scientific writing, they have no real meaning. If you
are worried about scalability (and I would), then the question to ask
may be whether a single flat list is scalable to large numbers of
tags, i.e., how many queries do I need to find all relevant tags and
how do the queries scale.
 
> >When I look at ietf-data-object-tags (likely also a misnomer), then what I 
> >see is a list associating tags to anything identifiable by a 
> >nacm:node-instance-identifier. It feels like this document has a lot of hot 
> >air around something that is at the end rather basic.
> 
> [Qin Wu] Please note that RFC9196 also defines node-selector as 
> node-instance-identifier. See the definition of node-instance-identifier in 
> RFC8341
> "
>  typedef node-instance-identifier {
>type yang:xpath1.0;
>description
>  "Path expression used to represent a special
>   data node, action, or notification instance-identifier
>   string.
> 
>   A node-instance-identifier value is an
>   unrestricted YANG instance-identifier expression.
>   All the same rules as an instance-identifier apply,
>   except that ***predicates for keys are optional.
>   If a key
>   predicate is missing, then the node-instance-identifier
>   represents all possible server instances for that key. "
> It can represent one specific node instance,e.g.,
>  /* instance-identifier for a list entry */
>  /ex:system/ex:user[ex:name='fred']
> or all possible node instance if the predicates is not specified, e.g.,
>  /* instance-identifier for all list entry/
> /ex:system/ex:user
> For the latter case, it can also be seen as at node level or schema node 
> level if my understanding is correct.

I can't tell right now whether RFC 9196 makes proper use of
nacm:node-instance-identifier. Anyway, this is important material
to explain, not the data objects massive kind of marketing text.

/js

-- 
Jürgen Schönwälder  Jacobs 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 draft-ietf-netmod-node-tags-06

[Qin Wu]

Hi, Jürgen:
Thank for quick comments. Please see reply inline below.
-邮件原件-
>发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年4月11日 16:19
>收件人: Kent Watsen 
>抄送: netmod@ietf.org
>主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>I have a problem with the term "Self-Describing Data Object Tags". It is not 
>clear what 'self-describing' means. RFC 8819 defines "YANG Module Tags", i.e., 
>tags that apply to entire modules. Perhaps this document should be titled 
>"YANG Data Node 
>Instance Tags".
[Qin Wu] Good comment, in my understanding, the essence of data object tags is 
to classification telemetry data or operation and management data into several 
categories and tag data node with category information (e.g., tag a data node 
to indicate whether it is KPI related data), therefore here "self-describing" 
is really referred to inline information included in the same data module. I am 
okay to change the title to reflect what it actually is. Maybe "YANG data node 
Tags" is more appropriate.

>There should be in general a check that terminology aligns with YANG 
>terminology.  The document talks about 'YANG data object', which is not a well 
>defined term. In fact, there are three levels of tagging, you can tag modules 
>(RFC 8819), you can tag 
>data nodes, and you can tag data node instances. It seems a bit unclear to me 
>what the WGs strategy is here with covering all three levels.

[Qin Wu] Good question, I am also discussing with Joe about the similar issue, 
we could have both data node level tag and instance level tag since we use 
node-instance-identifier type and need to reach agreement on this.

>I have not read the document in detail yet but I find the notion of data 
>objects and subobjects confusing. I also do not know what "massive" data 
>object collections are or why both objects and subobjects can be modeled as 
>YANG data nodes, or what the 
>purpose of this statement is. 

[Qin Wu] massive data collection might consume large amount of network 
bandwidth resource and computation resource. the data node tag help us capture 
characteristics data (e.g., KPI data) and greatly reduce the data to exported 
to the collectors.
Take example-module-A as an example:
   module example-module-A {
 //...
 container top {
   list X {
 leaf foo {
 }
 leaf bar {
 }
   }
 }
 // ...
   }
The top level node will be seen as data object while leaf foo and leaf bar will 
be seen as subobject, the top level node will be tagged with Object tag, the 
child node will be tagged with other tag such as metric tag or metric type tags.
Note that the notion of data objects and subobjects is only used in the usage 
example in section 3. Do you think it is confusing to introduce new 
terminologies, if yes, I will see how to fix this.

>When I look at ietf-data-object-tags (likely also a misnomer), then what I see 
>is a list associating tags to anything identifiable by a 
>nacm:node-instance-identifier. It feels like this document has a lot of hot 
>air around something that is at the end rather basic.

[Qin Wu] Please note that RFC9196 also defines node-selector as 
node-instance-identifier. See the definition of node-instance-identifier in 
RFC8341
"
 typedef node-instance-identifier {
   type yang:xpath1.0;
   description
 "Path expression used to represent a special
  data node, action, or notification instance-identifier
  string.

  A node-instance-identifier value is an
  unrestricted YANG instance-identifier expression.
  All the same rules as an instance-identifier apply,
  except that ***predicates for keys are optional.
  If a key
  predicate is missing, then the node-instance-identifier
  represents all possible server instances for that key. "
It can represent one specific node instance,e.g.,
 /* instance-identifier for a list entry */
 /ex:system/ex:user[ex:name='fred']
or all possible node instance if the predicates is not specified, e.g.,
 /* instance-identifier for all list entry/
/ex:system/ex:user
For the latter case, it can also be seen as at node level or schema node level 
if my understanding is correct.

>/js

>On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
>> This message begins a Working Group Last Call (WGLC) on 
>> draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session 
>> (minutes 
>> <https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>).  
>> The WGLC will close in two->weeks (Apr 22).  Here is a direct link to the 
>> HTML version of the draft:
>> 
>>  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

I have a problem with the term "Self-Describing Data Object Tags". It
is not clear what 'self-describing' means. RFC 8819 defines "YANG
Module Tags", i.e., tags that apply to entire modules. Perhaps this
document should be titled "YANG Data Node Instance Tags".

There should be in general a check that terminology aligns with YANG
terminology.  The document talks about 'YANG data object', which is
not a well defined term. In fact, there are three levels of tagging,
you can tag modules (RFC 8819), you can tag data nodes, and you can
tag data node instances. It seems a bit unclear to me what the WGs
strategy is here with covering all three levels.

I have not read the document in detail yet but I find the notion of
data objects and subobjects confusing. I also do not know what
"massive" data object collections are or why both objects and
subobjects can be modeled as YANG data nodes, or what the purpose of
this statement is. When I look at ietf-data-object-tags (likely also a
misnomer), then what I see is a list associating tags to anything
identifiable by a nacm:node-instance-identifier. It feels like this
document has a lot of hot air around something that is at the end
rather basic.

/js

On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
> This message begins a Working Group Last Call (WGLC) on 
> draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session 
> (minutes 
> ).  
> The WGLC will close in two-weeks (Apr 22).  Here is a direct link to the HTML 
> version of the draft:
> 
>   https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags 
> 
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors. Objections, concerns, and suggestions are also welcomed at this time.
> 
> Please be aware that this draft has declared IPR 
>  indicating that license may entail 
> possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 
> (mailman 
> ):
> 
> [Lou] 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.
> 
> [Qin] Thanks for asking, different from module level tag defined in 
> draft-ietf-netmod-module-tags , this work provide data node level tag 
> definition, use these data node level tag definition to provide hint or 
> indication to selection filter in the YANG push and tell the collector or 
> subscriber which specific category data objects needs to fetched.
> 
> 
> Kent (as co-chair)
> 

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


-- 
Jürgen Schönwälder  Jacobs 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 draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder]

During the NETCONF meeting at IETF 113, Benoit presented an I-D titled

 Per-Node Capabilities for Optimum Operational Data Collection
draft-claise-netconf-metadata-for-collection-03

and I asked why we need another metadata export mechanism given that
node tags is been worked on in the NETMOD WG. The reaction during the
meeting was to followup on the mailing list, i.e., there was no
conclusive answer during the meeting.

I suggest that this document does not proceed until we know that it
provides all mechanisms needed to support the use case described in
the above mentioned I-D. If any functionality is lacking, the WG may
want to investigate whether this can be addressed generically.

/js

On Fri, Apr 08, 2022 at 06:09:45PM +, Kent Watsen wrote:
> This message begins a Working Group Last Call (WGLC) on 
> draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session 
> (minutes 
> ).  
> The WGLC will close in two-weeks (Apr 22).  Here is a direct link to the HTML 
> version of the draft:
> 
>   https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags 
> 
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors. Objections, concerns, and suggestions are also welcomed at this time.
> 
> Please be aware that this draft has declared IPR 
>  indicating that license may entail 
> possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 
> (mailman 
> ):
> 
> [Lou] 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.
> 
> [Qin] Thanks for asking, different from module level tag defined in 
> draft-ietf-netmod-module-tags , this work provide data node level tag 
> definition, use these data node level tag definition to provide hint or 
> indication to selection filter in the YANG push and tell the collector or 
> subscriber which specific category data objects needs to fetched.
> 
> 
> Kent (as co-chair)
> 

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


-- 
Jürgen Schönwälder  Jacobs 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