Re: Netconf Event: Issue #1: To RCP or Not to RPC

[Phil Shafer <phil@juniper.net>]

"Sharon Chisholm" writes:
>Ok. This could get fun :-)

Not likely ;^)

>So, while I can bend the definition  of an RPC
>(http://www.cs.cf.ac.uk/Dave/C/node33.html) to kind of make it fit to
>what we are doing in Netconf, the fact is that even without a tag called
><rpc> we would still have
>	- A connection between the client and server
>	- The ability to execute a command on the server 
>We couldn't get the response, but we could have designed around it.
>Personally, I think the <rpc> wrapper is much more elegant than doing
>that.

I don't really follow you here, but it seems your example is a
level above netconf.  The URL talks about sunrpc's IDL and the
XDR functions to encode data for it.  We're more of the rfc1831
layer, where we're defining the bits over the wire, not the
C-language interface to make those bits.  One could even make a
version of rpcgen that generates netconf calls <evil grin/>.

Anyhow, let's pretend we're happy with netconf's rpc model, cause
I don't see it changing.  I don't really see it as untraditional,
in that it allows remote access to well-defined functions that accept
a set of input arguments and return a set of output data.  This allows
one to sit in a high level language and say stuff like:

  $status = $jnx->commit_configuration(confirmed => true, timeout => 30);

without knowing any details of the what's really going on.

What I find disturbing about <one-way-rpc> is (a) it's not an rpc,
in the sense that it doesn't have a reply, and (b) it's going the
wrong direction.  You've got the server sending data to the client,
which is definitely not an rpc.  I tried to think of it as some sort
of callback, but it's not really that either.  It's really is a
distinct channel of information, an ongoing reply to an already
completed rpc, that's intermixed with the main netconf rpc content.

All of which makes me wish we could resurrect the channels into
netconf, but I don't really see this happening.  Short of that,
we're stuck with the server sending asynchronous data to the
client, intermixed over the main rpc channel/stream.

Well, I guess we could do notifications as long-lived RPCs, where
I eat the entire connection with a <get-notifications> RPC that
only completes when the client <abort>s it (or closes the
connection).

>It is its role as a wrapper that we are trying to mimic. Perhaps we
>should rename it to <one-way-message> and loose the rpc bit. That might
>make things cleaner while still maintaining some alignment.

Choosing a better name will help, but the question Andy was asking is
what else would we ever want the server to spontaneously and/or
asynchronously send to the client that would behave exactly like the
behavior we're defining for notifications that is not a notification?
Unless we see something generic that will follow our fairly specific
rules, what do we win by having <one-way-whatever>?

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