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

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
>