Martin Bjorklund <m...@tail-f.com> writes:
Hi,
Here are my (mostly editorial) WGLC comments on
draft-ietf-netmod-module-tags-02:
o add boilerplate reference to RFC 8340
Done.
o 2
Use 8174 boilerplate
Done.
o 4.1
A module definition SHOULD indicate a set of tags to be automatically
added by the module implementer.
I think statement doesn't belong here, but rather to section 7
(which also has this statement already)
When I remove that sentence the paragraph doesn't really read well. I have
slightly modified the text to adapt to use of a module-tag extension statement
though.
And how are the tags supposed to be "automatically added"?
In their code presumably. :)
As I have written in previous discussions, and others as well, I
think that you should define a YANG extension that can be used to
define the tags, instead of relying on description statements. Is
there a reason why you think an extension statement wouldn't work?
It just all seemed overly complex for indicating something that a human has to
add by hand anyway (in their code). I will add this as it seems to be a
sticking point that multiple people have requested as you indicate.
o 4.1
OLD:
If the module definition will be
standard the tags MUST also be standard tags (Section 3.1).
NEW:
If the module definition will be
IETF standards track, the tags MUST also be IETF standard tags
(Section 3.1).
Done.
o 4.3
Implementations MUST ensure that a modules tag list is consistent
across any location from which the list is accessible. So if a user
adds a tag through configuration that tag should also be seen when
using any augmentation that exposes the modules tag list.
I don't understand the last sentence. What kind of augmentation do
you mean?
Mentioned this in another reply, this is left-over text for when we had exposed
the module tags in mulitiple places (i.e., a read-only list through augmenting
yang library). I've removed the text as it's now confusing.
o 5.1
OLD:
The tree associated with the tags module is:
NEW:
The tree associated with the "ietf-module-tags" module is:
Done.
o 5.1
I know this has been discussed before, and Juergen wanted plural
names, but I propose the following structure:
+--rw module-tags
+--rw module* [name]
+--rw name yang:yang-identifier
+--rw tag* string
+--rw masked-tag* string
I prefer a container an the top level over a list. Also with the
list called "module", the key can be called just "name". And
leaf-lists (and lists) usually have names in singular.
Ok I've adopted this.
o 5.2
I think the YANG version should be 1.1.
But nothing in this module requires 1.1 features, so why restrict its use to
1.1 only?
Add the standard boilerplate to the YANG module.
Done.
o 5.2 leaf name
"The YANG module or submodule name.";
Do we really want to attach tags to submodules, or should the tags
only be visisble for the module?
Modules, I've changed the text.
o 5.2 type for tag
leaf-list tag {
type string;
Can I use *any* string as a tag? No limitations at all? Is ":"
special in a tag?
The only thing special in the tag is the prefix. The document is suggestive in it's use of
secondary ":"s; however, I see no reason to "over-specify" (i.e.,
over-complicate) this.
o 5.2
The module should be consistently formatted wrt whitespaces.
(e.g., you can try pyang --keep-comments -f yang)
Done.
o 6
s/yang/YANG/
Done.
o 6 and 3.3
When I read 3.3 I thought that the word "local" seemed odd, and was
going to suggest "user" instead. It seems 8199 also uses
standard/vendor/user. So, I suggest we change "local tags" to "user
tags".
Prior art, OK, Done.
o 7.1
The module writer may use existing standard tags, or use new tags
defined in the model definition, as appropriate. New tags should be
assigned in the IANA registry defined below, see Section 8.2 below.
Hmm, once the "new" tags are defined, they are IETF standard tags,
right? So this text should really be:
The module writer must use only IETF standard tags
and also write that if new tags are needed, they MUST be
registered.
The intention was that the module author could use non-standardized tags if the
module itself was not standardized. The text now reads:
The module writer may use existing standard tags, or use new
tags defined in the model definition, as appropriate. For
standardized modules new tags MUST be assigned in the IANA
registry defined below, see <xref target="sec-ietf-prefix"/>
below.
o 8.2
Remove the Editor's note.
Done.
o 8.2
Why have both ietf:rfc8199:service and ietf:network-service?
They are different. A network-service is something like a DHCP server. I've
added examples (NTP server, DHCP server, DNS server) to the description.
o References
You need to add RFC 7950 as a normative ref since you define a YANG
module.
I've added a reference to 6020, we can update to 7950 if there is some reason
to require YANG 1.1.
Thanks,
Chris.
/martin
_______________________________________________
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
