[prev in list] [next in list] [prev in thread] [next in thread] 

List:       syslog-sec
Subject:    RE: SyslogMIB Issue-#4  // Issue-#2
From:       Rainer Gerhards <rgerhards () hq ! adiscon ! com>
Date:       2004-01-30 17:56:52
Message-ID: 200401301835.i0UIZ6jo021289 () willers ! employees ! org
[Download RAW message or body]

Let me make a comment here that applies to issue #2 (BSD Centric)

> -----Original Message-----
> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com]
> Sent: Sunday, January 25, 2004 3:05 PM
> To: Harrington, David
> Cc: syslog-sec@employees.org
> Subject: Re: SyslogMIB Issue-#4
>
> Hi Dave,
>     Thanks for the comments. I agree with you. Traps are useful.
> They provide a uniform mechanism/console for the network manager
> to manage the network, related devices and processes.
>     There are two levels at which we may want SNMP traps in the
> Syslog Messaging context.
>     a. To provide another option of how a message will be
>        processed. Presently we have
>           - log (syslogCtlLogActionTable)
>           - display on users console (syslogCtlUserActionTable)
>           - relay/forward (syslogCtlFwdActionTable)
>           - pipe (syslogCtlPipeActionTable)

In our products, we have many more options. I know for sure that Kiwi
syslogd also has many more options. I think many other vendors do have
other options, too. Upcoming versions of our *nix based syslogd will
definitely have more options. -sign may eventually require new actions
(verify signature? log diagnostic warning?) [this is speculated, just
for the records;)].

What I am trying to convey is that this is a very limited set and
different syslogd's may have totally different implementations. We can
stick with the minimal set of generic things. I am not deep enough in
SNMP to know if we (vendor) can define a mib to take care of the others
(I am sure we can ;)). But the question is how this would relate to the
"standard actions".

As a side note, the filterig/rule processing system is also totally
different in different implementations, this complicates things pretty
much. So it is probably best to stick with the minimal possibilities
from stock syslogd.

Rainer



[prev in list] [next in list] [prev in thread] [next in thread]