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

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

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:ietfdbh@comcast.net] 
> 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
> dbharrington@comcast.net
> 
> 
> 
> 
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec