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

From: "James Balestriere \(jbalestr\)" <[email-masked]>
Date: Wed, 13 Jul 2005 14:52:56 +0800

Hi Sharon ,

One question I had with BEEP was whether we should take advantage of
the multiple BEEP channels and have the events sent on a different
channel to the one doing the configuration.

Other things which might be interesting are whether we wish to hold onto
events for a while, by defining some thresholds values, and then
send one superEvent which contains a list of events. Thresholds could be
things like, time, number of events, bytes accumulated ...

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.
I can envisage a scenario where a hacker deliberately disrupts my
netconf session
and while I am disconnected compromises the router and reconfigures it.
Then when
my Netconf session reattaches I am none the wiser that some funny
business went on.

James.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Wednesday, 13 July 2005 11:57 AM
> To: netconf
> Subject: FW: I-D ACTION:draft-chisholm-netconf-event-00.txt 
> 
> hi
> 
> Here's the actual draft. This is a proposed solution to the need to do
> asynchronous messaging in netconf. Andy suggested it would be good to
> understand what the requirements in this space are.
> 
> Here are some big bullet items
> 
> 1. MUST support different types of events 
> 	1.1 Large and Small messages
> 	1.2 Different types of information
> 2. Client (manager) MUST be able to specify which events are 
> of interest
> 3. Client (manager) MUST be able to stop receiving events
> 4. Client (manger) MUST be able to process events as they come in
> 5. Server (network element) should not be blocked after sending out an
> event
> 6. Events MUST work well for SSH
> 7. Events MUST work for Beep and SOAP
> 
> Sharon
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, July 12, 2005 3:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-chisholm-netconf-event-00.txt 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Netconf Event Messages
> 	Author(s)	: S. Chisholm, K. Curran
> 	Filename	: draft-chisholm-netconf-event-00.txt
> 	Pages		: 26
> 	Date		: 2005-7-12
> 	
>    This memo defines a framework for sending asynchronous messages, or
>    event messages in Netconf.  It defines both the operations 
> necessary
>    to support this concept, and also discusses implications for the
>    mapping to application protocols.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chisholm-netconf-eve
nt-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of
> the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> 	"get draft-chisholm-netconf-event-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-chisholm-netconf-event-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

--
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: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Jul 2005 00:18:08 -0700

Hi -

> From: "James Balestriere (jbalestr)" <[email-masked]>
> To: "Sharon Chisholm" <[email-masked]>; "netconf" <[email-masked]>
> 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