On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote: > The IETF has completely punted the problem of converting data for a > configuration datastore to the schema tree for <operational>.
I am not sure. The <operational> model consists of the applied configuration plus any config false extras. NMDA simplifies things since there is now a single tree structure instead of two if you have to handle models where applied configuration can be different than intended config. If I configure /foo/bar in <running>, I can check /foo/bar in <operational> whether it exists and matches what I configured. > Deviations may be different. A leaf may be string in 1 tree and > decimal64 in the other. There is an incorrect assumption that > software developers will deal with these corner-cases (correctly and > consistently). Not really true for applied config. And with non NMDA, there is no guarantee either that /foo/bar and /foo-state/bar use the same type and semantics. > The other big problem is an untested NMDA transition strategy that is not > well understood by vendors. > Should non-NMDA (/foo-state) be visible to <get-data> or just <get>? Perhaps there is more explanation necessary. The idea here is that an NMDA client should not bother to search for /foo-state, it should send a <get> for /foo/state in operational. Yes, NMDA requires updates to clients. Whether these are visible or in which form they are visible to application logic likely depends on the client design. But yes, NMDA is not for free for clients. But once you have updated, we believe NMDA actually makes things simpler and more consistent. > Using the YANG library to separate the modules relies on the assumption that > the client is capable of managing each datastore independently (instead of > 1 schema tree per server). Yes, YANG library can express pretty complex server model organizations. This does not mean that all server have to use server model organizations. I assume that also many clients will not be interested to understand the entire server model, they likely want to check the existance of only those pieces that they care about. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
