[netmod] comments on draft-ietf-netmod-module-tags-01

[Andy Bierman <[e-mail]>]

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