Re: I-D ACTION:draft-chisholm-netconf-event-00.txt

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "James Balestriere (jbalestr)" <jbalestr@cisco.com>
> To: "Sharon Chisholm" <schishol@nortel.com>; "netconf" <netconf@ops.ietf.org>
> Sent: Tuesday, July 12, 2005 11:52 PM
> Subject: RE: I-D ACTION:draft-chisholm-netconf-event-00.txt
...
> In the unfortunate situation where the Netconf session suffers from an outage
> and events cannot be delivered, do we need a queuing mechanism so when the
> remote side reattaches these events can be delivered ? Not all notifications
> are of equal importance but some, like configuration change events, are critical.
...

The CMIP world developed some rather cool stuff to handle situations like these.
The "disseminator" can be thought of as the result of crossing a log with an
event forwarding discriminator, holding onto event records until they've been
successfully delivered.  Unfortunately, since it was developed after logs and
EFDs, the inheritance and attributes weren't as aesthetically pleasing as they'd
be if it had been in the architecture from the start.

So, my $0.02 is that thinking up front about events, event queues, logs,
notification subscription and delivery is well worthwhile.

Randy




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