Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>I think that managing 100s or 1000s of <get-foo> and
>even <set-foo> functions, which ignores the <candidate>,
><running>, <startup> model variants, ignores <edit-config>,
>and does not show up at all when I do a <copy-config>,
><get-config>, or <get> operation -- is a fairly broken design.

I don't think it's broken at all.  I think this is the point of using
an RPC-based design.  There are two reasons that I think this is a
win.  First, it's a better match for applications.  More specific
information in the API makes it a better API, both more readable and
more easily implemented.  Your unix program doesn't get filesystem
information using get() or even ioctl().  It uses statfs() to get this
data.  It's a direct, easily documented mechanism for getting
this particular content.  The same is true for RPCs.  I'd rather have:

    $results = $dev->get_syslog_streams();

than:

    $results = $dev->get("netconf/notifcations/config/whatever");

(or worse, having to build the xml object)

It's similar to calling read() verses calling syscall() with the SYS_read
system call number.

Second, we're not making a green field solution.  Device vendors have
a ton of code supporting existing CLI commands, all brimming with
information accessible via the command line.  So I go in and make a
<rpc-name> to "command line" mapping, and get all the fancy command
line arguments, types, ranges, help strings, etc for free.  All this
is fairly trivial code.

But to do this scoped generic stuff, I need to understand a _whole_
lot more about the output of the commands, including not only which
commands make which output tags, but which _options_ to those
commands make the output.  "show interfaces extensive" .vs. "show
interfaces statistics".  This is an immense pain.

I'd basically have to build a completely new management system.  I've
said it before, but I continue to believe that netconf will fail if it
becomes the "third way" (where first=cli and second=snmp).  In the
real world, the CLI gets implemented first, then SNMP (first
proprietary MIBs, then standard MIBs).  A completely disjoint netconf
implementation will a distant third.  We need to maximize the leverage
we can get off the existing implementations, not become the third way.

This was discussed at length in the prelude to netconf's creation.
One of our goals was allowing the vendor to reuse their cli
implementation to the greatest extent possible.

In addition, the use of explicit RPCs gives you explicit arguments,
which you need (or may need in the future) to refine the information
retrieved.  Or you may want your API for retrieving data to match the
API for manipulating it, in the same way the <source> parameter for
<get-config> matches the <source> parameter for <lock-config>,
<unlock-config>, <edit-config>, <validate>, etc.

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