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

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Apr 2005 20:48:35 +0200

David,

I fully agree to your comments on standardization and what a standard
should be. The *real problem* is that I do not see any of these things
to be used in majority. They are all equally often (of seldom) used. I
don't see any one of the current uses that is worth requiring it. I
don't see any generally useful information (maybe the MSGID). This is
why I like the idea of removing them.

Anyhow, I am open to all suggestions on *what exactly* should be
standardized. Based on this and past discussions and my experience with
syslog (both on the sender and receiver/analysis side),I have to admit I
have no clue at all which fields we should specify. For each, you can
argue that it is either not specific enough or not worth standardizing
(because it is to specialised).

So I leave it to the WG to suggest some fields and semantics. I am
simply out of ideas. Text suggestions are highly welcome.

Rainer

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 8:02 PM
> To: Rainer Gerhards; 'syslog'
> Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> 
> 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]
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of 
> > Rainer Gerhards
> > Sent: Thursday, April 21, 2005 12:28 PM
> > To: syslog
> > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> > 
> > 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
> > 
> 
> 
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Anton Okmianski" <[email-masked]>
Date: Thu, 21 Apr 2005 15:48:12 -0400

> I fully agree to your comments on standardization and what a 
> standard should be. The *real problem* is that I do not see 
> any of these things to be used in majority. They are all 
> equally often (of seldom) used. I don't see any one of the 
> current uses that is worth requiring it. I don't see any 
> generally useful information (maybe the MSGID). This is why I 
> like the idea of removing them.

I beg to differ. I see process name, process id or both (in syntax
name[id]) used in syslog messages all the time.  And for good reason.
This maps cleanly to APP-NAME and PROCID. 

I only suggested that in cases when you have an app suite, it may make
sense to allow APP-NAME to refer to app suite and PROCID to process
name. 

Message IDs are used by (at a minimum) Solaris syslog and Cisco
devices, although they use them differently. 

I agree with David, we don't need just a bucket transport mechanism.
There is XML, ASN.1, etc for this already.  We need standard defined
semantics for information we are allowing to be communicated.  

Anton. 

> 
> 
> Anyhow, I am open to all suggestions on *what exactly* should 
> be standardized. Based on this and past discussions and my 
> experience with syslog (both on the sender and 
> receiver/analysis side),I have to admit I have no clue at all 
> which fields we should specify. For each, you can argue that 
> it is either not specific enough or not worth standardizing 
> So I leave it to the WG to suggest some fields and semantics. 
> I am simply out of ideas. Text suggestions are highly welcome.
> 
> Rainer
> 
Rainer 
> > > Gerhards
APP-NAME, 
> > > PROCID and MSGID) is
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
> > > decides. It still is useful, because it allows filtering 
> on it. But 
> > > it is far
> > from
> > > being well-defined.
> > > 
> > > *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
> > > 
> > > > > 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