Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

Andy Bierman <andy@yumaworks.com> Wed, 07 February 2018 22:03 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605B5126D85 for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 14:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JSzuYAH_Jzq for <netmod@ietfa.amsl.com>; Wed, 7 Feb 2018 14:02:59 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 692D2124239 for <netmod@ietf.org>; Wed, 7 Feb 2018 14:02:58 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id x196so3514084lfd.12 for <netmod@ietf.org>; Wed, 07 Feb 2018 14:02:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MC2pn6E9YXqmMyeADqXWyWJyiIF+Z+zO+ciW01jheEA=; b=YbizLR2H8BTC9ibbl7OpGfjw4HB/vYcpb3ab22+0l+xc7sewiCvZXRETTKpYfT9sv5 tWSemV89Do4CoBcf8gh0Xxbx677eIz73uYtBtr7Jk6T38s/oksrbAt20EZeLaD0qC90j LtYEZqQcqZ+Hc8T1AfEyycmyxu+lALmNRYi3+aUwQTimiM1cjku+RbfYhmXnMTwYkowB r/sc2Fh54mNLTGc5eI4M5zv9T3vlW+/6IKQNcjILsrJP7YIH0PEm7VmaixElGbRf6prs 1VBBVqrF+deUNXanLPK7HmlhPTmfdRqW+hFJwfT+WmxFxEoZMZ/3rptzUWedSa/OB2Oe j6Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MC2pn6E9YXqmMyeADqXWyWJyiIF+Z+zO+ciW01jheEA=; b=K9bUxyJ9PY81wmK48hTgm06vOUMCUJ7ACj4h0gn7g7h5vqwEJhaIzPBWT7YJGtRQkb mMWtDeWQQwEmniVCbOnU9BkUirPfC7EfP3FOa1FxCkPr6Hm8cX05UGu/w5ZSkigzPCRh 5HA4nIR4xuIAauxs8y+A7NhUzQtWflfEVLp5eYlggREkBOREzo1aP+lOxt6xjymD7sD0 sfJnl/9MUtizhzvx1X/6scYKsHbuZZTHQNkfZqCpjegGIXpn9kE1jlG6xT/qWHxxiMY3 b186SObksZXgOmxMWe5ie3tzGSyykYfmYSG4qXd+GLt1y2ZUnG1nlNJ22AsUIKUCChh4 WMYw==
X-Gm-Message-State: APf1xPBiGlu9V4puQNuJPTRIe4Kxc0I9I1UybG0Lr2JgzwoT1zvKpR4i Tj2E+ckmjWD30pV6ozOdnMX53feqbZdTMTTxnTZV2Q==
X-Google-Smtp-Source: AH8x227X/VMq+QP+e4k0CazT6eX6YxxzyLZula2liIJdns/rDlwV2OYsIltkDRNRjY641j1kUYVvSiw14/F31r7xcDg=
X-Received: by 10.25.26.200 with SMTP id a191mr4495567lfa.35.1518040976622; Wed, 07 Feb 2018 14:02:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 14:02:55 -0800 (PST)
In-Reply-To: <201802071859.w17IxjwU073675@idle.juniper.net>
References: <CABCOCHQeganL9z8+QRbRvc-Y_jwVc7ZD0+-rd1yp4rhJfP-Kdg@mail.gmail.com> <201802071859.w17IxjwU073675@idle.juniper.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 7 Feb 2018 14:02:55 -0800
Message-ID: <CABCOCHSXGCAPQxxF7N-Bp=hx-ntRSgCzR-pbaebO6cBeYrJjrQ@mail.gmail.com>
To: Phil Shafer <phil@juniper.net>
Cc: joel jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401eda2a94100564a6758e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YFUUXD5dbm2FuwC7yo_uRolB2WE>
Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02
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: Wed, 07 Feb 2018 22:03:01 -0000

Hi,

Many good points.
IMO it will be difficult to agree on the details of this draft
without agreeing on the problem statement first.
As a process issue, this seems like an important step.
It is usually handled with WG charter text, but NETMOD
has a free pass on new YANG modules somehow.

I am interested in these tags as a new type of standard selection filter.
It can be applied to data retrieval, NACM rules, YANG push subtree
selection,
and probably many more use-cases.  So the problem statement
might be:

   There is a need for standardized mechanisms to classify YANG data nodes
with tags,
   which can be used in protocol operations to select matching data nodes,
based on tag values.
   This work includes the management and assignment of tags, and their
generalized use
   within protocol operations.


Andy


On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer <phil@juniper.net> wrote:

> Andy Bierman writes:
> >The draft avoids discussion of any useful operations based on tags.
>
> Nor does it really clearly say "what" is being tagged.  The absract
> talks about "used to help classify and organize modules", but the
> Introduction lacks any expansion on this.  There's really no clear
> problem statement or a clear definition of why we need tags or what
> one would use them for.
>
> It would also be helpful to understand why "#hashtag" and the string
> format ("ietf:routing", "vendor:super-duper:...") are chosen over
> YANG identities.  It seems like identity naming standards and inheritance
> would be good features.
>
> Also it's not clear why these would be configurable rather that
> controlled by the module author.  I'd rather have the OAM standard
> YANG module say something like:
>
>     module ietf-oam {
>         import "ietf-category" { prefix ietf-category; }
>
>         identify ietf-oam {
>             base ietf-category:ietf-standard;
>             description "This module category represents something
>                          OAM related.";
>         }
>
>         ietf-category:module-category ietf-oam;
>         ...
>     }
>
> The draft says:
>
>    Implementations that do not support the reset rpc statement (whether
>    at all, or just for a particular rpc or module) MUST respond with an
>    YANG transport protocol-appropriate rpc layer error when such a
>    statement is received.
>
> The entire idea of NETCONF/YANG is that the client _knows_ what it
> can safely send instead of tossing spaghetti at the wall until
> something sticks.  Avoid programming-by-error-detection, which
> creates fragile infrastructure.
>
> Use "feature" to control optional portions of a YANG module.  I'd
> suggest one feature for "reset" support and another for "read-only",
> since IMHO the idea of someone munging the categories of standard
> modules is, well, disconcerting.
>
> "Local" tags are not well explained.  The idea of a user/admin
> tagging modules means that something is broken.  Users shouldn't
> understand YANG modules.  Users use applications, some of which are
> home-grown.  Is "local" appropriate for my "audit interfaces" script?
>
> 6.1 is missing the list "module-tags".
>
> 9.1 advocates putting vital information in the description string,
> which is IMHO not a good idea.  We want to put as much information
> in machine-readable format as possible, so I can ask ietf.org
> questions like "give me a list of ietf-oam-related yang modules"
> and get a nice list.
>
> It also talks about "SHOULD" and "MAY" tags without giving any
> clue as to why or when this would be appropriate or useful.
>
> So my vote would be that this document needs some significant work
> and expansion before it's a supportable draft.  I think the authors
> have more in their heads than they've put into the draft and I'd
> like to see the rest of their thoughts.
>
> Thanks,
>  Phil
>