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

Andy Bierman <andy@yumaworks.com> Fri, 09 February 2018 21:57 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 8C2321270A3 for <netmod@ietfa.amsl.com>; Fri, 9 Feb 2018 13:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, 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 wClwwhngcgUo for <netmod@ietfa.amsl.com>; Fri, 9 Feb 2018 13:57:50 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 528911242F7 for <netmod@ietf.org>; Fri, 9 Feb 2018 13:57:50 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id r143so844034lfr.11 for <netmod@ietf.org>; Fri, 09 Feb 2018 13:57:50 -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=OyfmAUcSYr7kt9l59ThnBL81Ky4ITXh6cOXpgZGCpzo=; b=lUaI2n6r4+ylcT5XC0C7IRd3awxnZb9JZMmETrwJXVj2+vKUxDTfeC1THay/e1Yn6J t5PpktksDrRCSCwLsrn5PXor4Y7DSrt58IdwMxhxaMyM1bkTyq+QKQdjF4z/+5N2rm9a kPjZYe+BJVSVhSnGrm2fEnfJxRueSTVdupzD+vRKb9WwAIXhOUcceZS8wruA6jCITcIT pcsThk9nmCAivy4QPAFwRC0NH0JFxeNd0Fg5H6ziglugykwQdpdzxbK4wcKj9erqQEBG pJH9kOAmOOHPcx7pGDyJcY2BOXgSiOQAubsWCa0RfFpW2ctzEBrUZJ+nFi0dV+GKGo3e bh8w==
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=OyfmAUcSYr7kt9l59ThnBL81Ky4ITXh6cOXpgZGCpzo=; b=bZPVAEdm3g5TF0qz11TNwGdYnAHoRRocrV59QBhIN2Danzgx3UsG2eIpPOLxesbfCL Max8TjDMIlzZFpUlYY6hU+fXYNbrdfoORDsC/fOfWCo3ot8eUrwmkB8cowoEEWbewcvL XNOHjQZuA79LbUQcSDh+O13siIITxtATNsW0sTZxDqsxess7cpLIs/zAbZ8t5vzkw0Gd 3Z/s7hJp9cCl9NN4ru7ThEJSRqWRV8zIPwa6Umeu4Pc1QcpHT/apM1NxGCxTgHUt8zrP H9ZgZW0g6yJKIa8KtA2BiN2O9OxsKzHN55Nc93XYW9Bq/Uv2FfpMQpfBLFeJgE3Vh1d2 WKwA==
X-Gm-Message-State: APf1xPBdCnD3/qsltj1kaqkYDu901kgR5/mtK+e93eO0IlLhIqS961kz GUvuGkvzHyR1o2KSDz6vhcPE+kGu0NqV5UhLDrY+pC9j
X-Google-Smtp-Source: AH8x227INa+f9WxQZsZyNTv3w/mSC++JMifRs4E3E81pgklJB9Yg/lCwfWcKaLzB/jLEC5b79eaZ8/AiJYjhcQYd6CI=
X-Received: by 10.25.20.168 with SMTP id 40mr2948936lfu.23.1518213468487; Fri, 09 Feb 2018 13:57:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.225.18 with HTTP; Fri, 9 Feb 2018 13:57:47 -0800 (PST)
In-Reply-To: <026201d3a1b9$9e7ead00$4001a8c0@gateway.2wire.net>
References: <201802071859.w17IxjwU073675@idle.juniper.net> <026201d3a1b9$9e7ead00$4001a8c0@gateway.2wire.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 9 Feb 2018 13:57:47 -0800
Message-ID: <CABCOCHRtfCESeRE70NgGY93wzGx4DdWzpPbDaFPGVZyuOoVbCA@mail.gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: NETMOD Working Group <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a113fb1187b99d60564ce9eca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/bBAAsuuvnhS-3sq-czCbm-CxC40>
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: Fri, 09 Feb 2018 21:57:54 -0000

On Fri, Feb 9, 2018 at 7:19 AM, t.petch <ietfc@btconnect.com> wrote:

> Oppose adoption
>
> As others have said, there is a lack of a problem to solve.
>
>

Actually, I see eventual value in the tags themselves if:

   - each tag is defined with a YANG identity
   - there is standard filtering based on derived-from-or-self
   - the standard tags are maintained in an IANA module (iana-yang-tags)
   - there is a standard YANG extension yt:module-tag that can be used to
assign
     tags to an entire module
   - there is a standard YANG extension yt:data-tag that can be used to
assign
     tags to a YANG data subtree
   - standard YANG modules include appropriate tagging

IMO it is similar to iana-if-types, which is much better than each vendor or
each operator assigning all the code-points.

It would be a lot of work to come up with a good set of standard tags
but it seems there are people willing to work on that.


Andy



When I ask users of a technology that uses #hashtags where they come
> from, how they come into being and similar elements of procedure, I
> never get an answer.  #hashtags seem to be provided to allow a storm to
> gather on social media, around some vague idea, in order to put pressure
> on someone or something that would otherwise be unjustified:-)
>
> The tags listed in Section 10.2 seem just as vague and I do not see a
> role for something somewhat ill-defined in YANG.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Phil Shafer" <phil@juniper.net>
> To: "Andy Bierman" <andy@yumaworks.com>
> Cc: "NETMOD Working Group" <netmod@ietf.org>
> Sent: Wednesday, February 07, 2018 6:59 PM
> Subject: Re: [netmod] Adoption Poll:
> draft-rtgyangdt-netmod-module-tags-02
>
>
> > 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
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>