On Fri, Feb 9, 2018 at 7:19 AM, t.petch <ie...@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" <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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
