Re: action RPC I-D

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

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

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.


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

I didn't think of the access control model, but maybe that is a good
example.  It will be more complicated to design an ACM which has to look
into any nested XML structure for a parameter in some format which
points to an object.


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

I didn't say that there could be a single operation per namespace, I
said that the operation name has to be unique within it's namespace.


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

It's not identified differently, I wasn't clear - I meant something
like this:

  <action xmlns="...generic-action/1.0">
    <name>/interfaces[ifIndex="2"]/reset</name>
  </action>

more of an OO style I guess - execute the 'reset' action on the
'/interface[ifIndex="2"]' object.



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