[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification architecture

Sharon Chisholm wrote:


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.



I don't like it at all.
The document is not very clear at all.
There are many details that are buried in
hard-to-read XSD and not explained in
any human-readable text.


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.

.
IMO, it is way simpler to explain the notification path
as separate from the operations path.  They are separate
in CLI and SNMP.  I just don't see a notification as a one way
remote procedure call.  It is convoluted.

BTW, we decided awhile back that we didn't want 'void' RPCs.
That is why we have the <ok> element.


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.


Really? What are they?
This looks like a broken architecture to me.
Requests which return responses and/or status
are not handled the same as async. notifications -- which is what
we are chartered to add to netconf.


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



It was based on <rpc> layering.
It wasn't clear from the document that <notification>
is under <one-way-rpc>.  (Why the extra layer --
oh yeah -- we may add other types of 1-way rpcs
in the future :-)



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?


Like what?
We can deal with that problem if it ever comes up.
Extending XML is pretty easy.


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.


Nobody else seems to want to do this.
(Have the manager listen for <rpc>?)

Why do you want to make this so complicated?
A notification, over RPC, with an operations layer?
What is it used for?  I don't get it.

We should be solving current operational problems.
We have both the syslog and SNMP notification models
in use today.  We should build on that, not reinvent it.




Sharon


Andy


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





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