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

[Juergen Schoenwaelder <[e-mail]>]

It seems we are jumping between topics. I will skip over comments
concerning the YANG library and whether it is OK or not OK that YANG
library allows different schemas in different datastores.

On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
> On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
> [e-mail]> wrote:
> 
> > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> > >
> > > IMO the more complex NMDA is to implement, the less likely it will
> > > be implemented.  If you want the tools to figure out the correct
> > > datastore(s) from description-stmts instead of something
> > > deterministic and machine-usable, NMDA is less likely to be
> > > implemented.
> >
> > There is nothing machine readable today that tells you which argument
> > of get-config identifies the datastore that is being accessed by
> > get-config. Our reasoning is that for most actions that default is
> > going to do the right thing. If there is a need to have further
> > language support to handle the cases where operations may relate to
> > datastores different than operational, then this should be taken up by
> > a future version of YANG.
> >
> >
> There is only 1 schema tree now in pre-NMDA so it is easy to parse
> instance data against the one and only set of modules.
> 
> 
> 
> > > Given that the same objects can be defined differently in each
> > > datastore in NMDA, it is especially useful to know which set of YANG
> > > modules applies, before parsing instance data against those modules.
> >
> > I am not sure I parse this correctly.
> >
> 
> The new YANG library requires the implementation to know the datastore
> to pick the correct set of modules for the datastore used in the operation.
> Module sets are allowed to overlap, so the same module can be different
> in <running> vs. <operational>.
> 
> Developers unaware of the new NMDA complexities should read the drafts
> again.
> 
> 
> 
> >
> > > (2) Define <action2>:
> > > >
> > > > I'm not convinced that this is really required/helpful, given that most
> > > > actions are likely to only apply to operational.  If it turns out that
> > this
> > > > is particularly useful then I would propose that this is deferred
> > until a
> > > > future revision of NETCONF, particularly because we are trying to keep
> > the
> > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > > >
> > > > Is this OK?
> > > >
> > >
> > > The NMDA theme has been to declare things that are possible in pre-NMDA
> > > but not supported in post-NMDA to be not useful, so this can be left to
> > > vendors I guess.
> >
> > Not sure I understand this either.
> >
> > If you have a concrete change proposal, perhaps the discussion becomes
> > more concrete and productive.
> >
> 
> 
> I already said to declare that <action> is invoked in <operational>. Period.
> No description-stmt exceptions.
>
> If another datastore is needed, use rpc-stmt instead of action-stmt.

So you are fine if for RPCs description statements can define which
datastores are affected by an RPC? I probably did not get that you
make a distinction between actions and RPCs here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>