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

From: Kent Watsen <[email-masked]>
Date: Fri, 8 Apr 2022 18:09:45 +0000

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)

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 11 Apr 2022 09:54:57 +0200

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

> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 11 Apr 2022 10:18:44 +0200

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Apr 2022 22:35:51 +0100

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

---

5.2

   An implementation MAY include additional tags associated with data

   objects within a YANG module.  These tags SHOULD be IETF

   (Section 4.1) or vendor tags (Section 4.2).

The use of "SHOULD" is fine, but you need to give the alternative and

the reason for choosing the alternative.

---

7. multi-source-tag

s/'non-aggregated'  multi-source/'non-aggregated' multi-source/

---

8.

   This section updates [RFC8407].

A fine statement as far as it goes, but probably should say just a 

little more. Maybe,

   This section updates [RFC8407] by providing text that may be 

   regarded as a new subsection to Section 4 of that document.  It

   does not change anything already present in [RFC8407].

---

8.1

s/Section Section 9.2/Section 9.2/

---

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? 

---

9.2 Figure 6 Table 2

There are some formatting errors in the Metric Type Tag part of the

table. Also a couple of minor ones in Multiple Source Tag.

---

OLD

Appendix C.  Targeted data object collection example

NEW

Appendix C.  Targeted Data Object Collection Example

END

From: netmod <[email-masked]> On Behalf Of Kent Watsen
Sent: 08 April 2022 19:10
To: [email-masked]
Subject: [netmod] WGLC on draft-ietf-netmod-node-tags-06

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

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)