[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Real Notification Requirements



Hello,

I am a lurker on this list. My name is Rainer Gerhards and I am the
editor of the syslog-protocol draft. I think it might be useful if I
provide some of my views of how syslog could relate to the notification
work.

STRUCTURED-DATA in syslog is a flat system. There is only one level of
depth. The syslog WG considers this to be sufficient for syslog uses
because most information that syslog conveys is non-hierarchical. Also
syslog-sec was concerend about the maximum message size (we need to be
able to provide meaningful messages in as few as 480 octets). However,
STRUCTURED-DATA is designed as the primary extension mechanism for
syslog. It is my belief that XML-data fits nicely into the
STRUCTURED-DATA part, if there is need to.

Another major difference is that syslog is still a simplex protocol.
Also, the transport tends to be more simplistic in general, because this
is what we see the market place dictates. So we currently do not try to
standardize a secure transport on top of SSH but rather on top of TLS
(which is often deployed in practice). 

A subscribtion model would require considerable change to syslog. There
would be no consensus to integrate this into the current set of drafts.

A major problem with the syslog-sec wg has been lack of interest and
sufficient review. If there would be more voices, things would probably
have evolved into a different direction. On the other hand, RFC 3195
(BEEP-based syslog) has not gotten any momentum and received few
implementations. That implies that rapid change is not easily accepted
in syslog.

I do not have a strong opinion of NETCONF notifications should be merged
with syslog. I've seen some of the problems that we faced come up here
(e.g. message length), but I am not sure if the potential user base is
similar enough to justify a merge. I like that NETCONF notifications are
able to do more changes than we can do in syslog.

Many syslog receivers consume SNMP traps today. If NETCONF notifications
get standardized, I would expect that many syslog receivers would
consume them, too. 

My 2cts ... maybe the are useful for somebody ;)

Rainer Gerhards

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, March 28, 2006 5:18 PM
> To: Shane Kerr
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: Real Notification Requirements
> 
> On Tue, Mar 28, 2006 at 05:02:25PM +0200, Shane Kerr wrote:
>  
> > Perhaps it would be better to focus on adding a 
> subscription mechanism
> > to SYSLOG?
> 
> Certainly an option. Having a subcription mechanism is actually for me
> an important feature. Some 12 years ago, we hacked our central syslog
> daemon to actually ship syslog messages once you connected to it and
> it was a lovely hack which we used a lot (since it makes access to
> syslog message real simply for programs).
> 
> On the classification question: I think you can put anything into
> syslog, so the distinction between syslog messages, configuration
> change notifications, or SNMP notifications is kind of artificial.
> 
> In fact, it seems popular in many operational environments to have
> SNMP notification receivers which simply write to syslog, probably
> because there are also pretty nice syslog readers that can trigger all
> sorts of actions when they discover certain input patterns.
> 
> If we do an interim, it would be valuable to get some syslog experts
> there as well so that we can evaluate whether structured syslog and
> syslog enhancements will actually solve the problem.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> --
> 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/>