Notification architecture

[Andy Bierman <andy@andybierman.com>]

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