The Tail-f extension called action is used for operations that are not intended to modify the configuration datastore. Operations like “system reboot”, “software upgrade”, “interface reset” or any type of operation that is not meant to change configuration, can be modeled as an action in YANG.
An example of such modeling would be:
list server {
key name;
max-elements 64;
leaf name {
tailf:cli-allow-range;
type string;
}
tailf:action reset {
tailf:actionpoint reboot-point;
input {
leaf when {
type string;
mandatory true;
}
}
output {
leaf time {
type string;
mandatory true;
}
}
When the action is invoked, the instance on which the action is invoked is explicitly identified by an hierarchy of configuration or state data.
Actions can be placed under containers or lists.
RPC on the other hand, can only be placed as a child to the “module” statement.
An RPC looks like this:
module math-rpc {
namespace “http://example.com/math/1.0”;
prefix math;
import tailf-common {
prefix tailf;
}
rpc math {
tailf:actionpoint “math”;
input {
choice op {
container add {
leaf-list operand {
type int32;
min-elements 2;
max-elements 2;
}
}
container sub {
leaf-list operand {
type int32;
min-elements 2;
max-elements 2;
}
}
}
}
output {
leaf result {
type int32;
}
}
}
}
tailf:action is just another RPC. It is rendered as an RPC called action.
the “rpc” statement is meant to extend the standard RPCs defined in NETCONF. The name given to the “rpc” definition in YANG is the name used by the NETCONF server to identify these RPCs.
In summary:
tailf:action and rpc are 2 ways of supporting actions. The first will be rendered as an action RPC and the second as the “any given name in YANG” RPC. The first one can be placed anywhere in the model whereas the second one can only be place at the top level. “rpc” is a standard statement of YANG, tailf:action is an extension that may become standard in YANG 1.1.