Martin Bjorklund wrote:
Yes it is an implementation detail, as everything else. However by ensuring that a number of data items are present in any such new RPC/action, and ensuring that they are present as separate easily recognizable bits of data we make implementation a lot easier.Andy Bierman <ietf@andybierman.com> wrote:Martin Bjorklund wrote:Andy Bierman <ietf@andybierman.com> wrote:andIn your 'restart' example, 'actionName' could just as well be the actual RPC method name, and 'callingPoint' is really just an RPC parameter, along with the entire 'parameters' sub-tree.Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:I believe handling non-standard actions is easier if we define them in the data model and not as separate operations. It particularly helps intermediate SW to handle the actions. I agree with Andy that the "end-user" of the action must always understand all new actions whatever the form used to transfer them. However there may be, there will be a number of intermediate SW blocks on the path.I also agree that a data model effort should allow for operations to be defined within the data model. However, how this is mapped to Netconf rpcs is a different question. An operation could be mapped to a generic <action> rpc, or to a new rpc for each action. I agree with the "intermediate SW argument" though.Why? This seems like an implementation-specific detail to me.Yes, since the argument is that it might be easier to design/implement/envision intermediate SW components if the structure of the rpc is well-known; I guess this argument can be rejected as being an implementation issue.
Imagine some RPCs carrying the calling-point in one place other in another place. Balazs -- 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/>