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

Christian Hopps <chopps@chopps.org> Wed, 17 October 2018 08:56 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34933129AB8 for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 01:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXGBe7LDbizF for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 01:56:08 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D18ED12DD85 for <netmod@ietf.org>; Wed, 17 Oct 2018 01:56:07 -0700 (PDT)
Received: from stubbs.int.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0A35E6005A; Wed, 17 Oct 2018 08:56:06 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <1539732745739.66497@Aviatnet.com>
Date: Wed, 17 Oct 2018 04:56:05 -0400
Cc: Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EE0B9CB-9A17-4460-89D6-9F5E15610720@chopps.org>
References: <b45d1c39-c2f0-bcaf-61a4-9822ac04725a@bogus.com> <1538612528590.11321@Aviatnet.com> <1635702A-FFB5-469B-8389-7AFD772BFB04@chopps.org> <1539732745739.66497@Aviatnet.com>
To: Alex Campbell <Alex.Campbell@Aviatnet.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6V8CEOQ1pS5jz4fIFR3tlG3d9UY>
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 08:56:10 -0000

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 <Alex.Campbell@Aviatnet.com> 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 <chopps@chopps.org>
> 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 <Alex.Campbell@Aviatnet.com> 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.
>