Subject: Notification architecture

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2006 06:59:25 -0800

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>