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?
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.
> 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.
Thanks,
Chris.
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
