Re: SyslogMIB Issue-#4

[Glenn Mansfield Keeni <glenn@cysols.com>]

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: owner-syslog-sec@employees.org
> [mailto:owner-syslog-sec@employees.org] On Behalf Of Glenn Mansfield
> Keeni
> Sent: Monday, 26 January 2004 3:05 a.m.
> To: Harrington, David
> Cc: syslog-sec@employees.org
> 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:glenn@cysols.com]
>>>Sent: Friday, January 16, 2004 4:48 AM
>>>To: syslog-sec@employees.org
>>>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>