Re: [netmod] Action and RPC statements

[Robert Wilton <[e-mail]>]

Hi Alex,


On 31/10/2017 17:36, Alexander Clemm wrote:
>
> Hi Rob,
>
> A few comments, inline
>
> --- Alex
>
> *From:*netmod [mailto:[e-mail]] *On Behalf Of *Robert 
> Wilton
> *Sent:* Tuesday, October 31, 2017 7:14 AM
> *To:* Martin Bjorklund <[e-mail]>; [e-mail]; 
> [e-mail]; Randy Presuhn <[e-mail]>
> *Subject:* Re: [netmod] Action and RPC statements
>
> Hi,
>
> Here is another attempt for proposed text for Actions/RPC statements 
> in NMDA.
>
> <new>
>
> 6.2 Invocation of RPC Operations
>
> This section updates section 7.14 of RFC 7950.
>
> RPCs MAY be defined as affecting the contents of a specific datastore,
> any configuration datastore (e.g., <edit-config>), or any datastore
> (e.g., <get-data>).  The RPC definition specifies how the RPC input
> data is interpreted by the server.
>
> <ALEX> why “e.g., <get-data>”?  Does <get-data> affect the contents of 
> the datastore – I thought it just gets data, hence this example is not 
> ideal.
>
> There is also no mention about the source of the “in” parameters.  It 
> probably makes sense to mention that explicitly.
>
> Perhaps something along the lines of “RPCs MAY be defined as 
> _/relating/_ to the contents of a specific datastore….   Input data 
> resolves to <operational>, as does output data, as do RPC side 
> effects“.  Then below
>
> “RPCs definitions that do not explicitly state an affected
> datastore(s) _/refer_to/_  the general operational state of the server.”
>
Yes, that makes sense.

> One other comment, it would be good to also indicate that when an RPC 
> leads to modification of data nodes, what the “origin” of those 
> modifications is.
>
That is an interesting question.

To describe this as a concrete example, if you have a single config true 
YANG list for dynamic/configuration subscriptions then a subscription 
can be created either via configuration or as an RPC operation.

I would probably classify this as "learned", and I think that we could 
extend the definition of the "learned" origin to cover this case.

Thanks,
Rob


> </ALEX>
>
>
>
> RPCs definitions that do not explicitly state an affected
> datastore(s) modify the general operational state of the server.
> Hence, if any RPC input data relates to data node instances then
> those would generally resolve to data node instances in the
> <operational> data tree.
>
>
> 6.3 Invocation of Actions
>
> This section updates section 7.15 of RFC 7950.
>
> In YANG data models, the "action" statement may appear under "config
> true" and "config false" schema nodes.  While instances of both
> schema nodes may appear in <operational>, instances of "config true"
> schema nodes may also appear in other datastores.
>
> Actions are always invoked on a data node instance that exist in the
> <operational> data tree.  The behavior defined by an action statement
> is generally expected to affect the operational state of the server
> rather than directly modifying the contents of any configuration
> datastore.
>
> </new>
>
>
> On a related note, I also want to confirm that it is right that RPC 
> input data is always checked against operational:
>
> Section 6.1. of the NMDA draft states:
>
>
>    o  If the XPath expression is defined in a substatement to an "input"
>       statement in an "rpc" or "action" statement, the accessible tree
>       is the RPC or action operation instance and all operational state
>       in the server.  The root node has top-level data nodes in all
>       modules as children.  Additionally, for an RPC, the root node also
>       has the node representing the RPC operation being defined as a
>       child.  The node representing the operation being defined has the
>       operation's input parameters as children.
>
>
>
> Is <operational> always the right datastore to evaluate RPC 
> input/output data relative to?  For most RPCs this seems to be the 
> right choice by default but it also seems plausible that someone may 
> wish to define an RPC that wants to validate its input parameters 
> against the contents of another datastore.
>
> An example could be an "is-applied" RPC that takes a path to a subtree 
> in <running> or <intended> and checks whether the configuration for 
> that subtree is fully represented in <operational>.
>
> Thanks,
> Rob
>
> On 27/10/2017 09:33, Martin Bjorklund wrote:
>
>     Andy Bierman<[e-mail]> <mailto:[e-mail]>  wrote:
>
>         On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
>
>         [e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Hi -
>
>             On 10/26/2017 10:44 AM, Robert Wilton wrote:
>
>                 Hi ,
>
>                 Separating out the issue regarding which datastore action and RPC apply
>
>                 to, we propose the following NEW text to the datastores draft:
>
>                 6.2 Invocation of Actions and RPC Operations
>
>                     This section updates section 7.15. of RFC 7950.
>
>                     In YANG data models, the "action" statement may appear under "config
>
>                     true" and "config false" schema nodes.  While instances of both
>
>                     schema nodes may appear in <operational>, instances of "config true"
>
>                     schema nodes may also appear in other datastores.
>
>                     An NMDA compliant server MUST execute all actions in the context of
>
>                     <operational>.  Likewise, an NMDA compliant server MUST invoke all RPC
>
>                     operations in the context of <operational>, unless the RPC is
>
>                 explicitly
>
>                     defined as affecting other datastores (e.g., <edit-config>).
>
>                 OK?
>
>             A question - I understand the motivation for the "unless" for RPC
>
>             operations, but wonder why there is no similar "unless" for actions.
>
>         The <rpc> is not really in a datastore at all.
>
>         It may have input and output parameters with leafref and must/when
>
>         statements.
>
>         These are evaluated in the <operational> context.
>
>         The <rpc> may in fact be something like <edit-config>
>
>         which has parameters (like <config> to apply to
>
>         a specific datastore.
>
>         The action node is embedded within some data that has to be parsed
>
>         in a specific datastore before the action is processed.
>
>         This data is required to be in <operational>.
>
>         It also has XPath and leafref that needs to be resolved (same as <rpc>).
>
>         The side effects of the <rpc> or <action> can impact other datastores.
>
>         This would be defined in the description-stmt and this is not a problem.
>
>     This is exactly right.  We need to capture this in the text.
>
>     /martin
>
>     _______________________________________________
>
>     netmod mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>     .
>