Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Apr 2005 18:28:27 +0200

Hi David & all,

what I currently see in TAG (RFC 3164, the "source" for APP-NAME, PROCID
and MSGID) is

- image name
- OS process ID
- operator-assigned ID
- vendor-assigned application name
- vendor-assigned app name tree
- transactions IDs (smtp, database, ...)
- message IDs
- reboot IDs
- severity values (only combined with one of the above)
- any combination of the above

... and this is just what immediately comes to my mind.

If we really want to provide strong syntax and semantics, we must define
different fields for all of them - musn't we? Even then, we have the
issue that a Postfix SMTP transaction ID might be totally different from
an Exchange SMTP transaction ID. What I am trying to convey is that I
think it is beyond the scope of syslog to well-define identifiers for
each potential vendor usage.

Observed, existing syslog actually solves this issue by using a single
field - TAG - that will include whatever the vendor/operator decides. It
still is useful, because it allows filtering on it. But it is far from
being well-defined.

I may be totally wrong here, but I have to admit that I have *absolutely
no idea* how we could get these things into a few header fields AND then
well-define them. If somebody knows how to do that, I would deeply
appreciate any text suggestion.

Rainer

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 6:12 PM
> To: Rainer Gerhards; 'Anton Okmianski'; 'syslog'
> Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> 
>  
> 
> > Anyhow, I see a valid point in Dado's suggestion: all of 
> > these 3 fields
> > are highly optional and all of them have no strict definition. Maybe
> > this is not a good thing for well-defined header fields. 
> 
> Maybe this is not a good thing for an industry "standard" - Maybe we
> should make them not-optional and/or strictly define them. 
> 
> From RFC2026:
> "A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has
> received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable."
> 
> I question whether these field definitions have resolved the known
> design choices, are well-understood, and enjoy enough community
> interest to be considered valuable.
> 
> I think coming to an agreement on the format and semantics, and
> specifying it clearly and umambiguously in the documentation, would
> enhance the value of these fields. Let's standardize the semantics of
> the field, rather than just standardizing a bucket for undefined
> information.
> 
> David Harrington
> [email-masked]
> 
> 
> 
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Apr 2005 14:01:55 -0400

Hi Rainer,

The problem is that you're trying to make the "standard" accommodate
all possible variations of current usage. 

Standards are not about defining something so generically and
ambiguously that every vendor can claim compliance to the standard.
Standards should be about forcing agreement on a format that
subsequent standard-compliant implementations would use so the
information was actually useful; any vendor that chose to not follow
the standard simply doesn't get to market their product as being
standard-complaint. 

To put this in a slightly different way, we should be focusing on what
is most beneficial to the consumers of the information, not what is
easiest for the vendors.

If we don't narrow the design choices to support, say, the 90% of the
90/10 rule, then we end up with something that is so ambiguous as be
largely useless.

It is the vendors' responsibility to "port" their information to the
standard format, not the standards committee's responsibility to
"port" the standard to each vendor-specific format. We should
certainly try to choose a standard format that will be easy for most
vendors to "port" to, but we should not be trying to define something
so generic it requires no porting (and ends up being pretty useless).

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Rainer Gerhards
> Sent: Thursday, April 21, 2005 12:28 PM
> To: syslog