Hi,
Here are my comments for this draft.
I hope it can be completely quickly.
* sec 3.2: Vendor Tags
however, it is recommended that the vendor consider
including extra identification in the tag name to avoid collisions
(e.g., vendor:super-duper-company:...).
- Suggest standard text about choosing names with a low probability
of collision, like RFC 7950, 5.1:
Developers of module tags are RECOMMENDED to choose
names for their module tags that will have a low probability of colliding
with other vendor tags, e.g., by using the
enterprise or organization name as the second field name.
e.g., vendor:example.com:system-management.
* sec. 4.1 Module Definition Association
A module definition SHOULD indicate a set of tags to be automatically
added by the module implementer. These tags MUST be standard tags
(Section 3.1). This does imply that new modules may also drive the
addition of new standard tags to the IANA registry.
- Why can't a vendor specify its own tags.
- IMO, remove the sentence about MUST be standard tags.
* sec. 5.2 Tags Module
- a top-level list node is usually avoided, and a top-level container
is used instead.
- [major] there is no way for the client to retrieve the module-tags
list for the installed tags. A read-only version of the module-tags
list is needed (name, tag)
- how does a client know what tags the server will accept?
- how does a client know what values to put in the masked-tag
field?
** leaf-list tag (type string)
- a named type called "module-tag" would be better than an inline type
It will likely be reused.
- a minimum length of 1 would be better. (according to the
normative sections, the minimum length would be 5 for 'ietf:')
- a maximum length is likely to be enforced by an implementation.
It is useful for the client to know what a server must
support at a minimum (like 64 char names for YANG identifiers)
- a pattern specifying the exact allows chars and formats would
be better than a plain string
* sec 7.1 Define Standard Tags
- I do not agree that conformance requirements should be specified
for module tags. The underlying definitions already have conformance
specifications (e.g., if-feature, deviation).
- How are standard tags going to be decided?
Is this done by a design team, a WG, the IETF?
What level of consensus is required to create a new standard tag.
- I oppose using the description-stmt text to define module tags.
Machine-readable text should be identified as such.
YANG has an extension statement for this purpose:
extension module-tag {
description
"Specifies a module-tag associated with the module.
This statement is ignored unless it appears at the
top level of the YANG module.
The argument 'label' specifies the module tag value.";
argument label {
yin-element true;
}
}
Usage:
module example-module {
x:module-tag ietf:some-required-tag:foo;
x:module-tag ietf:some-recommended-tag:bar;
x:module-tag ietf:some-optional-tag:baz;
description
"[Text describing the module...]
RFC<this document> TAGS:
The following tags MUST be included by an implementation:
- ietf:some-required-tag:foo
- ...
The following tags SHOULD be included by an implementation:
- ietf:some-recommended-tag:bar
- ...
The following tags MAY be included by an implementation:
- ietf:some-optional-tag:baz
- ...
";
...
}
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
