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

[Martin Bjorklund <[e-mail]>]

Hi,

Here are my (mostly editorial) WGLC comments on
draft-ietf-netmod-module-tags-02:


o  add boilerplate reference to RFC 8340

o  2

  Use 8174 boilerplate


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)

  And how are the tags supposed to be "automatically added"?

  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?

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).


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?



o  5.1

  OLD:

    The tree associated with the tags module is:

  NEW:

    The tree associated with the "ietf-module-tags" module is:


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.


o  5.2

 I think the YANG version should be 1.1.

 Add the standard boilerplate to the YANG module.


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?


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?


o  5.2

  The module should be consistently formatted wrt whitespaces.

  (e.g., you can try pyang --keep-comments -f yang)


o  6

  s/yang/YANG/


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".


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.


o  8.2

  Remove the Editor's note.


o  8.2

  Why have both ietf:rfc8199:service and ietf:network-service?


o  References

  You need to add RFC 7950 as a normative ref since you define a YANG
  module.



/martin