Hi Andrew, Getting the high resolution timestamp should not be a problem. And I think that we can agree to constrain the length of the message that will be carried in the trap.
Glenn > 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > > > > >
