[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-chisholm-netconf-event-00.txt
hi
1. Beep Channels
This certainly came up when we were designing this solution. We found it
confused the discussion quite a bit. The layers really start to blur.
(We developed what I refer to as the 'egg yoke' diagram to try to keep
it straight in our heads, but hopefully I can spare you guys from that
figure ;-)). For the sake of simplicity, we decided to decouple the
event message discussion from the discussion of multiple channels.
There could be a case to take another look at the native concept of the
notification channel in beep, but I think we should be careful to keep
that discussion to just the application mapping bit of the discussion.
2. Additional Event Related Operations
Interesting. I think I had been thinking this would go into the data
model. A get on an event log and filtering on timestamp for example. A
generic resynchronization method might have some uses.
- I think it would be event-class agnostic. For example it would resend
recent events, but not all active alarms.
- It would have to be time based or sequence number based.
- It would have to be careful designed so it would be achievable on the
network element.
I will add this to the requirements list to ensure it is capture.
3. Thresholding
I think you are describing the behaviour of the event, not the event
message.
Sharon
-----Original Message-----
From: James Balestriere (jbalestr) [mailto:jbalestr@cisco.com]
Sent: Wednesday, July 13, 2005 2:53 AM
To: Chisholm, Sharon [CAR:5K50:EXCH]; netconf
Subject: RE: I-D ACTION:draft-chisholm-netconf-event-00.txt
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: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] 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: i-d-announce-bounces@ietf.org
> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, July 12, 2005 3:50 PM
> To: i-d-announce@ietf.org
> 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
> i-d-announce-request@ietf.org 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:
> mailserv@ietf.org.
> 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 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/>