Re: action RPC I-D

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> In 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.

and 

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.

Andy Bierman <ietf@andybierman.com> wrote:
> IMO, the agent and manager MUST know the security and
> other requirements a priori anyway (via a schema), so
> some generic 'container' for actions does not provide any
> real value -- just extra XML.

We could apply this argument to e.g. edit-config - why is edit-config
needed at all?  Vendors could define their own <edit-bla-bla> rpcs, and
the <target> could have been some parameter (possibly different
paramtere names all the time) in <edit-bla-bla>.


Andy Bierman <ietf@andybierman.com> wrote:
> How do you manage the allocation of action names?

Without a <action> wrapper each operation name would have to be unique
per namespace.  With an <action> rpc, the operation could be
identified with an "OID" and the action name, which could be a subtree
expression or a XPath expression (such as
/interfaces/[ifIndex="2"]/reset).  This means that the action name
would be unique per "object".  The callping-point parameter would not
be needed in this case either.



/martin

--
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/>