Hi, >> While I agree with Martin, in our systems we have a number of places, where >> the system does create configuration in running, due to >> >> different levels of automation and autonomous algorithms kick-in >> the created config needs to be possible to be further modified by the >> operator >> the created config needs to be referenced from operator created config >> the created config is not always ephemeral, it might need to be part of >> backup/restore > This is only a sampling from "the list of excuses". I have heard many more. > The road to hell is paved with good intentions, however. If we want to build > automation based on sound theory, clearly separating the orders from managers > from a system's own operational view is key, IMO. Reliability, security, > accountability are growing in importance, and they all play in this direction. > > We may not need to standardize rules to outlaw the above; the market will > take care of that. What we need to ensure is that it is possible to be > standards compliant without having to implement design excuses like these. > > > NMDA has a lot of room for proprietary mechanisms for converting <running> to > <intended>. > Many times the features desired by engineers exceed the capabilities of YANG, > such as > a dynamic default leaf. YANG allows a simple constant, and no business logic > to pick the default. > This is a very valid use of "server auto-magic". > > Maybe a future version of YANG can improve the client visibility into this > "auto-magic"
As you say, this is not uncommon. I usually recommend to leave out any default statement, and write in the description what happens if this leaf isn't set. The operator can then override the default by giving a value. While some more advanced features for default values may be of some utility, the simplicity of YANG is also important. We don't want to make the YANG models -- the interface contracts -- the new place for all business logic. /jan
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
