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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 24 Jan 2006 15:48:17 -0500

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)

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.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
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: Tue, 24 Jan 2006 16:07:23 -0500

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 24 Jan 2006 15:32:50 -0800

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

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

>Canada

Andy

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 24 Jan 2006 16:56:24 -0800 (PST)

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. 

>     future extensions to the initial document?

Regards,
/david t. perkins

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 25 Jan 2006 13:19:32 +0100

David,
I believe it is rather difficult to guess what a management box will do upon receiving a 
notification.  Some possibilities are: log it, some automatic action to clear an alarm, 
notify a GUI that some long running configuration operation is complete, just be happy 
that a heart beat event is received.
So for me this is really just a notification and it is really up to the receiver what he 
wants to do with it.

Also for me it is important that the notifications are connected to the main part of 
netconf and can operate on the same managed data model, maybe refer to configuration RPC 
calls (e.g. to an edit-config), so the notification framework is much more then simply 
mapping to our protocol.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]