HI,
To me, the term "Remote procedure call" means do something
on the "server". Thus, maybe all might find it easier
to take if it was
<RPC-REQUEST>
<LOG-EVENT-REPORT>
/* data for the event report */
</LOG-EVENT-REPORT>
</RPC-REQUEST>
With this way of thinking, then you might then add
<RPC-REQUEST>
<LOG-PERIODIC-SAMPLE>
/* data for periodic sample that is sent by
the managed node to a manager, based on
a configured reporting system */
</LOG-PERIODIC-SAMPLE>
</RPC-REQUEST>
Now whether or not you always want a reply to the RPC-REQUEST,
that is a different issue. This issue exists for both
"SETs" and "ACTIONs", when the response returns "no data"
and indicates only that the request was successful.
I believe that you should always send an "applcation level"
indication that a request is success, and that the protocol
should allow multiple requests to be "in flight" upto a
configurable max (not unlimited). Thus, event reporting
and SETs and GETs will all look the same.
On Tue, 24 Jan 2006, Andy Bierman wrote:
Sharon Chisholm wrote:
hi
As Juergen suggested, I'm going to start off pros/cons list of having
something at the RCP-layer in the Netconf Notification Solution. My list
on each side is shorter than I was hoping, but it hopefully can start
things off for us.
In short though, once you have the Netconf Layers diagrammed engrained
in your head, honouring these layers by having an rpc-layer wrapper
seems to be the simplest solution. Removing it seems more like an
optimization that says well, this new wrapper only can contain one type
of operation, so why have it? I see the efficiency in removing it, but
think we need to be careful about future proofing the architecture.
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.
Pros
----
1) Other netconf operations are wrapped in something in the RPC-layer.
It seems cleanest to also wrap the <notifications> in this layer. (Ease
of understanding, ease of processing, etc)
This is where we really disagree.
IMO, a notification is not an operation.
You are not executing an operation on the remote peer.
You are simply notifying the remote peer of something.
In my code anyway, the <rpc> node is processed in the
same manner for all RPC methods. If I had to look ahead
to see if this <rpc> was really some kind of special notification
instead, this will complicate processing, not simplify it.
Cons
----
1) If there is only one type of asynchronous message, then we can save
some bits on the wire, but only having one wrapper instead of two.
I think this pros and cons list is really missing the point, and masks
some important decisions the WG has to make:
1) Are we standardizing notifications based on syslog, or creating
something entirely different?
2) How should our design deal with unspecified, unknown,
future extensions to the initial document?
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
Andy
Regards,
/david t. perkins
--
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/>