Re: [netmod] Module tags

[Juergen Schoenwaelder <[e-mail]>]

On Sun, Feb 12, 2017 at 05:59:40AM -0500, Christian Hopps wrote:
> a
> Juergen Schoenwaelder <[e-mail]> writes:
> 
> > On Sun, Feb 12, 2017 at 04:42:22AM -0500, Christian Hopps wrote:
> >>
> >> > Can you point me to a set of modules and a concrete query where this
> >> > makes sense? I am like Martin not yet convinced that there is a use
> >> > case for this.
> >>
> >> I gave the example of something that implements a common interface. So
> >> for example most IGP routing protocols have hello timers. One could
> >> imagine an "ietf:implements:hello-timer" (or whatever) tag. This type of
> >> thing is used to avoid the use of multiple-inheritance in OOP. It could
> >> serve a similar purpose with yang (although in this case it avoids having
> >> to factor all commonality out into tiny modules).
> >>
> >> I don't know if this would develop organically or not, but I do know
> >> having a central list eliminates the option. Why choose the option with
> >> less capabilities?
> >
> > I am asking for a concrete example. Assuming that modules will have a
> > common structure and naming inside is IMHO wishful thinking. Show me a
> > concrete example please using existing modules.
> 
> I did give an example: IGP hello timers. I feel it's unreasonable to
> expect me to be more concrete with existing modules when we are talking
> about creating a feature that would make commonality useful (!)
> 
> There are IGP models, they have common hello timers, the fact that these
> are placed in a common area simply has to do with the fact that there
> was no gain in doing so.
> 
> I've offered I think a valid use case that is well excepted and present
> in other areas of computer science, your saying no-one is doing this now
> with yang. To me that's like having java without the interface
> statement and then asking to be shown actual java code using the
> non-existent interface statement. There are yang models with common
> factorable structure now, I've given an example. If that's not enough I
> don't know what else I can do.

Sorry, a bunch of tags and an expectation of authors doing things in a
common way does not give you Java interfaces. I remain unconvinced and
there is no requirement that we agree on this use case being
realistic.  At least you seem to agree that for existing modules this
is not terribly useful and that future modules would have to follow
certain conventions to make things useful.

> >> >> Is there a way to get the reset to default behavior? We do allow the
> >> >> user to remove default set tags, so I think that's why Lou added that
> >> >> RPC.
> >> >
> >> > Note sure whether this (removing of non-configured tags) is a good
> >> > idea. Again, concrete use cases might help to make the point.
> >>
> >> I do want to support tag removal. The most obvious case for tags is for
> >> operator use, and the resulting tag set for any module should be under
> >> the control of the operator. A use case would be that some server has a bug
> >> in their implementation and the admin wants to remove it from possible
> >> use. I'd ask the reverse question, why take this control away from the
> >> operator?
> >
> > I am trying to understand the use case. If you are unhappy with the
> > default tags, why not add your own tags? This way, the operator has
> > full control over his tag space.
> 
> A model on a server is buggy for some tagged feature, I want to remove
> that tag from it on that server. Your suggesting rather than me be in
> control and simply remove that tag from that server, I need to not use
> that tag at all in all of my network, and instead create a new tag that
> I add to all the functional servers in my network leaving it off this
> single server.
> 
> Again why is this a big deal? What are you gaining by not allowing the
> removal of tags? As an operator I'm certainly losing something.

It was suggested (I think) that tags originate either (a) from the
data model it self, (b) from the implementation itself, (c) from the
operator. You want to be able to overwrite (remove) (a) and (b) tags?
Are tags not scoped by something that represents some form of
ownership? If so, does it make sense to step on other people's
carefully design tags? What if this creates conflicts for different
applications, some like to have a certain tag some don't?

Perhaps what you are requesting is useful but I think it needs a bit
more thinking and clarity about what tags mean and how tags are
scoped.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>