RE: NETCONF Notifications

["Sharon Chisholm" <schishol@nortel.com>]

hi

A number of us are very plugged into the current work being done in syslog.
This does not mean there is not interest in netconf as a potential evolution
of that space. I also don't think we need to even make it our primary use
case for looking at asynchronous messaging. There are a number of cases
where these asynchronous messages are used very much to support
configuration operations, which I know is what the working group chairs are
looking to see.

The things to keep in mind when not wanting to preclude other forms of
asynchronous messages is the idea what we may want to be able to easily
identify the type of message to aid filtering and predictable content and
also that asynchronous messages may be short in some cases and much longer
in others.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Eliot Lear
Sent: Monday, May 30, 2005 4:41 AM
To: j.schoenwaelder@iu-bremen.de
Cc: Andy Bierman; netconf
Subject: Re: NETCONF Notifications


Juergen,

SYSLOG is out there.  Anyone can use it.  However, for reliable and 
secure SYSLOG you have to do something different.  Particularly, for 
reliable.  That's what 3195 was meant to cover.  If you want messages 
signed individually then that's a different kettle of fish, but to 
simply not have the messages go over the clear one can use the existing 
BEEP profile just fine.

Realistically from a BEEP perspective I'm not even sure we need to make 
a change to NETCONF to enable 3195 support.  We simply need to indicate 
that during a <greeting> the profile is available.  But this doesn't 
work for the other protocols (ssh, http).

Eliot

Juergen Schoenwaelder wrote:
> On Sat, May 28, 2005 at 09:34:29AM -0700, Andy Bierman wrote:
>  
> 
>>Let's start a thread to see if we agree on the problem we're trying to
>>solve. First, let's remember where we left off.
> 
> 
> I think it is important to not ignore what is going on in the syslog 
> WG. In particular, <draft-ietf-syslog-protocol-11.txt> seems to be 
> relevant.
> 
> The only strong reason I see for a netconf notification transport 
> would be the reuse of security associations. Perhaps a syslog mapping 
> over ssh would kind of solve the problem.
> 
> Bottom line: I am not really sure yet a notification channel within 
> netconf is essential. Even if it is, we should not be blind and ignore 
> that syslog is out there and that there is active work to build from 
> the original BSD design and which is not bound to BEEP.
> 
> /js
> 

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