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

[Martin Bjorklund <[e-mail]>]

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