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. > > No, you cannot deviate the same schema node in different ways. You can define or deviate 2 different schema nodes. That is the unacceptable change to YANG and why I like the OC solution better. > 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). > > Agreed. A vendor can provide unusable APIs with any YANG module, given the right deviations, so this cannot be a factor. But the OC solution did not allow features to be different at all. 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. > > Correct but maybe irrelevant. I am only concerned with the same schema node being different in multiple datastores. This was never part of the OC requirement. Each datastore can implement a specific subset of all the server modules. That part is well-defined and the framework allows for lots of innovation here without modifying YANG at all. > 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? > Non-overlapping subsets are fine. Overlapping subset but the details are the same for each module are fine. > > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
