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