Re: [netmod] Module tags

[Andy Bierman <[e-mail]>]

On Sat, Feb 11, 2017 at 8:32 AM, Martin Bjorklund <[e-mail]> wrote:

> Christian Hopps <[e-mail]> wrote:
> >
> > Andy Bierman <[e-mail]> writes:
> > > On Wed, Feb 8, 2017 at 2:17 PM, Martin Bjorklund <[e-mail]>
> wrote:
> > >      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.
> > >
> > >
> > > +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.
> >
> > 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?
>
> 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.
>


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?



>
> > 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.
>
> 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?
>
>
> > 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.
>
> I assume that reset to default would be to remove all configured tags
> from the config.  If so that is clearly supported.
>
>
> >
> > > 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; }
> > >   }
> > >  }
> >
> > This does seem useful, we can add it.
>
> But this is an XPath one-liner:
>
>   /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.";
    }
  }

}





>
>
>
> /martin
>


Andy