On 2020-05-05 11:00, Martin Björklund wrote: > Hi, > > If we were to redo YANG, I would prefer to have a single statement > "operation", either on the top-level, or tied to a node.
So, no rpc statement, and thereby no possibility to extend NETCONF with new RPCs? (Or to be precise, YANG would extend NETCONF with exactly one RPC, called "operation"?) --Per > /martin > > Christian Hopps <[email protected]> wrote: >> 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) >>> <[email protected]> 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) <[email protected]> >>> Sent: Thursday, April 30, 2020 11:31 AM >>> To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; >>> [email protected] >>> Subject: Re: [netmod] YANG action not allowed at root? >>> >>> I dont 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 <[email protected]> on behalf of "Sterne, Jason >>> (Nokia - CA/Ottawa)" <[email protected]> >>> Date: Thursday, April 30, 2020 at 11:08 AM >>> To: "[email protected]" <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
