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

["David T. Perkins" <dperkins@dsperkins.com>]

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