Subject: Re: [netmod] Action and RPC statements

From: Robert Wilton <[email-masked]>
Date: Wed, 1 Nov 2017 11:42:43 +0000

Hi Alex,

On 31/10/2017 17:36, Alexander Clemm wrote:
>
> Hi Rob,
>
> A few comments, inline
>
> --- Alex
>
> *From:*netmod [mailto:[email-masked]] *On Behalf Of *Robert 
> Wilton
> *Sent:* Tuesday, October 31, 2017 7:14 AM
> *To:* Martin Bjorklund <[email-masked]>; [email-masked]; 
> [email-masked]; Randy Presuhn <[email-masked]>
> *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<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
>
>         [email-masked]
>         <mailto:[email-masked]>> 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
>
>     [email-masked] <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>     .
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Nov 2017 12:53:08 +0100

On Wed, Nov 01, 2017 at 11:42:43AM +0000, Robert Wilton wrote:
> YANG list for dynamic/configuration subscriptions then a subscription can be
> created either via configuration or as an RPC operation.
> 

I do not think any changes are needed, section 5.3.4 is pretty clear
that the origin 'intended' applies to configuration provided by
<intended>. If you at the options, there is pretty much only
'learned' applicable.

/js

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

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 1 Nov 2017 18:00:15 +0000

> -----Original Message-----
...
> > 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 do not think any changes are needed, section 5.3.4 is pretty clear that the
> origin 'intended' applies to configuration provided by <intended>. If you at
> the options, there is pretty much only 'learned' applicable.
> 

It may be clear that "intended" may not be the right choice, but what is?  I think it does not hurt to be explicit about it.  This way, people don't have to guess if it should be learned, or maybe system, or possibly even unknown.  In its current definition, "learned" only talks about "protocol interactions with other systems ... such as routing protocols, DHCP, etc." If it is "learned" then update its definition to something like

learned: represents configuration that has been learned via
      protocol interactions with other systems, including protocols such
      as link-layer negotiations, routing protocols, DHCP, etc, or as a side effect of RPCs. 

--- Alex

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 1 Nov 2017 18:30:56 +0000

Thanks, Rob
--- Alex

From: Robert Wilton [mailto:[email-masked]]
Sent: Wednesday, November 01, 2017 4:43 AM
To: Alexander Clemm <[email-masked]>; Martin Bjorklund <[email-masked]>; [email-masked]; [email-masked]; Randy Presuhn <[email-masked]>; Phil Shafer <[email-masked]>
Subject: Re: [netmod] Action and RPC statements

Hi Alex,

A few comments, inline

--- Alex

From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Tuesday, October 31, 2017 7:14 AM
To: Martin Bjorklund <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Randy Presuhn <[email-masked]><mailto:[email-masked]>
Subject: Re: [netmod] Action and RPC statements

Hi,

Here is another attempt for proposed text for Actions/RPC statements in NMDA.

<new>

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

On a related note, I also want to confirm that it is right that RPC input data is always checked against operational:

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

Andy Bierman <[email-masked]><mailto:[email-masked]> wrote:

[email-masked]<mailto:[email-masked]>> wrote:

Hi -

Hi ,

explicitly

OK?

statements.

a specific datastore.

/martin

netmod mailing list

[email-masked]<mailto:[email-masked]>

.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Nov 2017 20:26:54 +0100

>       as link-layer negotiations, routing protocols, DHCP, etc, or as a side effect of RPCs. 

I do think that the choice is clear enough if you read the origin
value definitions. The point is that we can't cover all cases. Even if
we name side effects of RPCs (which is BTW not correct since some RPCs
do as a side effect modify configuration datastores), the next person
is going to say we do not cover YANG actions or certain SNMP sets or.

/js