Subject: [netmod] Module tags [Re: Augmenting an unimplemented module]

From: Christian Hopps <[email-masked]>
Date: Wed, 08 Feb 2017 16:29:10 -0500

Martin Bjorklund <[email-masked]> writes:
> Juergen Schoenwaelder <[email-masked]> wrote:
>> On Wed, Feb 08, 2017 at 01:22:01PM -0500, Christian Hopps wrote:
>> >
>> > The tags in the library and the tags in a module are updated at the same
>> > time and represent logically the same list of tags. Its clear this
>> > happens with an RPC. It seems a lot less clear this would (or should)
>> > happen if one edited only once location.
>>
>> I am not convinced by the design. We have lots of other resources
>> where we have configured and system determined values. I do not see
>> that tags are any different.
>
> I agree.  *If* you want a config true datastructure, it should be
> modified with the normal edit operations, not special RPCs.  There are
> several reasons for this.  For example, how would your new RPCs interact
> with locks?  With candidate?  With startup?

The point of already existing mechanisms and locks is somewhat
compelling. Although this data is not very dynamic so it's hard to
imagine locks coming into play, but the point is still taken.

So if the user changes the tags on a module using the module path can we
just indicate that it would automatically also update in the yang
library list? We use a grouping that gets stamped inside a module and
then we have another module define the yang library notation would we
simply define the semantics in text and outside of yang? It's easy for
the module grouping to refer to the yang library but the reverse is not
true.

> Also I am not sure it is a good idea to add configuration meta-data
> that really should be common across all modules into the modules
> themselves.  Another approach is to keep a separate list with the
> tags, indexed by modulename and revision.

I don't understand what your getting at here. Are you referring to the
grouping that gets used by a module author inside their module? The tags
set for a given module are specific to that module only.

Thanks,
Chris.

> /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2017 23:17:09 +0100 (CET)

Christian Hopps <[email-masked]> wrote:
> library list?

Sure.

> We use a grouping that gets stamped inside a module and
> simply define the semantics in text and outside of yang?

In the description should work.

> It's easy for

I meant that instead of using the grouping in every module, you could
have a separate structure in your module:

  container module-tags {
    list module {
      key "name revision";
      leaf name { ... }
      leaf revisoin { ...}
      leaf-list tag { ... }
    }
  }

This way you will handle configuration of tags for all modules, and
they don't have to have a special uses statement.

/martin

---

From: Christian Hopps <[email-masked]>
Date: Wed, 08 Feb 2017 18:09:23 -0500

> they don't have to have a special uses statement.

The reason I went with the grouping and in-module list was that I
thought one could then create selecting xpath expressions, e.g.,

   get foobar-value[../tags="ietf:implements:foobar"]

I'm not sure if netconf supports this use of xpath directly, but one can
imagine other systems or protocols supporting it.

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Feb 2017 08:55:06 +0100 (CET)

>    get foobar-value[../tags="ietf:implements:foobar"]

I'm not sure I understand what you're after, but I am pretty sure that
if it can be done with a per-module structure that you propose, then
it can also be done with a single structure.

Is the idea that you want to read a certain leaf in a certain module,
but only if that module has been dynamically tagged with a certain
tag?

> imagine other systems or protocols supporting it.

NETCONF does support XPath filtering.

/martin

---

From: Christian Hopps <[email-masked]>
Date: Thu, 09 Feb 2017 05:32:12 -0500

> but only if that module has been dynamically tagged with a certain

Close, the idea was that I want to read all "foobar-value"s from all
modules that have that tag set.

> NETCONF does support XPath filtering.

Yes, I'm aware of that, but I'm not sure if it supports the above
clarified idea which would use non-namespace "foobar-value" to fetch all
values along with an xpath check to see if a tag leaf-list contained a
tag value. I thought I read that netconf didn't support the latter at
least.

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Feb 2017 12:08:23 +0100 (CET)

> modules that have that tag set.

Ok. What is the use case?  It is probably not very common that
multiple modules have the exact same data structure defined.

> tag value. I thought I read that netconf didn't support the latter at

If it can be expressed in XPath 1.0, then NETCONF supports it.
Checking that a leaf-list contains a particular value is supported.

/martin

---

From: Christian Hopps <[email-masked]>
Date: Thu, 09 Feb 2017 07:19:50 -0500

> multiple modules have the exact same data structure defined.

My example is fairly forward looking I guess. The key thing to note is:
"implements" in the tag name. The idea being that one has defined a
common structure (or interface) and then associated that interface with
a tag. Now a client can, with a single xpath expression, access a value
in all modules that implement that interface.

