On Wed, Jan 25, 2006 at 01:10:31AM -0500, Phil Shafer wrote:
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.
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.