发件人: Netconf [mailto:[email protected]] 代表 Andy Bierman 发送时间: 2018年12月20日 2:46 收件人: Jan Lindblad; Andy Bierman; [email protected]; [email protected] 主题: Re: [Netconf] [netmod] magic leaf 'type' in IETF interfaces
On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <[email protected]<mailto:[email protected]>> wrote: Jan Lindblad <[email protected]<mailto:[email protected]>> 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. [Qin]: I think it is important to make NMDA server can use existing operation to return the same results to Non-NMDA client with <rpc-reply> as non-NMDA server does. We call this Server Backwards-Compatibility in https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility-00#section-2.3 > > 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 > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
