Hi,
The server implements the tags (at least the predefined ones), and the use
cases that come to my mind at least involve clients not servers.
I assume that the server here is a network element implementing
ietf-module-tags.
I still don't see why network elements should implement ietf-module-tags.
What benefit is gained from storing the tags on the server instead of the
client? It seems backwards.
Have I misunderstood? I assumed that ietf-module-tags was meant to be
implemented by network elements that are NETCONF servers - but now I see the
document doesn't actually specify who is meant to implement the module. Your
comment about newly installed routers supports my understanding however.
I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules
is exactly the point of pre-defined tags, but you questioned their value at the top of
your mail.
The problem with pre-defined tags is that they are never complete. I can always
find a useful tag that is not pre-defined.
Either way configuring a newly installed router is a given, I don't think this is the
place to solve the "forgot to add all the config to my new router install"
issue. :) If one is using tags in ones network then making sure the newly installed
router has tags configured the way you expect is no different from making sure that you
configured IS-IS correctly.
The reason I find this problematic is the same as above - that the router has
no use for the tag data.
It's as if my PC were to download its keyboard mapping table from my home
router. Then I change ISPs and have to swap the router, and suddenly my
keyboard doesn't work correctly.
It would be much better to store the keyboard mapping table for my PC *on my
PC* instead of adding needless external dependencies.
Alex
________________________________________
From: Christian Hopps <[email protected]>
Sent: Wednesday, 17 October 2018 9:56 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 -
10/16/18
The point is to keep this open to however the community might end up choosing
to use it. The act of pre-defining tags doesn't disallow other tags being
defined, in fact at this point I've sent a bunch of email defending leaving
things as open as possible. They both can co-exist. :)
Thanks,
Chris.
On Oct 16, 2018, at 7:32 PM, Alex Campbell <[email protected]> wrote:
I have no issue with systems using tags to classify or organize modules,
however this seems to me like something that would be specific to the system
doing the classifying.
Sure we support this. That's what user tag configuration is there for.
It would not be something that needs to be specified in the module itself
(except perhaps as freeform description text), and it certainly would not need
to involve the NETCONF server.
What would a server do with module classification data? (unless it is also
implementing some kind of module browsing interface, in which case it might be
used to supply the browser with data)
The server implements the tags (at least the predefined ones), and the use
cases that come to my mind at least involve clients not servers. I'm not saying
there wouldn't be a server use case, but it's not as obvious to me.
And yes implementing some kind of module browsing interface (which could group
modules by tags) is a fine example of how tags can be used.
Hashtags - all types, that I'm aware of - are inherently freeform and fluid, changing
quickly according to the desires of users. I don't think it makes sense to
"hard-code" them in published RFCs or even published vendor modules or firmware.
Tomorrow, I might want to list all modules for management plane protocols. As a
network operator, should I go and update the ietf-module-tags on all of my
network elements? That seems silly. This should be client-side data. (And if I
did, what happens when I add a new router and forget to update its tag data?
Will that confuse the client?)
I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules
is exactly the point of pre-defined tags, but you questioned their value at the top of
your mail.
Either way configuring a newly installed router is a given, I don't think this is the
place to solve the "forgot to add all the config to my new router install"
issue. :) If one is using tags in ones network then making sure the newly installed
router has tags configured the way you expect is no different from making sure that you
configured IS-IS correctly.
Thanks,
Chris.
Regards, Alex
________________________________________
From: Christian Hopps <[email protected]>
Sent: Wednesday, 17 October 2018 1:04 a.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 -
10/16/18
On Oct 3, 2018, at 8:22 PM, Alex Campbell <[email protected]> wrote:
The introduction does not explain what they are useful for
The second sentence of the abstract: "The expectation is for such tags to be used to help
classify and organize modules." The introduction repeats this in the first sentence. I'm not
sure how much differently we could say "Tags are useful for organizing and classifying
modules". Are you asking for justification on the usefulness of organizing and classifying
things? I think this concept is rather widely accepted.
, it just makes a comparison to #hashtags (which is something I would expect to
see in an April 1st RFC).
Using tags to help organize collections of data is literally ubiquitous:
Movies/music/media, IP routes, and yes even social media are just a few
examples. Regarding April 1st, are you are unfairly restricting your
perspective to only the ironic use of hashtags? Hashtags organically developed
as a useful and widely used way for people and groups to add meta-data to their
messages which then allowed other services to collect and present them in
useful ways. Indeed businesses and other groups use hashtags for this purpose
to great success. It was hardly a joke, and for many folks it is immediately
useful to understand what is being proposed.
Thanks,
Chris.
