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

Andy Bierman <andy@yumaworks.com> Mon, 16 April 2018 20:26 UTC

Return-Path: <andy@yumaworks.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 34FA812704A for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 13:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yeUCGCGlUWAv for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 13:26:07 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D93C126CE8 for <netmod@ietf.org>; Mon, 16 Apr 2018 13:26:07 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id v207-v6so24020051lfa.10 for <netmod@ietf.org>; Mon, 16 Apr 2018 13:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=MccExldum3VAGNPEJMXkAkoHn7cGRhTUy8YrJIe4tZ8=; b=yCNToPLY1deNTh27q3L2Mm8BIiOmy5GijxSozuMHFOZTQ7+558SA/ZSP/O9CBbDqyh yQ3lTGNTj8FfxaZyx5nZtj5o9/4TVETvMOgwG18ysNRGt9DILf3zmmMZyloVGByP84tT MkHagfCCLPtreJ0+92h/B1h9r3asWrOgCwwROScQlgqj4OPQXNSLgXMDg49bFEb2ZiY9 QuyMR/mr1RNLvgZC2ia6xv+GnbWfK4NkhQczg4fn8/HCfR9I8qdPxCLv5abrQPBFBhxM wlLGvZro1CmqSYej9gvl6rTJ5DGDwIf2r1VimKRJeBn5wOoZZcVsxSjKY0LixiYgrgm/ kB4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MccExldum3VAGNPEJMXkAkoHn7cGRhTUy8YrJIe4tZ8=; b=gzdeXfXI0kbIhKk+2yW3ttlwgc61KxKry06kZRSQdWnzlJI5NOuMXfmBDLvHxo67SC 2wGqHoDFPlddTGjlZ9kd+fwpv2LECTQmw3/1pmvCfyGO3/fiRR5pdfYiCcfGbacsnPMv 0ejr4PRAK/CjWMO63Bw50NZXnLqhB8zzcogovikLi2J0pgQtgZ7sgol4wbu6fACAAbEh 7RvlVgTrvO+omGYmjbSIgxOnMsWAm1s4ZE8pMIjTR0A/9naD3dxLFq9sI01ERXSGfgyH 66Cc6h4br4njkwo4B17FgCl8re92BVJpBjuHcrHCx7re1zz97CqpNV7W5Gxzj0K6OWjz mzGg==
X-Gm-Message-State: ALQs6tBDu0jarjLw6UzB7VjPj2d3lE9z1vvSp3tCcGtdVBDyr5eOfJAA S+zkqXQfD4pebR+A0wGDSgE+8UtyydxN8U8uy11qSUWw
X-Google-Smtp-Source: AIpwx4+WE1WBW+73OyX3aZ5YxpE2Gm0H7ho9998W6c46AtRngWUc6iDTAC9yE98ZSqMS1QuDY0fQP3At4H/qirCPB9Y=
X-Received: by with SMTP id a10mr2334884ljd.78.1523910364704; Mon, 16 Apr 2018 13:26:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 13:26:03 -0700 (PDT)
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 16 Apr 2018 13:26:03 -0700
Message-ID: <CABCOCHSK8Tinjyu+5CnDSYPsMwb1YibQ52PvtoCEXf3B==-Mnw@mail.gmail.com>
To: NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="089e082b3ee8f551030569fd0742"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YY_4hS-aXGro8sqsjJOP7cUfn04>
Subject: [netmod] comments on draft-ietf-netmod-module-tags-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Apr 2018 20:26:10 -0000


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

 ** 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 {
         "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;


         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;

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