Martin Bjorklund <[email protected]> writes: > Christian Hopps <[email protected]> wrote:
> 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.
Or an in-module config:true list of tags, but yes, your right.
>
>> 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?
In another thread I gave the example of IGP hello timers. The xpaths
currently are exactly the same, but without a way (e.g., tagging interfaces)
to make use of the commonality one wouldn't expect the commonality to have
grown organically I don't think. Also, if I'm not mistaken, even the
xpaths don't have to be exactly the same if one uses regular
expressions, just the final node names.
>> 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.
It would also put back any default tags that had been removed. In any
case I was just curious if it was possible. The reset RPC would still
have the issues with doing an end-run around the normal config
operations so I'm fine with removing it as well.
>> > 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']
Yes, xpath is nice that way. :) I figured the RPC was useful in the case
that xpath wasn't supported.
Thanks,
Chris.
> /martin
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
