Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?

[Andy Bierman <[e-mail]>]

On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> 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