Re: [netmod] Module tags

Christian Hopps <chopps@chopps.org> Tue, 14 February 2017 14:08 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 C9388129660 for <netmod@ietfa.amsl.com>; Tue, 14 Feb 2017 06:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 vZTUf7oZTWaz for <netmod@ietfa.amsl.com>; Tue, 14 Feb 2017 06:08:16 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F912964E for <netmod@ietf.org>; Tue, 14 Feb 2017 06:08:16 -0800 (PST)
Received: from tops.chopps.org (97-83-46-222.dhcp.trcy.mi.charter.com [97.83.46.222]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 65F70623E9; Tue, 14 Feb 2017 14:08:15 +0000 (UTC)
References: <87r338gtzw.fsf@chopps.org> <20170209.085506.1418859449501855827.mbj@tail-f.com> <878tpfac43.fsf@chopps.org> <20170209.120823.198284779081114388.mbj@tail-f.com> <874m03a74p.fsf@chopps.org> <15a22d86378.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <72728899-a310-b43e-65dd-7623135c5fba@cisco.com>
User-agent: mu4e 0.9.19; emacs 25.1.1
From: Christian Hopps <chopps@chopps.org>
To: Robert Wilton <rwilton@cisco.com>
In-reply-to: <72728899-a310-b43e-65dd-7623135c5fba@cisco.com>
Date: Tue, 14 Feb 2017 09:08:13 -0500
Message-ID: <87mvdo986q.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Hx3TW_6jxpdgPjKvQh-nywEVB9w>
Cc: netmod@ietf.org
Subject: Re: [netmod] Module tags
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Feb 2017 14:08:18 -0000

Robert Wilton <rwilton@cisco.com> writes:

> Hi tags draft authors,

> On 09/02/2017 12:28, Lou Berger wrote:
>>
>> I'm personally more excited by the use of tags as additional module
>> meta-data accessible via yang library. But also see no reason to
>> preclude this possible  (even if unlikely) usage.
>
> When the idea of tags was presented as IETF, I had assumed that tags
> would be versioned/managed entirely independently from the YANG modules
> that the tags apply to.

Well they are called "tags" after all.  Normally one applies a tag to
something (i.e., tags it. :)

> For a while, there was a desire to organize YANG modules by their
> hierarchical path location in the schema tree.  My concern with this
> approach, is that there needs to be sufficient foresight to get that
> structure right now, because it will be very painful to change it in
> future.  Unfortunately things have a habit of evolving over time, and
> hence choosing the right structure now such that is still the right
> structure in 25 years seems somewhat unlikely.
>
> I was thinking that tags offers a better solution to this problem, that
> allows the structure to be a bit more dynamic, evolving over time.  I.e.
> YANG modules for features can sit at (or near to) the top level of the
> schema tree, and tags can then be used to group those modules into
> sensible organizations that can evolve, so that when clients are trying
> to sort through all the different YANG models that are available, they
> have more hope than looking at a flat list.

We in fact plan to do this with the device meta model. I believe this
was in the presentation too, but it might not have been very obvious.

> In this scenario, I think that it is better if the YANG module
> definitions themselves don't specify the tags because then
> adding/removing/changing them is going to be a pain.  If this tag
> information was managed separately (e.g. in something like YANG catalog)
> then it seems easier for the tags to evolve over time.

I want to be sure I understand you here. We've defined 3 places that a
tag could be defined (comes into existence), the module designer, the
vendor and the local user. When you say "module defines" are you talking
about the first case, or are you talking about where a tag resides after
it is created? For the latter that was our intention with the yang
library augmentation. For the former case consider e.g., IS-IS, I think
the authors of that module know and are the appropriate folks to add
categorization tags such as "ietf:routing", "ietf:protocol",
"ietf:routing:igp" or whatever. Nothing would keep the user or vendor
from removing these or adding their own tags for the same purpose as
well if they found these inappropriate or incorrect.

> But I also had not really realized that the tags information would
> necessarily reach down to the devices.  I.e. I hadn't envisaged Chris's
> example of querying the hello-time via an IGP package tag. Instead, I
> had thought of tags making a YANG catalog website more useful.  E.g.
> when browsing for YANG modules, be able to restrict the query to just
> the modules that are tagged as "standard" + "IGP", etc.
>
> So, I think that this draft may benefit with a bit more description of
> the envisaged use cases, and also about how tags are envisaged to evolve
> once they have been defined.

Well one goal I had with tags was to allow for them to be used in
the future in ways we may not have anticipated. Therefore
we specifically did not lock down how they are used or what they are
used for. That said, examples of how one might use could be helpful.

Thanks,
Chris.

> Thanks,
> Rob
>
>>
>> Lou
>>
>>
>>> Thanks,
>>> Chris.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>