Re: action RPC I-D

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> 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.

Why?
This seems like an implementation-specific detail to me.
Your access control model should be more robust than
simply allowing user X to do anything called <action>.
I don't see what benefit an intermediate SW component
can realize if an extra generic container is added to <rpc>.



> 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

This is not true.
The WG or any vendor could put multiple elements in the
same namespace, just as we have <edit-config> and <copy-config>
in the same namespace now.


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

Why should action RPCs be identified differently than other RPCs?
This seems to create complexity, not reduce it.

> /martin

Andy

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