On Wed, Feb 8, 2017 at 2:17 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Christian Hopps <cho...@chopps.org> wrote:
> >
> > Martin Bjorklund <m...@tail-f.com> writes:
> > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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?
>
> Sure.
>
> > 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?
>
> In the description should work.
>
> > 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.
>
> 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.
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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
