Re: [netmod] Module tags

[Robert Wilton <[e-mail]>]

On 14/02/2017 16:30, Christian Hopps wrote:
> 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, ...).
It will be easier to change the tag on a cow ear than on a standardized 
YANG module, but I like your example ;-)

It is outside my area of expertise, but I expect that most of the 
meta-data associated with a cow is not attached to the cow itself, but 
stored in some database somewhere.  The cow ear tag is more so that you 
can identify the right cow in the database.

>
>>>> 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.
I think that the WG area tags could be useful for someone that is trying 
to categorize YANG models by IETF area.    But my main point is that if 
we decided that they were a good idea now, but not such a great idea in 
5 years time, going back and changing (or removing) them is painful if 
they are baked into the models.

>
>> 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.
This goes back to my questioning as to whether tags should actually 
extend to the devices themselves, or just live in the manageability 
layer of YANG modules.

E.g. an operator could maintain a local database of tags associated with 
the modules that they use.  This database would initially be sourced 
from a central place, but could be refined/updated however the operator 
liked.  Tag based queries could be build in the operators mgmt systems, 
but would be converted to equivalent regular queries (with appropriate 
subtree filters) before being sent to the device.

Thanks,
Rob

>
> 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
>>>>> .
>>>>>