Re: [netmod] Module tags

[Christian Hopps <[e-mail]>]

Robert Wilton <[e-mail]> writes:

> On 14/02/2017 14:08, Christian Hopps wrote:
>> Robert Wilton <[e-mail]> 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. :)
> Of course, I still mean that the tags are applied to the module, but
> just that the place where that relationship is defined and maintained is
> not in the module itself. I.e. some central locations that map from
> unique module name to associated metadata tags.
>
> A roughly equivalent example might be perhaps like CDDB, where a program
> can take a CD track, and go and fetch the associated metadata from some
> known location without the metadata being embedded in the CD track itself.

Sure, but that is setup that way b/c the CD data is seen as read only
right? I don't think this is even the normal way to tag things. There
are tons of examples of the opposite where the item itself is tagged
(XML attributes, social media's #hashtags, cow ears, ...).

>>> 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?
> I was talking meaning the first case, where the tags are embedded in the
> definition of a module, that itself is embedded in a published standard.
>
>>   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.
> OK, today, it might seem obvious that the tags should be routing,
> protocol, igp, etc.  But in the future that choice of categorization
> might not be the best, but it will be resistant to change because some
> of the tag definitions are embedded in the modules themselves.
>
> Some of your suggested tags identify areas of IETF.  But what if those
> areas change over time, of the associated of drafts/WGs to particular
> areas changes.  A YANG module could end up being tagged with a stale
> area, and I doubt that anyone would want to update a standard to just
> update the tags.

Lou didn't like the area tags either, so perhaps those are just poor
initial choices, but "routing" (i.e., std tag "ietf:routing") is a fine
tag I think, so maybe we need to move more to this rather than the ietf
area groupings.

> So, I was wondering if it wouldn't be better to not allow tags to be
> embedded in the modules at all.  Instead, if this was maintained in a
> central database, e.g. like http://www.yangcatalog.org/, then the module
> authors could always email the maintainers of YANG catalog to agree with
> them how the module could most usefully be tagged in the catalog.  If
> this needs to change over time then this would seem to be much easier to
> update.

And then what happens to the modules that are deployed? I like having
some set of tags than are paired directly with the standardized module
specifically b/c they do not change.

We did leave things open, so you could also create a yang catalog tag
prefix and service as well.

Thanks,
Chris.

>>   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.
> OK, yes.  But I wasn't thinking so much of a particular vendor or
> operator, but more if the industry in general (or perhaps just the
> maintainers of the catalog) decided that different categorization would
> be more appropriate over time.
>
> Thanks,
> Rob
>
>>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> .
>>>>