Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol-09-PartII

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 14 Apr 2005 18:51:58 +0200

David,

I quickly got a real-world example. Maybe this illustrates:

Apr 13 11:18:27 grfdeb squid[22687]: Finished rebuilding storage from
disk.
Apr 13 11:18:27 grfdeb squid[22687]:     11003 Entries scanned
Apr 13 11:18:27 grfdeb squid[22687]:         0 Invalid entries.
Apr 13 11:18:27 grfdeb squid[22687]:         0 With invalid flags.
Apr 13 11:18:27 grfdeb squid[22687]:     11003 Objects loaded.
Apr 13 11:18:27 grfdeb squid[22687]:         0 Objects expired.
Apr 13 11:18:27 grfdeb squid[22687]:         0 Objects cancelled.
Apr 13 11:18:27 grfdeb squid[22687]:         0 Duplicate URLs purged.
Apr 13 11:18:27 grfdeb squid[22687]:         0 Swapfile clashes avoided.
Apr 13 11:18:27 grfdeb squid[22687]:   Took 0.4 seconds (30507.4
objects/sec).
Apr 13 11:18:27 grfdeb squid[22687]: Beginning Validation Procedure

The 22687 in parenthesis is the process id and would be APP-INST. There
are many other applications using a similar scheme.

Rainer 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Rainer Gerhards
> Sent: Thursday, April 14, 2005 6:48 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog 
> Protocol-09-PartII
> 
> David, 
> 
> > Hi,
> > 
> > So which wording did you adopt here? Did you use 'instance of the
> > sender's syslog process'?
> 
> yes
> 
> > I'm not sure that's easier to understand, nor that it better
> > represents a SENDER-INST, and I'm not quite sure what 
> exactly you want
> > in this field, nor why, based on the discussion in Appendix A. Some
> > guidance on WHICH process id would be helpful, if process 
> id is to be
> > used.
> 
> Actually, I have to admit I am out of terms in regard to this 
> field. In
> my point of view, an instance is the physical representation of an
> executable. The executable is what you have on disk or other permanent
> storage). Once the loader loads this executable, it becomes a specific
> instance. It might be loaded more than once, in which case each of the
> running processes is an instance. That's the case for a 
> general purpose
> OS. On a special-purpose box, e.g. an router, the vendor might decide
> that the box as whole is the syslog sender. Thus, the instance in this
> case might actually be a reboot ID - or whatever the vendor 
> assigns. The
> basic idea is that you should be able to somewhat identify which
> physical representation of the code was producing the message. But I
> guess this isn't any clearer..
> 
> The process ID of the syslog sender process should be used. E.g. if
> postfix is running on a UNIX machine and its PID is 4711, 
> 4711 should be
> in this field.
> 
> > 
> > It strikes me that this attribute is not well thought-out. I haven't
> > been much involved with syslog. Is this attribute supported by
> > existing running code? 
> 
> It is in wide use in existing code inside the TAG. TAG currently is -
> depending on the application - a combination of SENDER-INST, 
> SENDER-NAME
> and MSGID. At least some analysis scripts rely on it.
> 
> > Is this something the whole WG agrees should be
> > standardized?
> > 
> > If the WG wants this standardized, then the text describing it (and
> > its use case) should be tightened up a lot. I suggest a format be
> > standardized if possible, based on common operating systems, with
> > recommendatioins about how to deal with non-common formats. Some
> > examples might be helpful as well.
> > 
> > If this cannot be tightened up, I recommend it be left out of the
> > standard.
> 
> Given the problems in describing it, this might eventually be the best
> solution. Applications needing this field can still include it in
> APP-NAME, as it currently is done with the TAG.
> 
> Mmmhhh... Maybe we should simply call it a "cookie" (APP-COOKIE) and
> allow the sender to place inside it whatever it wants to - 
> this probably
> best reflects current behaviour.
> 
> Any comments from the WG are deeply appreciated.
> 
> Rainer
> > 
> > My $.02
> > David Harrington
> > [email-masked]
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of 
> > > Rainer Gerhards
> > > Sent: Thursday, April 14, 2005 11:25 AM
> > > To: [email-masked]
> > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog 
> > > Protocol -09-PartII
> > > 
> > > Tom,
> > > 
> > > thanks for this suggestion, too. I've used the first wording you
> > > provided. I still think that the definition of sender does not
> > change
> > > from section 3, as 3 says "An application that can 
> generate a syslog
> > > message is called a sender". Anyhow, it obviously causes confusion
> > and
> > > so it is better to try to sort this out.
> > > 
> > > As a side note, I will submit the updated ID tomorrow or 
> > > monday if I do
> > > not hear any other comments.
> > > 
> > > Thanks again for all the help,
> > > Rainer
> > > 
> > > > -----Original Message-----
> > > > From: Tom Petch [mailto:[email-masked]] 
> > > > Sent: Saturday, April 09, 2005 9:38 PM
> > > > To: Rainer Gerhards
> > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog 
> > > > Protocol -09-Part II
> > > > 
> > > > I do not think that it is 'instance' per se that confused me, 
> > > > it is 'instance of
> > > > the sender'.  'Sender' has been given a technical meaning in 
> > > > section 3 and the
> > > > usage here is different, meaning only a part of sender as 
> > > used before.
> > > > So make it more specific, such as 'instance of the sender's 
> > > > syslog process' (you
> > > > do refer to process id just after)
> > > > 
> > > > Alternatively use a more process-oriented word such 'execution'.
> > > > 
> > > > Tom Petch
> > > > ----- Original Message -----
> > > > From: "Rainer Gerhards" <[email-masked]>
> > > > To: "Tom Petch" <[email-masked]>
> > > > Sent: Thursday, April 07, 2005 4:45 PM
> > > > Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog 
> > > > Protocol -09-Part
> > > > II
> > > > <snip>
> > > > I also have seen that "instance" is probably a bad word, 
> > > but I lack a
> > > > better one. "Instance" is well defined in the software 
> > > > development space
> > > > (at least I think), but this understanding of instance is 
> > > > obviously not
> > > > universal. A suggestion for a better word would be much
> > appreciated.
> > > > Others might call an instance a reboot, run, job, 
> process, process
> > > > space, incarnation, physical representation, just to give 
> > > > some examples
> > > > (which I think make up for equally-bad words in this context
> > here).
> > > > 
> > > > Rainer
> > > > 
> > > > > -----Original Message-----
> > > > > From: Tom Petch [mailto:[email-masked]]
> > > > > Sent: Thursday, April 07, 2005 2:56 PM
> > > > > To: Rainer Gerhards; [email-masked]
> > > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog
> > > > > Protocol -09-Part II
> > > > >
> > > > > <below>
> > > > > Tom Petch
> > > > >
> > > > <snip>
> > > > 
> > > > 
> > > _______________________________________________
> > > 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