Re: [netmod] YANG action not allowed at root?

[Per Hedeland <[e-mail]>]

On 2020-05-05 11:00, Martin Björklund wrote:
> Hi,
>
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.

So, no rpc statement, and thereby no possibility to extend NETCONF
with new RPCs? (Or to be precise, YANG would extend NETCONF with
exactly one RPC, called "operation"?)

--Per

> /martin
>
> Christian Hopps <[e-mail]> wrote:
>> An action is defined as being something bound to a node. Talking about
>> actions that aren't bound to a node is talking about RPCs AFAICT. In
>> the server it just comes down to passing the bound node data in to the
>> function or not. Defining "unbound actions" to replace RPCs is just
>> different syntax for the same thing, right? Having 2 ways to do the
>> same thing wouldn't help make servers easier to implement (it would do
>> the opposite actually).
>>
>> Thanks,
>> Chris.
>>
>>> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa)
>>> <[e-mail]> wrote:
>>>
>>> Yes - the intent was to address the limitation that an RPC can only be
>>> at root. Actions can be out in a tree & nicely associated with
>>> something (e.g. instead of having a pile of flat RPCs with long names
>>> that encode containers like reset-www-xxx-yyy-zzz-entity).
>>>
>>> But I don't really understand why we limited actions from being at the
>>> root. It prevents a strategy of implementing all operations in a
>>> server (some of which may be desirable at root for various reasons,
>>> some of which may be desirable in the tree) as actions.
>>>
>>> Why not allow this?
>>>
>>>    module bar {
>>>          action do-stuff {
>>>            input {
>>>              leaf iterations {
>>>                type uint8;
>>>               }
>>>             }
>>>          }
>>>        }
>>>    }
>>>
>>> Which could be called from NETCONF like this:
>>>
>>>      <rpc message-id="101"
>>>           xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>>>        <action xmlns="urn:ietf:params:xml:ns:yang:1">
>>>          <do-stuff xmlns="urn:example:bar">
>>>            <iterations>5</iterations>
>>>          </do-stuff>
>>>        </action>
>>>      </rpc>
>>>
>>>
>>> Jason
>>>
>>> From: Reshad Rahman (rrahman) <[e-mail]>
>>> Sent: Thursday, April 30, 2020 11:31 AM
>>> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>;
>>> [e-mail]
>>> Subject: Re: [netmod] YANG action not allowed at root?
>>>
>>> I dont know the history on this but the intent is to have action tied
>>> to a data node.
>>>
>>> https://tools.ietf.org/html/rfc7950#section-7.15
>>>    The difference between an action and an rpc is that an action is tied
>>>    to a node in the datastore, whereas an rpc is not.  When an action is
>>>    invoked, the node in the datastore is specified along with the name
>>>    of the action and the input parameters.
>>>
>>> Regards,
>>> Reshad.
>>>
>>> From: netmod <[e-mail]> on behalf of "Sterne, Jason
>>> (Nokia - CA/Ottawa)" <[e-mail]>
>>> Date: Thursday, April 30, 2020 at 11:08 AM
>>> To: "[e-mail]" <[e-mail]>
>>> Subject: [netmod] YANG action not allowed at root?
>>>
>>> Hi all,
>>>
>>> I was a bit surprised to find this in section 7.15 of 7950 recently:
>>>
>>>    Since an action cannot be defined at the top level of a module or in
>>>    a "case" statement, it is an error if a grouping that contains an
>>>    action at the top of its node hierarchy is used at the top level of a
>>>    module or in a case definition.
>>>
>>> I realize that actions can be placed down in a schema tree (i.e. sit
>>> in the context of a container or list), but why is it phrased that
>>> they *must* be in a container?
>>>
>>> RPCs are limited to being at the root. I would have thought actions
>>> could be anywhere (root or down in the tree).
>>>
>>> Jason
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>