Juergen Schoenwaelder <[email protected]> writes:
> On Sat, Feb 11, 2017 at 07:52:23AM -0500, Christian Hopps wrote: >> >> 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. > > Can you point me to a set of modules and a concrete query where this > makes sense? I am like Martin not yet convinced that there is a use > case for this. I gave the example of something that implements a common interface. So for example most IGP routing protocols have hello timers. One could imagine an "ietf:implements:hello-timer" (or whatever) tag. This type of thing is used to avoid the use of multiple-inheritance in OOP. It could serve a similar purpose with yang (although in this case it avoids having to factor all commonality out into tiny modules). I don't know if this would develop organically or not, but I do know having a central list eliminates the option. Why choose the option with less capabilities? >> 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. > > Note sure whether this (removing of non-configured tags) is a good > idea. Again, concrete use cases might help to make the point. I do want to support tag removal. The most obvious case for tags is for operator use, and the resulting tag set for any module should be under the control of the operator. A use case would be that some server has a bug in their implementation and the admin wants to remove it from possible use. I'd ask the reverse question, why take this control away from the operator? Thanks, Chris. > > /js
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
