Re: [netmod] Action and RPC statements

Alexander Clemm <alexander.clemm@huawei.com> Tue, 31 October 2017 17:36 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671C13FA17 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 10:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 870P1oPtSEEL for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 10:36:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B445B13F9F3 for <netmod@ietf.org>; Tue, 31 Oct 2017 10:36:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYY92656; Tue, 31 Oct 2017 17:36:13 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 31 Oct 2017 17:36:12 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 10:36:06 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "andy@yumaworks.com" <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>, Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Thread-Topic: [netmod] Action and RPC statements
Thread-Index: AQHTTv5c6Thnq3+sH0epzy6XUWpHDqL+fHIA///AowA=
Date: Tue, 31 Oct 2017 17:36:06 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com>
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> <c544a19e-2534-9355-002e-18affd12ea5a@alumni.stanford.edu> <CABCOCHQdmMYObMBCxP=qWuH3RdCRi9q7Y6G0VsSnDeyg2qLc4w@mail.gmail.com> <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
In-Reply-To: <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.80]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABACADsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59F8B48E.007E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8749b419d9e9efe6a83f53400acb7338
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/n_Y-WstD7F-6KxLKsd1DJsoHE08>
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2017 17:36:20 -0000

Hi Rob,

A few comments, inline

--- Alex

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Tuesday, October 31, 2017 7:14 AM
To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com; netmod@ietf.org; Randy Presuhn <randy_presuhn@alumni.stanford.edu>
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.”



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.

</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 <andy@yumaworks.com><mailto:andy@yumaworks.com> wrote:

On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <

randy_presuhn@alumni.stanford.edu<mailto:randy_presuhn@alumni.stanford.edu>> 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

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod

.