Re: [netmod] mbj's WGLC review of module-tags-02

[Christian Hopps <[e-mail]>]

Martin Bjorklund <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod