Re: [netmod] Module tags

[Christian Hopps <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> writes:

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

I agree it's probably mostly useful going forward.

My xpath foo isn't very strong, but given that both OSPF and IS-IS label
their hello interval timer nodes "hello-interval" I believe this xpath
would select those nodes from both models:

    //hello-interval[/tags="ietf:routing:igp"]

That said, the content does currently differ. For OSPF the node is the
integer timer interval whereas the synonymous interval for IS-IS is a child
node named "value".

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

Yes indeed tags can be created in 3 ways, but the ultimate authority is
the user as they are the ones actually deploying devices to implement
something (e.g., a network). The designer and implementer cannot
ultimately know how the user will use their devices and their modules. I
guess I'm drawing from my unix background here, give the user the rope;
I'm not sure how they would hang themselves with this particular rope,
but worrying about that seems to be the only reason to not give them the
control. :)

Thanks,
Chris.

> /js