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

Martin Bjorklund <mbj@tail-f.com> Tue, 16 October 2018 14:20 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5E017130DE8 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 07:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id O7BtWL-5_GqI for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 07:20:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com []) by ietfa.amsl.com (Postfix) with ESMTP id 128FF130DE4 for <netmod@ietf.org>; Tue, 16 Oct 2018 07:20:34 -0700 (PDT)
Received: from localhost (unknown []) by mail.tail-f.com (Postfix) with ESMTPSA id 4A6621AE0498 for <netmod@ietf.org>; Tue, 16 Oct 2018 16:20:33 +0200 (CEST)
Date: Tue, 16 Oct 2018 16:20:32 +0200
Message-Id: <20181016.162032.2229087452409342445.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/EAL4f8lUn6yjzpFbdOz2LakMffU>
Subject: [netmod] mbj's WGLC review of module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Oct 2018 14:20:36 -0000


Here are my (mostly editorial) WGLC comments on

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


   If the module definition will be
   standard the tags MUST also be standard tags (Section 3.1).


   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


    The tree associated with the tags module is:


    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


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

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

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