RE: Notification architecture

["Sharon Chisholm" <schishol@nortel.com>]

hi

Couple points:

1. Notifications are not layered on the <rpc>, but rather a new wrapper
of <one-way-rpc> which is at the same Netconf layer as <rpc> but is
different. Therefore there should be no issues surrounding statistics
and I don't think the beep mapping is hindered by this wrapper.

2. I've had good success in using the existing Netconf layer model to
help people understand the different bits of Netconf. Your proposed
update solves one problem I had around the fact that drawn the wrong
way, it would imply that <notifications> ran over <rpc> or something
along those lines, but it now breaks the fact that there are layers.
This concept gets somewhat lost.

3. There are advantages to systems who want to process both synchronous
and asynchronous messages to be able to use the same method
	- process rpc
	- process message
By having two different architectures for these messages, things diverge
much more.

4. I don't understand the access control comment.

5. Layer compression for notifications limits future extensibility
options. What happens if some mythical day in the future we want to add
another type of asynchronous message, or want to do acknowledged events?
How does that work? Right now, I could conceive of running
<notification> over <rpc> <rpc-reply> as one method to do acknowledged
events, which becomes more difficult with what you are proposing. I
don't want to optimize the architecture for things that are out of scope
of this release and things which we may never ever get to, but I think
in general we should give some consideration to the implications on
extensibility that this compression might have.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, January 12, 2006 9:59 AM
To: Netconf (E-mail)
Subject: Notification architecture


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


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