Re: [netmod] Action and RPC statements

Robert Wilton <rwilton@cisco.com> Tue, 31 October 2017 17:13 UTC

Return-Path: <rwilton@cisco.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 9416013F9E3 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 10:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 nE6Qk--SOW9S for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 10:13:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF8E13F9E5 for <netmod@ietf.org>; Tue, 31 Oct 2017 10:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2013; q=dns/txt; s=iport; t=1509469979; x=1510679579; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fd8rDaDMYeSnD1vTZ0E5B7z1RsK9F5rv18+2w6qgKRI=; b=dRPuPBAUNMk2OhG4OJUai+oXM+7A6VqlxpqXbfPhxH7AZ0LBkHOEHD/n EEBlZ2AFbVs0HLVrmmPvxRc0n2SkNI6Fe1leA8CvBog6eoZz4ZTjAPTBS 4YgNiLid2feof0+RiWC3KQ5GWnAcTBP0JssUUTZwf8zForZi01zgLYUQK A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQDirfhZ/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUxhCOLE5AdlkKCEQqFOwKFNBYBAgEBAQEBAQFrKIUdAQEBAwE?= =?us-ascii?q?jDwEFUQsOCgICJgICVwYBDAgBAYoXCKhogieLDQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2BD4Ifg1qBaSmDAYR7gyuCYQWiBpR8i3SHOo4mh2yBOSYHKoFrNCEIHRW?= =?us-ascii?q?DLoJbHIEoP0GJSiyCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,324,1505779200"; d="scan'208";a="698352356"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2017 17:12:57 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9VHCv7c021791; Tue, 31 Oct 2017 17:12:57 GMT
To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, netmod@ietf.org, Randy Presuhn <randy_presuhn@alumni.stanford.edu>
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> <20171031151415.o45uexttym2eqp6n@elstar.local>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <010e52e2-689f-40a3-aa90-15cc23f0bc7e@cisco.com>
Date: Tue, 31 Oct 2017 17:12:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171031151415.o45uexttym2eqp6n@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OaO4DyK9TawhZxLIKwBXuKZ14s4>
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:13:03 -0000


On 31/10/2017 15:14, Juergen Schoenwaelder wrote:
> On Tue, Oct 31, 2017 at 02:14:20PM +0000, Robert Wilton wrote:
>
>> 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.
> Yes.
>   
>> 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>.
> How is this different from say partial locks (RFC 5717)? Note that in
> your example, you carry an xpath value as part of the RPC invocation
> to the server and the RPC code on the server then is interpreting the
> xpath value; this is not the same has having an xpath expression in
> the definition of the RPC itself (e.g., as part of a constraint).
OK, thanks for the explanation, I get the distinction.

But what about if the input parameter was an instance-identifier (that 
you want to be resolved against the configuration datastore)? Wouldn't 
RFC 7950 section 9.13 + NMDA Sec 6.1 force that leaf in the input data 
to be resolved against <operational> instead?

>
> I believe we previously concluded that xpath expressions that are part
> of the schema definition of an RPC / action are evaluated against
> <operational>. I think this is a reasonable interpretation and we
> can't affort a vaguely defined xpath context here.
I don't think that it would necessarily be vaguely defined, instead it 
would be the description that defines the XPath context to use, 
defaulting to operational if not specified otherwise.

However, having said that, I can't think of a realistic example of when 
a must/when statement for an RPC against a configuration datastore would 
be useful ...

Thanks,
Rob


>
> /js
>