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 protected]> On Behalf Of Kent Watsen
Sent: 08 April 2022 19:10
To: [email protected]
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)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
