On Sun, Feb 12, 2017 at 12:40:20PM -0500, Christian Hopps wrote: > > Juergen Schoenwaelder <[email protected]> writes: > > > On Sun, Feb 12, 2017 at 08:55:04AM -0500, Christian Hopps wrote: > >> The tags defined by (a) and (b) are still for the users use. In fact > >> aren't there plenty of defaults in configuration on devices that the > >> user can override or remove? I guess I don't understand why this is so > >> controversial. > >> > > > > In YANG, you can overwrite defaults by configuring explicit values, > > you can't remove the default - the default is just not used anymore > > once there is a configured value - the default still exists and it > > will come back when there is no configured value anymore. But I am not > > sure the analogy is a good one. > > > > If a data model defines an implementation should set the tag 'foo', > > then it feels odd to me to go to the device and to remove that > > tag. > > Perhaps strictly from a module designers point of view it might seem > odd. One reason we allow for changing things from strictly the designers > point of view though is because the designer can't anticipate all use > cases and situations that arise from here to eternity. As I'm the user, > unless there is a very good reason not to the default should be to let > me do what I want. That's the unix way, and I certainly like unix. :) > > > The tag 'foo' after all is there because the data model says it > > should be there - so in an ideal world all implementations of this > > data model will set the tag. Why would be removing the 'foo' tag on > > all these correct implementations be significantly cheaper than simply > > using your own (application specific) tag instead of the 'foo' tag > > (that does not seem to do what you like)? Or you add a tag > > 'ops-foo-broken' to those implementations where you believe the foo > > tag is inappropriate. > > > > At the end, it is not a big deal to remove tags but somehow I am not > > sure whether there is not a difference between (a), (b), and (c) tags. > > The tag is there to help identify things about the module to the users > of that module, as the ultimate authority on the use of this module I > want to be able to override that default just like I can override other > default values. > > Your right I can add a new tag to be used by software that I can modify, > but what if other software I need to use is also using the designer's > tag? I can only control it by removing the tag in that case.
Or you break software by removing that tag. If a module says an implementation must set a certain tag, how can it help to remove this tag? Are you not breaking a part of a contract between a module and implementations using the module? > It doesn't cost anything really to allow for this, and it provides > future-proofing control to the user, conversely what do we gain from > disallowing it? I am simply challenging you in order to better understand how people expect tags to be used, what it means to have type (a), (b), and (c) tags and why it is necessary to be able to remove type (a) and (b) tags. I guess it all boils down to what it really means to say in a module that a certain set of tags must be set, i.e., whether an application can rely on these tags to be set or not. /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
