Subject: Notification architecture

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2006 06:53:56 -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/>

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Tue, 24 Jan 2006 11:38:30 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, January 24, 2006 11:10 AM
> To: Sharon Chisholm
> Cc: Netconf (E-mail)
> Subject: 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.

HT: As Sharon said above, the proposal is to introduce a) new operation
at rpc layer 
(rpc-one-way) and b) a new message at the operations layer
(notification). Perhaps you
can explain what details you feel are missing. 

  <rpc-one-way>
	<notification>
		<subscriptionId>String</subscriptionId>
		<eventClasses>
			<maintenance/>
		</eventClasses>
		<sequenceNumber>0</sequenceNumber>
		<dateAndTime>2001-12-17T09:30:47.0Z</dateAndTime>
		<eventInfo/>
	</notification>
   </rpc-one-way>

The proposed approach satisfies the unacknowledged notification aspect.
For ack notifications
you could use the rpc, rpc-reply w/o changing the notification
definition. You could of course say that notifications do not follow the
layering scheme that the NETCONF protocol follows and remove the
rpc-one-way. In this case then to indicate whether the notification is
ackd or unackd a new field needs to be added to the notification
operation/message.  

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

HT: Ok, should've read the email b4 typing. I don't see how it is
convoluted & I think
I sent you some references to other work that uses one way rpcs (so this
is not unique to this proposal). 
With that said, the definition could be done either way. But the goal
was to preserve the layering scheme. 

In SNMP you have a separate operation/PDU for notifications but
everything else is the same. The protocol stack doesn't change. Same
thing for other protocols (e.g. CMIP - I know bad comparison), remote
invocation (ROSE) for event notifications is done in the same manner as
for other protocol operations.  

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

HT: Well but that didn't include discussion on notifications. Did it? 
> 
> >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.

HT: You can define a protocol which notifies a remote entity that a
message has been received in the same manner regardless of whether or
not it is an async message. Maybe something else other than an rpc
could've been used for NETCONF to accommodate cmd/rsp and one way
messages. Anyway, you may ignore my previous comment. 

> 
> >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: [email-masked] 
> [mailto:[email-masked]] On 
> >Behalf Of Andy Bierman
> >Sent: Thursday, January 12, 2006 9:59 AM
> >To: Netconf (E-mail)
> >Subject: Notification architecture
> >
> >
> >Hi,
> >
> >
> 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.
> >
> >to unsubscribe send a message to 
> [email-masked] with the 
> >word 'unsubscribe' in a single line as the message text body.
> >to unsubscribe send a message to 
> [email-masked] with the 
> >word 'unsubscribe' in a single line as the message text body.
> to unsubscribe send a message to [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.

---

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Tue, 24 Jan 2006 12:21:08 -0800

I forgot to add... why don't we list the adv/disadv of the 2 or maybe 3
options for notifs layers/structure, discuss it and select one.  

Hector

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 24 Jan 2006 16:45:56 -0500

hi

<Andy>
I have found that there is no better way to improve a design than by
implementing it.  I believe both co-Chairs of this WG would rather start
(any charter item) with a deployed working solution than with an
untested proposal. 
</Andy>

So, you'll be pleased to learn that an earlier version of this is
being/has been implemented. Any feedback we get from implementers or
users we will be sure to feedback into the working group. I've already
made some adjustments based on this sort of feedback.

<Andy>
I don't think we should have a complicated architecture
unless we FULLY UNDERSTAND WHY.
I am never swayed by arguments like "we might
want to do some unknown thing the future".
If the WG agrees on specific future extensions, that's something else.
All engineering tradeoffs need to be cost-justified.
</Andy>

The problem is that we are both arguing that we are proposing the
simpler architecture. That isn't helpful.

Sharon