Hi Andy,
To try and formally close this issue: We propose that no changes are
made to the NMDA draft.
I think that you have raised two issues in this thread:
(1) All YANG actions in an NMDA server are invoked against <operational>.
We generally agree that module defined actions, and module defined RPCs
and notifications, will generally apply to the operational state of a
system, but this won't necessarily universally hold. In particular it
may not hold for any YANG modules that are defining generic behaviour
(e.g. inactive configuration, templating solutions, I2RS, etc). We
don't think that this needs to be specified in the NMDA datastores
draft, but would be better documented in a future revision of YANG.
(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?
Thanks,
Rob
On 18/10/2017 23:16, Andy Bierman wrote:
On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:
> On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
> [email protected]
<mailto:[email protected]>> wrote:
>
> > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > > > >
> > > > > augment "/if:interfaces-state/if:interface" {
> > > > > action reset {
> > > > > description "Reset this interface";
> > > > > }
> > >
> > > Can you spot the NMDA problem above?
> > > Actually, it exists for in-line definitions, not just augment.
> > >
> > > Once you collapse the interfaces-state tree into
/interfaces, there
> > > is no way to specify whether an action is intended for
<operational>
> > > or a configuration datastore, or all datastores.
> >
> > I think operations (both RPCs and actions) by default always
execute
> > in the context of the operational state datastore. This is
consistent
> > with the way we define the xpath context. An operation that
operates
> > on other datastores needs to carry this information in its
semantics
> > and typically requires special arguments to select the datastores
> > affected. This is how <get-config> and <edit-config> work.
Hence, a
> > reset action defined for an interface by default applies to the
> > operational state datastore. And this default makes likely
sense for
> > most actions and RPCs.
> >
> > If an action or RPC is expected to operate on a different
datastore,
> > the description must explain this and there may be a need to
pass a
> > datastore identifier to the operation. [Yes, in retrospect,
one might
> > have designed the protocol differently so that there would
always be a
> > datastore parameter at the protocol level but its too late for
that.]
> >
> >
>
> IMO this needs to be simple and deterministic.
> All YANG actions in an NMDA server are invoked against
<operational>.
>
Well, yes, like all RPC operations - except that we have RPC
operations that do act on other datastores. ;-) But the generic
mechanism including any xpath contexts is against operational. If the
semantics of the operation that say 'interpret parameter 5 as a
datastore name and act on that datastore', well then this is what the
designer wanted. This is how edit-config and friends work today.
Except this approach is ad-hoc and sub-optimal.
That's why NMDA <get-data> is better (because it is extensible yet not
ad-hoc).
IMO an <action2> wrapper would be a good addition for a YANG update
<action2>
<datastore>rd:running</datastore>
<top>
<foo>
<test-action>
...
</test-action>
</foo>
</top>
</action2>
It is better to keep the YANG model decoupled from datastores,
and use a protocol parameter to make it explicit.
/js
Andy
--
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/
<http://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
