On Sun, Feb 12, 2017 at 04:42:22AM -0500, Christian Hopps wrote: > > > 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?
I am asking for a concrete example. Assuming that modules will have a common structure and naming inside is IMHO wishful thinking. Show me a concrete example please using existing modules. > >> 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? I am trying to understand the use case. If you are unhappy with the default tags, why not add your own tags? This way, the operator has full control over his tag space. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
