Re: [OPSAWG] WG adoption of SNMP <-> SYSLOG mapping documents,

[Rainer Gerhards <[e-mail]>]

Hi Juergen S. and Q.,

I have not yet commented because I was unsure whether or not the draft
will be adopted. Anyhow, at least one point I would like to add.

On Fri, Jan 30, 2009 at 12:00 AM, Juergen Schoenwaelder
<[e-mail]> wrote:
> On Sun, Jan 25, 2009 at 02:17:40AM +0100, Juergen Quittek wrote:
>
>> Below please find a review of draft-schoenw-syslog-msg-mib-01.
>
> Thanks for your detailed and helpful review.
>
>> 1. Section 4, line 1:
>>    Why do you consider only the conversion of received SYSLOG messages
>>    to entries in the SyslogMsg tables? If you report log messages
>>    concerning the host of the syslog MIB module, couldn't it also make
>>    sense to directly generate table entries for local log messages
>>    without sending messages using the SYSLOG protocol to a local
>>    SYSLOG receiver and converter?
>>    If it does not make sense, it may be worth clarifying why.
>
> My understanding is that the SYSLOG protocol itself does not discuss
> any forms of "local" or "direct" SYSLOG message delivery. On most Unix
> systems, even locally generated SYSLOG content is usually send via
> some local communication path to a SYSLOG daemon. So there is not
> really a distinction between messages originating form the local
> system and messages originating from remote systems. While it might be
> possible to add a sentence that implementations may bypass the
> generation of messages, I am not sure this is needed (you can always
> implement things in whatever way you like as long as it shows the
> right behaviour) and I am also not convinced this is necessarily a
> good idea to do. So for now, I have made no change.

I concur to Juergen S' point of view. In the real-world *nix use case
(the dominant scenario) almost all messages are not generated by the
syslog subsystem itself. Typically, there is a single startup and
shutdown message emitted by the syslog subsystem and maybe a finite
number of error messages concerning the configuration. In contrast,
the syslog subsystem processes an infinite number of messages it
receives from various sources. Note that "local" delivery, in the
real-world-scenario, means that an application (e.g. mail mta) creates
a log record and submits it via a local communications channel to the
syslogd, which then (locally) receives the message.

Of course, there are some other (less dominating) real-world scenarios
where the application emitting a message is actually the original
creator of its content. However, if that application is capable to
send snmp notifications, why should it model a syslog-type snmp
notification and not native format? The only reason I can think about
is that it expects that the snmp receiver actually is interested in
syslog message and thus uses the notification only to tunnel that
message. That use case, IMHO, is not a valid one. In such a case, I'd
prefer to see the originator to emit a native snmp notification and a
converter on the receiving end converting that to syslog format.

So my conclusion is that there is no need to support direct generation
of syslog-type snmp notifications without receiving a syslog message
first.

Rainer
_______________________________________________
OPSAWG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg