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

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Oct 2018 16:20:32 +0200 (CEST)

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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 16 Oct 2018 14:43:31 -0400

> o  add boilerplate reference to RFC 8340

Done.

>   Use 8174 boilerplate

Done.

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

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

>    IETF standards track, the tags MUST also be IETF standard tags

Done.

>   I don't understand the last sentence.  What kind of augmentation do

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.

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

Done.

>   leaf-lists (and lists) usually have names in singular.

Ok I've adopted this.

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

>   only be visisble for the module?

Modules, I've changed the text.

>   Can I use *any* string as a tag?  No limitations at all?  Is ":"

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.

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

Done.

>   s/yang/YANG/

Done.

>   standard/vendor/user.  So, I suggest we change "local tags" to "user

Prior art, OK, Done.

>   and also write that if new tags are needed, they MUST be

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.

>   Remove the Editor's note.

Done.

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

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod