Subject: [Syslog] semantics of the origin SD-ID

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2008 09:41:45 +0200

Hi,

I have a question concerning the semantics of the origin SD-ID defined
in section 7.2 of <draft-ietf-syslog-protocol-23.txt>. The text talks
about the "originator" of a message. The definition of "originator" is
provided in section 3:

   o  An "originator" generates syslog content to be carried in a
      message.

I am facing a situation which looks as follows:

    box A                       box B
  +-------+    non-syslog     +-------+   syslog
  |       | ----------------> |   T   | -----------> ...
  +-------+   notification    +-------+   message

I have an event notification originating from box A that is received
by box B via a non-syslog protocol.  Box B runs a translator T turning
the non-syslog event notification into a syslog message. If I take the
text in the syslog specs literally, then the origin SD-ID likely
identifies the (syslog) originator, that is box B. However, the text
in 7.2 also says:

   Specifying any of these parameters is primarily an aid to log
   analyzers and similar applications.

Since the true origin of the event carried in the syslog message is
box A, a log analyzer might be better served by being able to identify
box A as the origin of the content carried in the syslog message, even
though the first hop in the forwarding chain was not really a syslog
message.

What do the syslog experts think - should the origin SD-ID identify
box A or box B in the example above?

/js

PS: The background behind this question is work proposed to the OPSAWG
    on mapping SNMP notifications to SYSLOG messages and I like to
    clarify in the mapping what the semantic of the origin SD-ID is in
    this context (<draft-marinov-syslog-snmp-02.txt>).

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 2 Oct 2008 09:53:45 +0200

Hi Jürgen,

the upcoming syslog rfc series is still missing two documents, I think: one on relay behavior and one on gateway behavior. So let me express my personal view as I can not cite anything that underwent discussion.

In the gateway case you describe, I would think that the origin SD-ID should contain identification of the original originator, provided that this identification is known with sufficient trust (which it is in case of SNMP, I think).

Also thanks for making me aware of draft-marinov-syslog-snmp-02.txt, this looks like useful work.

Rainer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, October 02, 2008 9:42 AM
> To: [email-masked]
> Subject: [Syslog] semantics of the origin SD-ID
> 
> Hi,
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Oct 2008 11:48:07 +0200

> this looks like useful work.

Please let the OPSAWG an their chairs know since they need to
determine concensus whether this document is taken on as an OPSAWG
work item.

/js

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 2 Oct 2008 12:03:35 +0200

Hi OPSAWG,

I am a syslog implementor and would like to endorse the work planned to
support mapping of SNMP to syslog. There are already implementations
available, those that I know out of my head are Kiwi Syslog, WinSyslog,
MonitorWare Agent and rsyslog (default or to-become default on many
linux distributions). I am sure there are also plenty of others. I think
Cisco has created a private syslog MIB, at least I think I remember we
used it some time ago.

I am the author of rsyslog. While I have not written the SNMP plugins, I
know from discussions that having no standard MIB for syslog messages
causes each vendor to define its own or (mis)use some private extension
of other vendors (as we initially did). Similar issues exist on the
receiving side.

While probably not mainstream, there are a number of installations who
do syslog-to-snmp (and vice versa) processing. So there is operator
demand for this kind of mapping.

Best regards,
Rainer Gerhards

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, October 02, 2008 11:48 AM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: Re: [Syslog] semantics of the origin SD-ID
>