[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notification architecture
- To: "Netconf (E-mail)" <netconf@ops.ietf.org>
- Subject: Notification architecture
- From: Andy Bierman <ietf@andybierman.com>
- Date: Thu, 12 Jan 2006 06:59:25 -0800
- User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
Hi,
IMO, the architectural layering defined in the Notifications
draft is broken. Currently, a notification is modeled as an
operation -- as a child of the <rpc> node in the PDU encoding.
The whole notion of a one-way remote procedure call instead
of an event notification seems convoluted to me. A notification
is not a 'void' procedure call (i.e., just a function with no
return value). It has temporal characteristics. That's why
it has a timestamp and an RPC doesn't.
<notification> needs to be a top-level element.
This proposed layering creates several problems:
- Access control configuration is more complicated. It is
desirable to give separate access to users for notifications
and real RPCs like <edit-config>. Nesting these elements
forces more complex access control rules to be configured
to accomplish this feature.
- Notifications cannot be channelized in the BEEP transport
unless <notification> is independent of <rpc>. Obviously
we want to take advantage of this feature in BEEP for asynch
notifications. That's been our design goal from day 1.
- Statistics for RPCs will be confusing
It is desirable for the stats for RPCs to be separate from
the stats for notifications, e.g.
ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType];
(for all ncErrorType)
- Dual-role entities will be receiving <rpc> as a real RPC
and as a notification. This complicates the code path.
Current implementations can set up internal structures
and glean info from the 'rpc' node that is required
for all real RPCs. As proposed, an implementation would
have to either look ahead or undo and restart, because
the internal code path for notification processing
is totally different than for a real RPC (no error response
handling for starters).
Draft Proposed Layering:
Layer Example
+-------------+ +-----------------------------+
| Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Operations | | <get-config>, <notification>|
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| RPC | | <rpc>, <rpc-reply> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+
My Proposed Layering
Layer Example
+-------------+ +-----------------------------+
| Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ |
| Operations | |
+-------------+ \
| \
+-------------+ +--------------+
| RPC | | Notification |
+-------------+ +--------------+
| /
+-------------+ +-----------------------------+
| Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+
There is no operation layer in a notification.
There is only transport, notification header, and content.
Andy
--
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/>