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.

> 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.

> (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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to