Hi Rainer,
This pretty much matches with the image I have in mind.
Till there is no "original sender" in the syslog message
itself I guess that we will have to do with the "last sender".
Glenn
Rainer Gerhards wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
