Oppose adoption

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

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" <p...@juniper.net>
To: "Andy Bierman" <a...@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

Reply via email to