[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Notification architecture
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
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] 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.
>
> >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/>
>
--
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/>