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? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
