Andy Bierman <[email protected]> wrote: > On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund <[email protected]> wrote: > > > Andy Bierman <[email protected]> wrote: > > > I think NMDA is creating much more complexity and disruption than is > > > required. > > > The original issue was the OpenConfig-style config/state trees. > > > The WG agreed that an RPC-based solution was needed so that the > > > YANG modules would not need to change (far too disruptive!). > > > > > > Then the IETF proceeds to redo all the YANG modules anyway. > > > Now the server is allowed to implement the same module differently in > > each > > > datastore. > > > Now comparing the configured and operational value is even harder than > > > before. > > > > > > None of this added complexity was in the OpenConfig proposal. > > > It was not even possible to have different features and deviations for > > the > > > same object in that proposal. > > > > Actually, this is not correct. In both OC and the old IETF split tree > > solutions, the configuration and operational state were modelled with > > duplicate nodes, and you could certainly deviate these nodes > > differently. > > > > This said, I share your concern about complexity. I also agree that > > the only model that makes the client simple is that if all objects in > > the config are also available with the same types in operational > > state. Otherwise comparison won't work (or be complicated). > > > > But at the same time, the converse is not true. I.e., if an object is > > present in operational, it doesn't have to be configurable. > > > > So what I think we want is that the schema for the conventional > > datastore is a subset of the schema for operational. > > > > This would allow an implementation that cannot support configuration > > of let's say the MTU, to deviate the mtu with "not-supported" in the > > conventional datastore, but it will still be available for inspection > > in operational. > > > > Does this make sense? > > > > OK -- deviations for not-supported make sense per datastore > to resolve the missing-object ambiguity problem. > It is not realistic to expect every object in a module to be able > to report its operational state in the same release. > It is better to report not-supported than return nothing or return the > configured value as a guess. > > If the admin-state and oper-state objects are different, 2 objects should > be used instead of per-datastore deviations of the syntax of 1 object.
Agreed. So based on this, how about this text: The schema for <operational> MUST be a superset of the combined schema used in all configuration datastores except that YANG nodes supported in a configuration datastore MAY be omitted from <operational> if a server is not able to accurately report them. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
