Re: action RPC I-D

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello,
You could just as naturally map CLI commands into actions, see below.
Some of the intermediate entities might not want / not need to understand the full data 
model, like in the sub-agent architecture, etc.
Balazs


Phil Shafer wrote:
> Martin Bjorklund writes:
> > 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.
>
> We have a rich history of failed OO-ish approaches.  IMHO the
> key to netconf lies in leveraging the existing infrastructure
> of existing CLIs.  CLIs are not oriented toward this sort of
> approach, but use more direct action verbs:
>
>     reset interface 2
>     ping foo.net
>     reboot
>     install new-sw.tgz
>
> which translate easily into direct RPCs:
>
>     <rpc ...>
>       <ping>
>         <target>foo.net</target>
>       </ping>
>     </rpc>
     <action>
       <actionName>ping</actionName>
       <callingPoint type="xpath">
         /top/interfaces/interface["ifName=eth0"]
       </callingPoint>
       <parameters>
         <target>foo.net</target>
       </parameters>
     </action>

> 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".
>
> In addition, using a string loses all the specificity that
> an XML schema tries to buy you.  Your only tool to restrict
> the content of a string is a regex, which, well, stinks when
> compared with the descriptive capabilities of schema for
> a <ping> element and its contents.
Thats why I lifted out callingPoint. Also I agree that even for other parameters we should 
not encode multiple data items in one string.
> > 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.
>  
> Let the schema (or whatever your schema is generated from) drive
> your intermediate SW components.  If your command hierarchy (and/or
> config hierarchy) drives your xml content, then the same internal
> data can drive it all.  XML schemas, XML parsers, and command parsers
> all groking the same data will help keep the schema, API, and CLI
> in sync.
>
> Thanks,
>  Phil

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