On Thu, Dec 20, 2018 at 1:08 AM Belotti, Sergio (Nokia - IT/Vimercate) < [email protected]> wrote:
> Hi, > > > > On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <[email protected]> wrote: > > Jan Lindblad <[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. > > > > 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? > > > The client can see WHAT changed because of server-auto-magic but not WHY a particular server implementation converts <foo> into <bar> if <foo> is edited. A client (using plain YANG) cannot predict at all what will happen if <foo> is edited. The issue remains: how does a client know that a mandatory leaf is not actually required in <running>? I guess vague auto-magic description-text is good enough Andy > > > > 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 > > [email protected] > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [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
