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

[Qin Wu <[e-mail]>]

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:[e-mail]] 代表 Adrian Farrel
发送时间: 2022年4月13日 5:36
收件人: 'Kent Watsen' <[e-mail]>; [e-mail]
主题: 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 XXXX 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 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.

[Qin Wu] Thanks, the proposed change looks good.
---

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.

[Qin Wu] Accepted, thanks.
---

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.
[Qin Wu] I think IETF tag is register while vendor tag not, I will add text to clarify.
---

7. multi-source-tag

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

[Qin Wu] Accepted.
---

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

[Qin Wu] works for me.
---

8.1

s/Section Section 9.2/Section 9.2/

[Qin Wu] Fixed.
---

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’?
---

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.

[Qin Wu] Fixed.
---

OLD
Appendix C.  Targeted data object collection example
NEW
Appendix C.  Targeted Data Object Collection Example
END

[Qin Wu] Fixed, thanks.
From: netmod <[e-mail]<mailto:[e-mail]>> On Behalf Of Kent Watsen
Sent: 08 April 2022 19:10
To: [e-mail]<mailto:[e-mail]>
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)