Hi all, I have to admit I am not following that closely with SNMP due being busy with -protocol.
As it looks SNMP trap may be useful, I would suggest that this is implemented as a transport mapping for -protocol. -protocol is transport ignorant by design. Some of the structured data elements may be mapped to SNMP properties, as are the header fields. So we already have a number of well-defined values. The ability of mapping syslog message to different transports was a key thing that made us create -protocol, so we could utilize it here. Eventually, it would make sense to create some few additional (option) structure data elements, like the IP address of the original sender. This may be useful for mapping onto SNMP (if element is provided by emitor). Rainer > -----Original Message----- > From: Andrew Ross [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 25, 2004 11:10 PM > To: 'Glenn Mansfield Keeni'; 'Harrington, David' > Cc: [EMAIL PROTECTED] > Subject: RE: SyslogMIB Issue-#4 > > > Hi Glenn, > > That system looks good. Something to map syslog messages into > SNMP traps > and another one for notifications. > > Let's make the timestamp high resolution like the new proposed syslog > RFC that Rainer is working on. > > Leave a string binding in the notification trap for error message > descriptions that we can't plan for. > > Maybe set a binding in the syslogCtlSnmpTrapActionTable that > indicates a > multi part message. Or just constrain the length to 1024 again?? > > Regards > > Andrew > > PS. More comments on your other 6 points will follow when I get my act > together. :-) > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Mansfield > Keeni > Sent: Monday, 26 January 2004 3:05 a.m. > To: Harrington, David > Cc: [EMAIL PROTECTED] > 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) > We can add snmp trap to this with relative ease. It is > just a matter of adding another table > e.g. syslogCtlSnmpTrapActionTable > I would propose that the contents of the trap would be > o the syslog message itself. Perhaps the length will > need to be constrained. > o SyslogSeverity, > o syslogFacility, > o message source > o timestamp. > b. To notify the syslog/System administrator of notable events > e.g. o failure to process a message > relay, log, display etc > o too many rejected messages > o anything else ? > > > Any comments, suggestions ? > > Cheers > > Glenn > > Harrington, David wrote: > > 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 > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > >
