Juergen
On February 12, 2017 8:04:55 AM Juergen Schoenwaelder
<[email protected]> wrote:
On Sun, Feb 12, 2017 at 07:54:52AM -0500, Christian Hopps wrote:
Juergen Schoenwaelder <[email protected]> writes:
...
> 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.
This is all about proving user controllable metadata for modules. Library
is a good existing example of providing what I mean by module metadata, but
its data is (rightly) not under user control. So one thing that is
"different" about tags is the user control of the metadata.
From a mechanism perspective, creating a config true module for module
metadata is fine - but personally, I still see the value of having module
metadata consolidated in yang library.
From a user perspective, the authors think the capability (including a, b,
c from above and complete ability to override the user) is useful - even if
we don’t agree on all aspects of how this mechanism is going to be most
used/useful down the road.
Please keep in mind that tags are data about modules, i.e. module metadata.
So the item/information being "configured" is another module. This is
another way in which tags are different than other modules and their
information.
Lou
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