Thanks,
Chris.

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 Feb 2017 07:28:11 -0500

> in all modules that implement that interface.

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.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Feb 2017 13:36:20 -0800

> they don't have to have a special uses statement.
+1.

I read the draft, and I agree with you that the single container solution
is best. Looks like configuration data to me, and no need for any special
case editing models.

Oddly, the draft relies on XPath filtering to retrieve modules with a
certain tag.
There is no <find-tags> operation.
That is the 1 RPC operation that might be justified.

e.g.:

  rpc find-tags {
    description "find all modules with the specified tag(s).";
     input {
       leaf-list tag { type string; }
     }
     output {
       leaf-list module-name { type string; }
     }
   }

> /martin
Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Christian Hopps <[email-masked]>
Date: Sat, 11 Feb 2017 07:52:23 -0500

> is best. Looks like configuration data to me, and no need for any special

We do get this with the yang library augmentation I believe. I hope
the yang library will be implemented by most servers. Do you think this
is not sufficient?

Again the in module list allows for single xpath selection of a given
node for all modules that have a certain tag set. I found this rather
elegant, so that's why I've argued to keep it. I want to make sure that
people have considered this before we abandon it.

I'm OK with removing the add/delete RPCs as they do seem redundant.

Is there a way to get the reset to default behavior? We do allow the
user to remove default set tags, so I think that's why Lou added that
RPC.

> Oddly, the draft relies on XPath filtering to retrieve modules with a certain tag.

This does seem useful, we can add it.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Feb 2017 14:54:17 +0100

> people have considered this before we abandon it.

Can you point me to a set of modules and a concrete query where this
makes sense? I am like Martin not yet convinced that there is a use
case for this.

> user to remove default set tags, so I think that's why Lou added that

Note sure whether this (removing of non-configured tags) is a good
idea. Again, concrete use cases might help to make the point.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 11 Feb 2017 17:32:14 +0100 (CET)

> the yang library will be implemented by most servers. Do you think this

The augmentation of yang-library is not sufficient b/c it is config
false only.  That's why a separate config list is also needed.

> people have considered this before we abandon it.

Just to be clear, the use case is only for the case where several
different modules implement the exact same structure, right?  Do you
have any example where this is the case?  Or maybe I didn't understand
the use case; if so, could you provide a more complete use case?

> user to remove default set tags, so I think that's why Lou added that

I assume that reset to default would be to remove all configured tags
from the config.  If so that is clearly supported.

> This does seem useful, we can add it.

But this is an XPath one-liner:

  /modules-state/modules/name[../module-tag = 'foo']

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Feb 2017 12:05:20 -0800

> false only.  That's why a separate config list is also needed.

So what would qualify as the corresponding configuration that would
warrant the creation of the /modules subtree?  How many different subtrees
of configuration do we need per module-name/revision pair?

>   /modules-state/modules/name[../module-tag = 'foo']

XPath is optional to implement, but I agree this is not an important
feature.

I actually question the usability of per-module tags.
I do not think it will be granular enough for selection of yang-push
content (for example).

I suggested a YANG module called topic.yang last December:
https://www.ietf.org/mail-archive/web/netconf/current/msg12006.html

IMO the tagging needs to be on schema tree, not the module-set.
See the 'topic-maps' container below.  I made it config false
but it could be config true instead.

I also do not like relying on conventions instead of deterministic rules.
Use of identityref in topic.yang is fully distributed, but without requiring
any prefix strings to be assigned in advance and maintained.

(from attachment to msg above)
module topic {
  namespace "urn:test:topic";
  prefix top;

  import filter { prefix fil; }

  revision 2016-12-01;

  extension event-topic {
    argument id;
    description
      "An extension to map a schema node to a specific topic
       identifier. An rpc, notification, action, or data-def
       statement containing this external statement is mapped
       to the event-topic identity represented by the 'id'
       parameter.

       The syntax of the 'id' argument is the identityref
       data type.

       Example:

         container example-vpn {
           top:event-topic 'example:vpn-event';
           ...
         }
         container example-vpn-state {
           top:event-topic 'example:vpn-event';
           ...
         }
         notification example-vpn-event {
           top:event-topic 'example:vpn-event';
           ...
         }
      ";
  }

  identity topic-filter {
    base fil:filter-type;
    description
      "Filter type identifier for topic filters.";
  }

  identity topic-id {
    description
      "Base identity from which topic identifiers are derived.";
  }

  /********************************
     example topic subtree

    + topic-id
      |
      + service-topic
        |
        + routing-topic
          |
          + bgp-topic
          |
          + isis-topic

  **********************************/

