Re: [netmod] Module tags

[Christian Hopps <[e-mail]>]

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.

>> >> 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.

> /js