Re: [netmod] YANG action not allowed at root?

Christian Hopps <chopps@chopps.org> Tue, 05 May 2020 08:37 UTC

Return-Path: <chopps@chopps.org>
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 075A63A15D3 for <netmod@ietfa.amsl.com>; Tue, 5 May 2020 01:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 wmGq23caPrp9 for <netmod@ietfa.amsl.com>; Tue, 5 May 2020 01:37:21 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 674773A15D2 for <netmod@ietf.org>; Tue, 5 May 2020 01:37:21 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A897E611EC; Tue, 5 May 2020 08:37:20 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <DM5PR08MB263359FB2993EC569444A4539BAA0@DM5PR08MB2633.namprd08.prod.outlook.com>
Date: Tue, 05 May 2020 04:37:19 -0400
Cc: Christian Hopps <chopps@chopps.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0533F71D-C017-40A5-B953-21FFF9CBD1FB@chopps.org>
References: <AE95765B-0561-45DC-A4A8-E8B3BCE4BB12@cisco.com> <DM5PR08MB263359FB2993EC569444A4539BAA0@DM5PR08MB2633.namprd08.prod.outlook.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4w1DMrGfuaTBM0BXGwTnIHQ22u0>
Subject: Re: [netmod] YANG action not allowed at root?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 05 May 2020 08:37:23 -0000

An action is defined as being something bound to a node. Talking about actions that aren't bound to a node is talking about RPCs AFAICT. In the server it just comes down to passing the bound node data in to the function or not. Defining "unbound actions" to replace RPCs is just different syntax for the same thing, right? Having 2 ways to do the same thing wouldn't help make servers easier to implement (it would do the opposite actually).

Thanks,
Chris.

> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:
> 
> Yes - the intent was to address the limitation that an RPC can only be at root. Actions can be out in a tree & nicely associated with something (e.g. instead of having a pile of flat RPCs with long names that encode containers like reset-www-xxx-yyy-zzz-entity).
>  
> But I don't really understand why we limited actions from being at the root. It prevents a strategy of implementing all operations in a server (some of which may be desirable at root for various reasons, some of which may be desirable in the tree) as actions.
>  
> Why not allow this?
>  
>    module bar {
>          action do-stuff {
>            input {
>              leaf iterations {
>                type uint8;
>               }
>             }
>          } 
>        } 
>    } 
>  
> Which could be called from NETCONF like this:
>  
>      <rpc message-id="101"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>        <action xmlns="urn:ietf:params:xml:ns:yang:1">
>          <do-stuff xmlns="urn:example:bar">
>            <iterations>5</iterations>
>          </do-stuff>
>        </action>
>      </rpc>
>  
>  
> Jason
>  
> From: Reshad Rahman (rrahman) <rrahman@cisco.com> 
> Sent: Thursday, April 30, 2020 11:31 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
> Subject: Re: [netmod] YANG action not allowed at root?
>  
> I don’t know the history on this but the intent is to have action tied to a data node.
>  
> https://tools.ietf.org/html/rfc7950#section-7.15
>    The difference between an action and an rpc is that an action is tied
>    to a node in the datastore, whereas an rpc is not.  When an action is
>    invoked, the node in the datastore is specified along with the name
>    of the action and the input parameters.
>  
> Regards,
> Reshad.
>  
> From: netmod <netmod-bounces@ietf.org> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
> Date: Thursday, April 30, 2020 at 11:08 AM
> To: "netmod@ietf.org" <netmod@ietf.org>
> Subject: [netmod] YANG action not allowed at root?
>  
> Hi all,
>  
> I was a bit surprised to find this in section 7.15 of 7950 recently:
>  
>    Since an action cannot be defined at the top level of a module or in
>    a "case" statement, it is an error if a grouping that contains an
>    action at the top of its node hierarchy is used at the top level of a
>    module or in a case definition.
>  
> I realize that actions can be placed down in a schema tree (i.e. sit in the context of a container or list), but why is it phrased that they *must* be in a container?
>  
> RPCs are limited to being at the root. I would have thought actions could be anywhere (root or down in the tree).
>  
> Jason
>  
>  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod