Hi, Adrian:
-----邮件原件-----
发件人: netmod [mailto:[email protected]] 代表 Adrian Farrel
发送时间: 2023年4月26日 6:10
收件人: 'Kent Watsen' <[email protected]>; [email protected]
主题: Re: [netmod] WGLC on node-tags-09
Hi,
I have reviewed this draft during the normal working group process, and I just
re-read it as part of working group last call. I believe the function defined
is useful, and
I think the draft is ready to advance towards publication once my list of
small points have been addressed.
Cheers,
Adrian
== Discussion ==
Section 7.
I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown in
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!
The alternatives might be:
1. You simply use the tag as a string (i.e., using the typedef tag) and
rely on implementations to know what the tag type means.
2. You change the identity to an Integer, and you include an integer in
the IANA registry so that new tags are just new entries.
3. You move the base identity into an IANA-managed YANG module that is
updated by IANA automatically in lockstep with the IETF tags registry
[Qin Wu] Good comment, Andy also raised similar comment, the motivation of
introducing
node-tag-type identities is to address Jurgen’s comment and try to make the
node tag mechanism
generic enough and allow future extension, we did provide an example in
Appendix A which allow you add additional Auxiliary Data Property in the module
extension.
one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA registry,
but
node-tag-type identities will not be registered together with IETF YANG Data
Node Tags. Secondly, we did use tag as a string, we choose to use the same
typedef tag used for module tag, now for node tag.
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it doesn’t
allow any future module extension.
2. we keep some of these identities for second level data node classification,
e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter
,delay identities from this draft since it seems to
duplicate with what has already been defined in IANA registry, in addition, we
remove some of IETF yang data node tags including summary, counter, gauge and
unknown, which is redundant with identities
for second level data node classification.
== Minor ==
idnits reports some minor issues...
** There are 4 instances of too long lines in the document, the longest one
being 7 characters in excess of 72.
== Unused Reference: 'RFC6022' is defined on line 834, but no explicit
reference was found in the text
== Unused Reference: 'RFC8641' is defined on line 871, but no explicit
reference was found in the text
== Unused Reference: 'RFC9195' is defined on line 880, but no explicit
reference was found in the text
== Unused Reference: 'RFC9196' is defined on line 884, but no explicit
reference was found in the text
[Qin Wu] Fixed, thanks
--
I think that Section 1, in introducing the concept of tags, should spend a
sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG
tags already exist, and how this work develops the idea.
[Qin Wu] I think we have already done this, see relevant text in section 1 as
follows:
“
To that aim, this document defines a YANG module [RFC7950] that
augments the YANG Module Tags ([RFC8819]) to provide a list of node
entries to add or remove node tags as well as to view the set of node
tags associated with specific data nodes or instance of data nodes
within YANG modules.
”
--
Apart from being able to deduce it from Section 4.3, it is not absolutely clear
from Section 4 that the colon has special meaning. That is that all prefixes
now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish an
non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
supposed to use a colon - you should clarify that all prefixes end
with a colon noting that the colon is not a separator but is part of
the prefix. This does beg the question about separators in the
prefixes and in the tag values
- Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
- Tag values (after the prefix) that contain colons may cause
confusion so you should probably make this a RECOMMENDation,
although 4.2 suggests the use of colons as further separators.
An alternative to all this is that you define the colon as the separator, and
change the tag names to not include colons.
But 9.1 makes it pretty clear that you expect all registered prefixes to end
with a colon.
[Qin Wu] That’s really a good comment, so Tag = Tag prefix+ Tag Value,
Colon is part of Tag prefix if you expect all registered prefix to end with a
colon.
The question is whether we see colon as separator or portion of the tag prefix.
Do we need to make tag prefix is mandatory to have for a tag?
--
4.1
9.2 constrains these tags by saying that they must "conform to Net- Unicode as
defined in [RFC5198], and shall not need normalization". I think you should
state this in this section using BCP 14 language.
[Qin Wu] How about the following change:
OLD TEXT:
“
An IETF tag is a node tag that has the prefix "ietf:".
All IETF node tags are registered with IANA in the registry defined in Section
9.2.
”
NEW TEXT:
“
An IETF Tag is a node tag that has the prefix "ietf:".
All IETF Node Tags are registered with IANA in the registry defined in Section
9.2.
These IETF Node Tags MUST conform to Net-Unicode as defined in [RFC5198], and
SHOULD not need
normalization.
”
--
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:entno:vendor-defined-classifier).
Surely you have to go further than recommending? How will interop work unless
you require 'entno' to be present?
But here you have said "enterprise or organization name" and then used a field
called 'entno' which looks very much like an Enterprise Number as registered by
IANA (RFC2578) which would, IMHO, be a good solution.
[Qin Wu] Correct, the motivation is to use additional enterprise name to avoid
collision,
Do you think I should add reference to RFC2578?
--
4.4 looks reasonable to me, but I think you need to add text to talk about how
an implementation is supposed to handle a tag prefix it doesn't know (for
example, one that is defined and added to the registry after
[Qin Wu]
the code was released). I suspect the intention is that all tags can be
processed as opaque strings, and the prefixes are there in order to achieve
uniqueness of the strings, but do not need to be processed.
Thus all implementations should be able to process all tags regardless of their
prefixes.
[Qin Wu] Your understanding is correct, maybe add one more sentence at the end
to say:
“
Therefore an implementation SHOULD be able to process all tags regardless of
their prefixes.
”
--
5.2
An implementation MAY include additional tags associated with data
nodes within a YANG module. These tags SHOULD be IETF ((i.e.,
registered) ) or vendor tags.
It would be good to:
- Expand on the "MAY" to say why an implementation might do that
[Qin Wu] I think section 5.1 emphasizes adding tag at the module design stage
while section 5.2
Emphasizes that we can adding additional tag at the implementation stage, e.g.,
vendor A want to add some vendor specific tag, Vendor B want to add some other
IETF tag that allow two vendors interoperable.
- Add an alternative to the "SHOULD" and an indication of why an
implementation might vary from the "SHOULD".
[Qin Wu] How about the following change:
NEW TEXT:
"
An implementation MAY include additional tags associated with data
nodes within a YANG module at the implementation time. These tags SHOULD be
IETF ((i.e.,
registered) ) or vendor tags. IETF tags allows better interoperability than
vendor tags.
"
--
8.1 is intended as a new section of RFC 8407 so I think it should be possible
to read it like that. I suggest re-writing as follows.
Note:
- Leaving out the figure number to be consistent with RFC 8407
- Making the reference to Section 9.2 point to this document explicitly
8.1. Define Standard Tags
A module MAY indicate, using node tag extension statements, a set of
node tags that are to be automatically associated with nodes within
the module (i.e., not added through configuration). For example:
module example-module-A {
//...
import ietf-node-tags { prefix ntags; }
container top {
list X {
leaf foo {
ntags:node-tag "ietf:summary";
}
leaf bar {
ntags:node-tag "ietf:loss";
}
}
}
// ...
}
The module writer can use existing standard node tags, or use new
node tags defined in the data node definition, as appropriate. For
IETF standardized modules, new node tags MUST be assigned in the IANA
registry defined in Section 9.2 of RFC XXXX.
[Qin Wu]:The proposed text is much clear, thanks.
---
9.2
Since you want the DE to look at this, I think you need:
OLD
The allocation policy for this subregistry is IETF Review [RFC8126].
NEW
The allocation policy for this subregistry is IETF Review with Expert
Review [RFC8126].
END
[Qin Wu] Okay.
--
11.
I think 5198 is a normative reference as you require ietf: tags to comply.
[Qin Wu] Good catch and will fix.
== Nits ==
Section 1
This document defines tags for both nodes in the schema tree and
instance nodes in the data tree and shows how they can be associated
with nodes within a YANG module, which:
* Provide dictionary meaning for specific targeted data nodes;
...
Slightly confusing. I think the bullets are intended to apply to the tags.
I.e., the tags provide dictionary meaning...
But the text reads like it is the nodes (or possibly the YANG module) which
provides the meaning.
So possibly you need:
This document defines tags for both nodes in the schema tree and
instance nodes in the data tree, and shows how the tags can be
associated with nodes within a YANG module, to:
* Provide dictionary meaning for specific targeted data nodes;
...
[Qin Wu] The proposed change looks good, thanks.
--
1.
OLD
To that aim, this document defines a YANG module [RFC7950] that
augments the YANG Module Tags ([RFC8819]) to provide a list of node
entries to add or remove node tags as well as to view the set of node
tags associated with specific data nodes or instance of data nodes
within YANG modules.
NEW
To that aim, this document defines a YANG module [RFC7950] that
augments the YANG Module Tags ([RFC8819]) to provide a list of node
entries to which add node tags or from which to remove node tags, as
well as a way to view the set of node tags associated with specific
data nodes or instance of data nodes within YANG modules.
[Qin Wu] Okay.
--
3.
s/data nodes repositories/data node repositories/
[Qin Wu] Fixed
--
4.
Initially, three prefixes are defined.
Maybe...
Three prefixes are defined in the subsections that follow.
--
[Qin Wu] Okay.
6.1
s/is as follows/as shown in Figure 1/
[Qin Wu] Okay.
--
7.
s/"RFC 8819: YANG Module Tags ";/"RFC 8819: YANG Module Tags";/
[Qin Wu] Okay.
--
8.1
s/associated with node/associated with nodes/
[Qin Wu] Okay.
--
9.2
Figure 4 has some text alignment issues
--
9.2
OLD
A data node can contain one or multiple node tags.Data node to be
tagged with the initial value in Table 2 can be one of 'container',
'leaf-list', 'list', or 'leaf' data node. All tag values described
in Table 2 can be inherited down the containment hierarchy if Data
nodes tagged with those tag values is one of 'container', 'leaf-
list', 'list'.
NEW
A data node can contain one or multiple node tags. A data node to be
tagged with an initial value from Table 2 can be one of 'container',
'leaf-list', 'list', or 'leaf'. All tag values described in Table 2
can be inherited down the containment hierarchy if the data nodes
tagged with those tag values is one of 'container', 'leaf-list', or
'list'.
END
[Qin Wu] Fixed.
--
11.
s/Berger,Jaehoon/Berger, Jaehoon/
[Qin Wu] Okay.
== Petty comments ==
Section 1
"fairly ubiquitous"
Ubiquitous is an absolute state. You cannot be "somewhat pregnant" or "slightly
dead".
You probably want "widespread" or "used extensively".
[Qin Wu] okay, I prefer to use “widespread”
--
3.
The following lists a set of use cases to illustrate the use of node
tags.
It's not really a list. It's OK that it is not many examples, but the text
implies we might be going to see a few. How about:
The following describes some use cases to illustrate the use of node
tags.
[Qin Wu] Okay.
--
9.2
Why does "IETF Node Tags" have a capital 'N' when "YANG node Tag" and "YANG
node Tag Prefixes" use a lower case 'n'?
[Qin Wu] Good catch, we can make it consistent to use Capital in all places.
-----Original Message-----
From: netmod <[email protected]> On Behalf Of Kent Watsen
Sent: 19 April 2023 03:00
To: [email protected]
Subject: [netmod] WGLC on node-tags-09
This email begins a two-week WGLC on:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
Please take time to review this draft and post comments by May 2nd.
Favorable comments are especially welcomed.
This draft went through a WGLC a year ago. The authors addressed the
comments received and have been were waiting for feedback. In essence,
this draft is presumed to reflect WG consensus and thusly, if no objection is
received, the draft will move to the next step in the publication process.
Ref:
https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/
Kent // co-chair
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
