On Tue, Dec 18, 2018 at 5:37 AM Jan Lindblad <[email protected]> wrote:
> 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" Best Regards, > /jan > Andy > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
