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 PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 PROTECTED] > > 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 PROTECTED] > > > > > > > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec
