Re: [netmod] EXTERNAL: Re: WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps <[e-mail]>]

Alex Campbell <[e-mail]> writes:

> Capabilities, features and deviations indicate the type of requests the router can respond to.
>
> The capability advertisement may not affect the router, but the capability itself directly does.
> The capability advertisement tells the client that the router can answer requests involving the capability in question.
>
> Will clients base their behaviour on module tags, such as fetching all modules with a particular tag?

It depends on what the tag/meta-data is! This is a way to add meta-data, but we aren't restricting or strictly defining how one will *use* the meta-data on purpose. Tags are meant to be a tool that can be used in many ways even some yet unimagined ways.

> In that case, as a vendor, I do not understand the implications of adding or removing a tag and I would prefer if the RFC was clearer on that point.

So as a vendor don't add or remove tags you don't understand.

This is a general purpose tool we are adding here, the ability to associate tag/meta-data with a module. There are some uses that we can think of now (e.g., from the definition side classifying the origin of a module as IETF or OpenConfig, or from the client side marking a module as "dontuse" for an NMS b/c they found bugs with it on a given device. And there will be uses that are dreamt up later.

The point here is to put in place a way to associate tags with modules, not to restrict how they are used.

Thanks,
Chris.

> ________________________________________
> From: Christian Hopps <[e-mail]>
> Sent: Thursday, 18 October 2018 11:16 p.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: EXTERNAL: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
>
> A router has no use for it's capability/feature/deviation advertisements either; module-tags are no different in this respect.
>
> Thanks,
> Chris.
>
> Alex Campbell <[e-mail]> writes:
>
>> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]> 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.
>>>