On Fri, Sep 27, 2019 at 3:40 AM Rob Wilton (rwilton) <[email protected]> wrote:
> Hi, > > > -----Original Message----- > > From: netmod <[email protected]> On Behalf Of Schönwälder, Jürgen > > Sent: 26 September 2019 19:35 > > To: Andy Bierman <[email protected]> > > Cc: [email protected] > > Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: > > Please clarify implementation about ‘when’ > > > > 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. > > Indeed. For non-NMDA, even if /foo/bar and /foo-state/bar are the same > type in the published model, there is no guarantee that a server won't > deviate the /foo-state/bar leaf to change its type to differ from /foo/bar, > and this is allowed. > > But NMDA is aiming to be better than this. One of the fundamental aims is > that the config and operational values should be comparable, on the same > relative datastore path and have the same type. > > That is why RFC 8342 does not allow a server to change the type of a data > node in operational, they are only allowed to remove it to indicate that it > is not supported. > > RFC 8342, section 5.3 The Operational State Datastore(operational): > > 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 intention here is: > - If a server does a deviate "add|replace|delete" deviation on a config > data node then that same deviation MUST be applied to all datastores that > contain that data node in their schema (or otherwise operational cannot be > a superset). > - A server MAY have operational datastore specific deviate > "not-supported" deviations. The purpose of this is meant to help > migration, ideally servers would not have these deviations. > > Hence, a client/server can construct a single "superset" schema for the > device, and then the schema for each individual datastore must be a subset > of that "superset" schema (with the added requirement that there is only a > single schema for all conventional datastores). > > IMO the new YANG library is the most disruptive and complex way possible to express a simple capability "operational value for configuration object foo supported or not". I prefer the capabilities module approach in https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04 Deprecating the YANG library and starting over is kind of a bull-in-the-china-shop approach to advertising some server capabilities. I appreciate that the new YANG library structurally allows invalid schemas > to be defined, but then so does the old YANG library as well. E.g. there > is nothing in the old YANG library structure to prevent a server from > reporting that it implements two different revisions of the same YANG 1.1 > module. > > Thanks, > Rob > > Andy > > > > > > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
