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

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

Anton,

So this boils down that you are happy with the current draft and just
would like to have PROCID larger (let's say 64 or 128 octets)?

Rainer 

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 9:48 PM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> 
> > 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 
> > (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
> > 
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Anton Okmianski" <[email-masked]>
Date: Thu, 21 Apr 2005 16:10:56 -0400

> Anton,
> 
> So this boils down that you are happy with the current draft 
> and just would like to have PROCID larger (let's say 64 or 
> 128 octets)?

Yes. And hopefully its content defined with SHOULDs.  I think it
should say that this SHOULD be a process name or process ID.  

I also don't understand this statement: "the syslogd is restarted, the
PROCID changes".  Do you mean when the processing sending requests
restarst, it MAY change the PROCID value (if it is a process id and
not name)? 

Thanks,
Anton. 

> > > 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).
> > >