a Juergen Schoenwaelder <[email protected]> writes:
> 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. I did give an example: IGP hello timers. I feel it's unreasonable to expect me to be more concrete with existing modules when we are talking about creating a feature that would make commonality useful (!) There are IGP models, they have common hello timers, the fact that these are placed in a common area simply has to do with the fact that there was no gain in doing so. I've offered I think a valid use case that is well excepted and present in other areas of computer science, your saying no-one is doing this now with yang. To me that's like having java without the interface statement and then asking to be shown actual java code using the non-existent interface statement. There are yang models with common factorable structure now, I've given an example. If that's not enough I don't know what else I can do. >> >> 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. A model on a server is buggy for some tagged feature, I want to remove that tag from it on that server. Your suggesting rather than me be in control and simply remove that tag from that server, I need to not use that tag at all in all of my network, and instead create a new tag that I add to all the functional servers in my network leaving it off this single server. Again why is this a big deal? What are you gaining by not allowing the removal of tags? As an operator I'm certainly losing something. > /js
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