  identity service-topic {
    base topic-id;
    description
      "Base identity from which service-related topic identifiers
        are derived.";
  }

  identity routing-topic {
    base service-topic;
    description
      "Base identity from which routing related topic identifiers
        are derived.";
  }

  identity bgp-topic {
    base routing-topic;
    description
      "Base identity from which BGP related topic identifiers
        are derived.";
  }

  identity isis-topic {
    base routing-topic;
    description
      "Base identity from which IS-IS related topic identifiers
        are derived.";
  }

  container topic-maps {
    config false;
    description
      "The set of topic-id to schema node mappings used by
       the server";

    list topic-map {
      key "id node";
      leaf id {
        type identityref {
          base topic-id;
        }
        description "The topic identifier for this mapping";
      }
      leaf node {
        type string; // really schema-node-identifier from 6535bis
        description "The schema node for this mapping";
      }
    }
  }

  augment "/fil:filters/fil:filter" {
    when "derived-from-or-self(fil:type, 'top:topic-filter')";

    description "Set of topic filter parameters";

    leaf-list topic-filter {
      type identityref {
        base topic-id;
      }
      description
        "Identifies a topic that is included in the
         subscription. Multiple instances represent a
         logical AND expression. Each topic-filter
         instance must evaluate to 'true' in order for
         the subscription to accept the event.

         A topic matches the filter if there is at least one
         topic-id associated with the event node or notification
         that is derived from or equal to the topic-filter value.";
    }
  }

}

Andy

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 04:42:22 -0500

> makes sense? I am like Martin not yet convinced that there is a use

I gave the example of something that implements a common interface. So
for example most IGP routing protocols have hello timers. One could
imagine an "ietf:implements:hello-timer" (or whatever) tag. This type of
thing is used to avoid the use of multiple-inheritance in OOP. It could
serve a similar purpose with yang (although in this case it avoids having
to factor all commonality out into tiny modules).

I don't know if this would develop organically or not, but I do know
having a central list eliminates the option. Why choose the option with
less capabilities?

> idea. Again, concrete use cases might help to make the point.

I do want to support tag removal. The most obvious case for tags is for
operator use, and the resulting tag set for any module should be under
the control of the operator. A use case would be that some server has a bug
in their implementation and the admin wants to remove it from possible
use. I'd ask the reverse question, why take this control away from the
operator?

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Feb 2017 11:41:06 +0100

> having a central list eliminates the option. Why choose the option with

I am asking for a concrete example. Assuming that modules will have a
common structure and naming inside is IMHO wishful thinking. Show me a
concrete example please using existing modules.

> use. I'd ask the reverse question, why take this control away from the

I am trying to understand the use case. If you are unhappy with the
default tags, why not add your own tags? This way, the operator has
full control over his tag space.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 05:59:40 -0500

a

> concrete example please using existing modules.

I did give an example: IGP hello timers. I feel it's unreasonable to
expect me to be more concrete with existing modules when we are talking
about creating a feature that would make commonality useful (!)

There are IGP models, they have common hello timers, the fact that these
are placed in a common area simply has to do with the fact that there
was no gain in doing so.

I've offered I think a valid use case that is well excepted and present
in other areas of computer science, your saying no-one is doing this now
with yang. To me that's like having java without the interface
statement and then asking to be shown actual java code using the
non-existent interface statement. There are yang models with common
factorable structure now, I've given an example. If that's not enough I
don't know what else I can do.

> full control over his tag space.

A model on a server is buggy for some tagged feature, I want to remove
that tag from it on that server. Your suggesting rather than me be in
control and simply remove that tag from that server, I need to not use
that tag at all in all of my network, and instead create a new tag that
I add to all the functional servers in my network leaving it off this
single server.

Again why is this a big deal? What are you gaining by not allowing the
removal of tags? As an operator I'm certainly losing something.

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 06:30:11 -0500

> false only.  That's why a separate config list is also needed.

Or an in-module config:true list of tags, but yes, your right.

> the use case; if so, could you provide a more complete use case?

In another thread I gave the example of IGP hello timers. The xpaths
currently are exactly the same, but without a way (e.g., tagging interfaces)
to make use of the commonality one wouldn't expect the commonality to have
grown organically I don't think. Also, if I'm not mistaken, even the
xpaths don't have to be exactly the same if one uses regular
expressions, just the final node names.

> from the config.  If so that is clearly supported.

It would also put back any default tags that had been removed. In any
case I was just curious if it was possible. The reset RPC would still
have the issues with doing an end-run around the normal config
operations so I'm fine with removing it as well.

