Re: action RPC I-D

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

Phil Shafer <phil@juniper.net> 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.

No, they wouldn't be uncontrolled, just as parameters within an
edit-config are not uncontrolled.

But anyway, I just said that I do agree with the "intermediate SW
argument", i.e. using a well-known <action> rpc might make it easier
to write this kind of software.

As an example, suppose you have a set of hosts, each with a set of
services, and a service can be reset.  Using a normal rpc, this reset
could be:

  <reset-service-in-host>
    <host>foo</host>
    <service>web</service>
    <when>now</when>
  </reset-service-in-host>

Using the <action>, with Balazs syntax,

  <action>
    <callingPoint>/hosts/host[name="foo"]/service[name="foo"]</callingPoint>
    <name>reset</name>
    <parameters>
      <when>now</when>
    </parameters>
  </action>

My only point is that the latter might be easier for a SW component
like a master agent.


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