Christian Hopps <[email protected]> wrote:
>
> Andy Bierman <[email protected]> writes:
> > On Wed, Feb 8, 2017 at 2:17 PM, Martin Bjorklund <[email protected]> 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.
> 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']
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