>   /modules-state/modules/name[../module-tag = 'foo']

Yes, xpath is nice that way. :) I figured the RPC was useful in the case
that xpath wasn't supported.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Feb 2017 12:51:35 +0100

> don't know what else I can do.

Sorry, a bunch of tags and an expectation of authors doing things in a
common way does not give you Java interfaces. I remain unconvinced and
there is no requirement that we agree on this use case being
realistic.  At least you seem to agree that for existing modules this
is not terribly useful and that future modules would have to follow
certain conventions to make things useful.

> removal of tags? As an operator I'm certainly losing something.

It was suggested (I think) that tags originate either (a) from the
data model it self, (b) from the implementation itself, (c) from the
operator. You want to be able to overwrite (remove) (a) and (b) tags?
Are tags not scoped by something that represents some form of
ownership? If so, does it make sense to step on other people's
carefully design tags? What if this creates conflicts for different
applications, some like to have a certain tag some don't?

Perhaps what you are requesting is useful but I think it needs a bit
more thinking and clarity about what tags mean and how tags are
scoped.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 07:54:52 -0500

> certain conventions to make things useful.

I agree it's probably mostly useful going forward.

My xpath foo isn't very strong, but given that both OSPF and IS-IS label
their hello interval timer nodes "hello-interval" I believe this xpath
would select those nodes from both models:

    //hello-interval[/tags="ietf:routing:igp"]

That said, the content does currently differ. For OSPF the node is the
integer timer interval whereas the synonymous interval for IS-IS is a child
node named "value".

> more thinking and clarity about what tags mean and how tags are

Yes indeed tags can be created in 3 ways, but the ultimate authority is
the user as they are the ones actually deploying devices to implement
something (e.g., a network). The designer and implementer cannot
ultimately know how the user will use their devices and their modules. I
guess I'm drawing from my unix background here, give the user the rope;
I'm not sure how they would hang themselves with this particular rope,
but worrying about that seems to be the only reason to not give them the
control. :)

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Feb 2017 14:04:12 +0100

> integer timer interval whereas the synonymous interval for IS-IS is a child

See, either something is designed and guaranteed to mean the same or
it is not.  Assuming that something showing up at the same path was
designed to be the same can go seriously wrong. I wonder why an
operator would want to run a network on such weak premises.

> ultimately know how the user will use their devices and their modules.

Then there should only be type (c) tags. 

> I guess I'm drawing from my unix background here, give the user the rope;

There are many things a device can implement differently. Do we
generally need a way to overwrite things? I am trying to understand
why tags are different and considered to require this ability. And as
I said, there is always the option to trust only the tags an operator
has assigned himself.

/js

---

From: Lou Berger <[email-masked]>
Date: Sun, 12 Feb 2017 08:32:43 -0500

Juergen

...
> I said, there is always the option to trust only the tags an operator

This is all about proving user controllable metadata for modules. Library 
is a good existing example of providing what I mean by module metadata, but 
its data is (rightly) not under user control. So one thing that is 
"different" about tags is the user control of the metadata.

>From a mechanism perspective, creating a config true module for module 
metadata is fine -  but personally, I still see the value of having module 
metadata consolidated in yang library.

>From a user perspective, the authors think the capability  (including a, b, 
c from above and complete ability to override the user) is useful - even if 
we don’t agree on all aspects of how this mechanism is going to be most 
used/useful down the road.

Please keep in mind that tags are data about modules, i.e. module metadata. 
So the item/information being "configured" is another module. This is 
another way in which tags are different than other modules and their  
information.

Lou

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 08:55:04 -0500

> I said, there is always the option to trust only the tags an operator

The tags defined by (a) and (b) are still for the users use. In fact
aren't there plenty of defaults in configuration on devices that the
user can override or remove? I guess I don't understand why this is so
controversial.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Feb 2017 15:57:55 +0100

> user can override or remove? I guess I don't understand why this is so

In YANG, you can overwrite defaults by configuring explicit values,
you can't remove the default - the default is just not used anymore
once there is a configured value - the default still exists and it
will come back when there is no configured value anymore. But I am not
sure the analogy is a good one.

If a data model defines an implementation should set the tag 'foo',
then it feels odd to me to go to the device and to remove that
tag. The tag 'foo' after all is there because the data model says it
should be there - so in an ideal world all implementations of this
data model will set the tag. Why would be removing the 'foo' tag on
all these correct implementations be significantly cheaper than simply
using your own (application specific) tag instead of the 'foo' tag
(that does not seem to do what you like)? Or you add a tag
'ops-foo-broken' to those implementations where you believe the foo
tag is inappropriate.

