Hello, Action is just as schema-friendly as defining separate RPCs.What we gain with <action> is a guarantee that 2 bits of data callingPoint and actionName are always present. We also gain a non-mandatory recommendation that the data model should define additional data like: access control behavior (read/write/disturb-traffic or some other values), the exact parameter types, default values etc.
We believe that there are intermediate protocol handling entities that actually don't need to know more then the actionName and the callingPoint so they will not need to handle the complete data model.
Action also gives the possibility to make some syntax checks on an incoming action based just on the data model without understanding what the action actually means. (parameter checks, value ranges etc.)
BalazsPS. You will also make some companies (for example but not only Ericsson) happy that already use similar constructs, and you won't disturb others as they don't have to use this.
Phil Shafer wrote:
Martin Bjorklund writes:Phil Shafer <phil@juniper.net> wrote:Options from the "ping" command become xml elements under the <ping> element. Imagine trying to encode options under a string like "/interfaces[ifIndex="2"]/reset".This string is just to identify the action. In Balazs' draft, this identifier is split into two parts, the <calling-point> and the <name>. Parameters are passed with in <parameters> element in his draft. They would not be "encoded" into the action name.Okay, an action has a name, a target, and a set of parameters. Your suggestion puts the name and the target in a string which is uncontrolled and undocumented (as far as schema). Putting the parameters in an element won't help you constrain them, since the constraints need to be tied to the particular action. So the question is: what does a generic <action> action buy you? And are you trade that against what a schema-friendly RPC buys you? Thanks, Phil
-- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>