On Thu, Oct 3, 2019 at 5:30 PM Qin Wu <[email protected]> wrote: > > > *发件人:* netmod [mailto:[email protected]] *代表 *Andy Bierman > *发送时间:* 2019年9月27日 11:42 > *收件人:* Schönwälder, Jürgen <[email protected]> > *抄送:* [email protected] > *主题:* Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please > clarify implementation about ‘when’ > > > > > > > > On Thu, Sep 26, 2019 at 11:35 AM Schönwälder, Jürgen < > [email protected]> wrote: > > 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. > > > > > > different deviation modules in each module-set are allowed in the YANG > library. > > That makes it kind of mandatory for the client to support it, or choose to > > not conform to the standard. > > > > > > > > > > > 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. > > > > I am not trying to revive debates on the value of NMDA or the solution, > > but more flexibility for the server means more complexity for the client. > > IMO this is contributing to the slow adoption of NMDA. > > > > I hope the industry will find a transition solution (NMDA Lite) that fully > supports > > the protocol operations, but uses the same module-set(s) in the YANG > library > > for all datastores. If this is the expected norm for servers then clients > that support it > > will work. (I would like to hear about even one NMDA implementation > > that supports complex YANG libraries). > > > > [Qin]: Should Non-NMDA client fall back to RFC7895 YANG library or adopt > new YANG library in RFC8525 and assume same module-set(s), schema for all > datastores? > > RFC7895 has already been obsoleted. > > >
No. The /modules-state subtree has status "deprecated" in RFC 8525. It is not desirable to list non-NMDA only modules in the new /yang-library so the deprecated tree will never go away as long as the server intends to support non-NMDA clients. NMDA has this MUST requirement: The datastore schema for <operational> MUST be a superset of the combined datastore schema used in all configuration datastores, except that configuration data nodes supported in a configuration datastore MAY be omitted from <operational> if a server is not able to accurately report them. The "foo" module will be listed in /yang-library and /modules-state. The temporary "foo-state" module will be listed only in /modules-state. (I don't see much value in implementing /yang-library but if think you need it then go ahead ;-) /js > > > > Andy > > > Andy > > -- > 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