At the end, it is not a big deal to remove tags but somehow I am not
sure whether there is not a difference between (a), (b), and (c) tags.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 12:40:20 -0500

Juergen Schoenwaelder <[email-masked]> writes:

> tag.

Perhaps strictly from a module designers point of view it might seem
odd. One reason we allow for changing things from strictly the designers
point of view though is because the designer can't anticipate all use
cases and situations that arise from here to eternity. As I'm the user,
unless there is a very good reason not to the default should be to let
me do what I want. That's the unix way, and I certainly like unix. :)

> The tag 'foo' after all is there because the data model says it

The tag is there to help identify things about the module to the users
of that module, as the ultimate authority on the use of this module I
want to be able to override that default just like I can override other
default values.

Your right I can add a new tag to be used by software that I can modify,
but what if other software I need to use is also using the designer's
tag? I can only control it by removing the tag in that case.

It doesn't cost anything really to allow for this, and it provides
future-proofing control to the user, conversely what do we gain from
disallowing it?

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Feb 2017 19:05:06 +0100

> tag? I can only control it by removing the tag in that case.

Or you break software by removing that tag. If a module says an
implementation must set a certain tag, how can it help to remove this
tag? Are you not breaking a part of a contract between a module and
implementations using the module?

> future-proofing control to the user, conversely what do we gain from

I am simply challenging you in order to better understand how people
expect tags to be used, what it means to have type (a), (b), and (c)
tags and why it is necessary to be able to remove type (a) and (b)
tags. I guess it all boils down to what it really means to say in a
module that a certain set of tags must be set, i.e., whether an
application can rely on these tags to be set or not.

/js

---

From: Christian Hopps <[email-masked]>
Date: Sun, 12 Feb 2017 14:30:37 -0500

> implementations using the module?

I don't break your software, I break my network. I bought your software
I want control over it.

> application can rely on these tags to be set or not.

Indeed, the application should rely on those tags being set. That's
what gives me control over what the application uses or doesn't.

I'd like to hear what is gained by *not* providing the user (customer!)
this option.

Thanks,
Chris.

---

From: Robert Wilton <[email-masked]>
Date: Mon, 13 Feb 2017 16:49:22 +0000

Hi tags draft authors,

On 09/02/2017 12:28, Lou Berger wrote:
> 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.

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.

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.

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.

Thanks,
Rob

> .

---

From: Kent Watsen <[email-masked]>
Date: Mon, 13 Feb 2017 18:19:11 +0000

As for a concrete use-case, would something like this be helpful
for a server to indicate which datastores a module is supported in?

I'm thinking specifically about the revised-datastores draft where
we've discussed that a module might exist in just oper-state,
oper-state + ephemeral, oper-state + ephemeral + running, etc.

Kent // as a contributor

Hi tags draft authors,

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 14 Feb 2017 10:03:22 +0000

> for a server to indicate which datastores a module is supported in?
I'm not sure.  I would probably prefer to see the two kept separate, but 
it may depend on what the scope of modules tags ends up being.

Rob

---

From: Christian Hopps <[email-masked]>
Date: Tue, 14 Feb 2017 09:08:13 -0500

> would be versioned/managed entirely independently from the YANG modules

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

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

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

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 14 Feb 2017 15:06:56 +0000

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

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

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.

>   Nothing would keep the user or vendor
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

---

From: Christian Hopps <[email-masked]>
Date: Tue, 14 Feb 2017 11:30:44 -0500

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

> area, and I doubt that anyone would want to update a standard to just

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.

> this needs to change over time then this would seem to be much easier to

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.

---

From: Robert Wilton <[email-masked]>
Date: Tue, 14 Feb 2017 17:29:27 +0000

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

> tag I think, so maybe we need to move more to this rather than the ietf
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.

> 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

---

From: Christian Hopps <[email-masked]>
Date: Thu, 16 Feb 2017 02:03:41 -0500

> can identify the right cow in the database.

On some other threads I've given the example of a tag that indicates an
"interface" (like java has interfaces), is present. In that case the
actual metadata (the interface definition) is present elsewhere and the
tag is just like a cow ear tag, i.e., a reference. This is the case with
most tag uses I think, the only difference may be the amount of
information that is represented by the tag.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Feb 2017 08:13:10 +0100

> information that is represented by the tag.

I have doubts that this use case is realistic. To drive automation at
this level, you most likely need tagging of YANG objects and not YANG
modules - coarse grain tagging of modules will be of limited value.

/js