On Fri, Jan 12, 2007 at 11:19:50AM +0100, Rainer Gerhards wrote:
> Glenn,
>
> thanks for the description in "plain words". At least for me, this is
> very useful.
>
> If you think about things that are common to a sufficiently large number
> of syslog applications, you can not standardize on many more properties.
> What syslog applications do with the messages is very different, as are
> the filtering capabilities.
>
> One thing I could think of is a MIB/special table (whatever in SNMP
> terms) *just* for *simple syslog *senders**. It is common for devices
> like routers, switches and firewalls to provide a limited syslog
> reporting capability. What needs to be configured here is
[...]
> Some devices support multiple TARGETs, some only a single one.
The question really is who is interested to configure syslog
originators typically found on network elements via SNMP. If there are
people interested in this, they better speak up now and tell us what
information they need to get the syslogs on their products configured.
If nobody speaks up with concrete input and implementation plans, we
should perhaps drop syslog configuration via SNMP and just focus on
monitoring (and leave syslog configuration to future MIB work or leave
this to NETCONF once they have figured out to write data models).
I personally would vote for a very basic syslog monitoring MIB which
allows me to track syslog activities and to identify discrepancies
between originated syslog messages and actually received syslog
messages. Ideally, an implementation of such a MIB would hook into an
SNMP master agent via AgentX (of a similar mechanism) so I can
transparently access the MIB by talking to the main SNMP agent on the
device.
/js
--
Juergen Schoenwaelder {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
