Re: action RPC I-D

[Phil Shafer <phil@juniper.net>]

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>

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.

>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

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