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

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 
> <j.schoenwaelder@jacobs-university.de 
> <mailto:j.schoenwaelder@jacobs-university.de>> 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 <
>     > j.schoenwaelder@jacobs-university.de
>     <mailto:j.schoenwaelder@jacobs-university.de>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod