Re: [netmod] Action and RPC statements

[Kent Watsen <[e-mail]>]

Hi Robert,

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

s/MAY/may/? - is this draft providing for this, or should it come from
e.g., RFC 7950?


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

I reordered first sentence, and added a comma to the second:

RPCs modify the general operational state of the server, unless
explicitly defined to affect other datastores. 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. 

okay

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

fixed plurality issue in first sentence, and removed wishy-washy 
language from the rest:

Actions are always invoked on a data node instance that exists in the 
<operational> data tree.  Action statements affect the operational
state of the server.


What do you think?

Kent // contributor