Re: [netmod] Module tags

[Juergen Schoenwaelder <[e-mail]>]

On Sun, Feb 12, 2017 at 07:54:52AM -0500, Christian Hopps wrote:
> 
> 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".

See, either something is designed and guaranteed to mean the same or
it is not.  Assuming that something showing up at the same path was
designed to be the same can go seriously wrong. I wonder why an
operator would want to run a network on such weak premises.

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

Then there should only be type (c) tags. 

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

There are many things a device can implement differently. Do we
generally need a way to overwrite things? I am trying to understand
why tags are different and considered to require this ability. And as
I said, there is always the option to trust only the tags an operator
has assigned himself.

/js

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