Hi, On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>> wrote: Jan Lindblad <j...@tail-f.com<mailto:j...@tail-f.com>> writes:
> 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. Anyway, this is not a case where the server writes something on its own to a configuration datastore. I don't think it is a problem if NMDA or non-NMDA servers write to <running>. Just part of the complexity that is baked in -- NMDA does nothing to help the client know why <running> is different than <intended> anyway. SB>> But RFC 8342 says : “It represents the configuration after all configuration transformations to <running> are performed (e.g.,template expansion, removal of inactive configuration)” So my understanding is that by definition “intended” can be different from “running”. Am I missed something? > > 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. Absolutely. I am not proposing YANG needs a new default-stmt. There is a description-stmt and vendors can add their own extensions to flag auto-magic data nodes. Lada > > /jan Andy Thanks Sergio Sergio Belotti Senior System Engineer and Standardization Architect IP/Optical Networks, Optics BU Nokia M: +39-335761776 Via Energy Park, 20871 Vimercate (MB) , Italy sergio.belo...@nokia.com<mailto:sergio.belo...@nokia.com> > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
