Hi Glenn, The benefit of having an SNMP trap is that there becomes some coordination between the syslog messaging and SNMP trap manager applications.
Operators often use trap management tools to alert them to problems, and these applications often have the ability to filter out uninteresting traps, to sort by priority, to do fault isolation, and so on. Trap management utilities can also feed into SNMP-based topology mapping tools (like HPOV) which can use colored icons to represent serious problems, and so on. The problem with a syslog notification is - what would it contain? You could write one syslog notification for reporting all syslog events by simply having a varbind with the complete syslog message. That means that an SNMP trap application cannot do much in terms of sorting by priority. You could create a notification that ocntains some standardized values common to syslog messages, such as severity, related subsystem, vendor, and then include the human-readable string in an octet string. This might be useful, but it might be less useful than notifications specific to a technology. I think the WG needs to discuss the nature of potential notification designs. Personally I think such a generalized trap might be a good thing for improving coordination between syslog and SNMP, but it will depend a great deal on the actual design and how easily that design can be utilized by applications. dbh > -----Original Message----- > From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED] > Sent: Friday, January 16, 2004 4:48 AM > To: [EMAIL PROTECTED] > Subject: SyslogMIB Issue-#4 > > > Issue #4. Snmp Notifications ? Do we need any ? > > > Action: Do we need any? > Note- Syslog itself is a notification. > If there a clear requirement for a notification > that can added. > > Status: Waiting on community input > > > > > > > > > > >
