Christian Hopps <[email protected]> wrote:
>
> Martin Bjorklund <[email protected]> writes:
> > Juergen Schoenwaelder <[email protected]> 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.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
