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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 24 Jan 2006 16:35:49 -0500

hi

Ok. This could get fun :-)

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.

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.

Sharon

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2006 4:07 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: [email-masked]
Subject: Re: Netconf Event: Issue #1: To RCP or Not to RPC 

"Sharon Chisholm" writes:
>Note that I've always viewed the term <rpc> as a bit of a misnomer 
>since the Netconf RPC isn't really a traditional RPC. I suspect that 
>perhaps some of the disconnect on this issue might lie in how much one 
>treats <rpc> like an XML tag and how much one treats it like a 
>traditional RPC.

I'd like to jump into the pro/con debate, but first I'd like to
understand your point here, since that may be the source of my dislike
this notification encoding.  Please clue me in on why the Netconf RPC
isn't really a traditional RPC.

Thanks,
 Phil

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 25 Jan 2006 01:10:31 -0500

>Ok. This could get fun :-)

Not likely ;^)

>Personally, I think the <rpc> wrapper is much more elegant than doing

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).

>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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jan 2006 08:09:30 +0100

> completed rpc, that's intermixed with the main netconf rpc content.

Whether you need a reply depends on the semantics. Some people may
even prefer to have a reply for a notification. In fact, confirmed
notification delivery could be a reason which distinguishes netconf
notifications from syslog. If we just rebuild syslog, I tend to agree
with those who raise the very valid question why we want to do this in
the first place.

Regarding your second comment: Yes, client server roles switch for
notification delivery. This is a long known issue with many
interesting implications as we all learned over the years. But for me,
it does not really matter whether the notification sits in an rpc
frame or not - the issues that make notifications "interesting" will
remain with or without it.
 
/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Phil Shafer <[email-masked]>
Date: Wed, 25 Jan 2006 02:44:52 -0500

Juergen Schoenwaelder writes:
>If we just rebuild syslog, I tend to agree

Yup, I've said before that syslog w/ SD-Params would make me happy.

>notification delivery.

So maybe the easiest way forward (if we proceed) is to make
notifications happen over a distinct connection where the server
and client roles can be easily reversed and the notifications can
be trafficed over the existing netconf protocol elements.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jan 2006 00:07:46 -0800

>remain with or without it.

To me, an important interesting issue is whether we are standardizing
best current practices or inventing new technology.  I get very nervous
when I see proposals for features that are not currently being widely used
in the field by operators.  When two or more independent organizations
try to solve the same sort of problem, but with different solutions, in
real products, then you know the industry is ready for a standard
to solve that problem.

To quote my favorite band:
"You gave me something that I didn't have, but had no use..."

We've done that so many times in SNMP, we should be more cautious by now.

>/js

Andy