[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> dbharrington@comcast.net
>
>
> > -----Original Message-----
> > From: syslog-sec-bounces@www.employees.org
> > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
> > Rainer Gerhards
> > Sent: Thursday, April 14, 2005 11:25 AM
> > To: syslog-sec@employees.org
> > 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:nwnetworks@dial.pipex.com]
> > > 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" <rgerhards@hq.adiscon.com>
> > > To: "Tom Petch" <nwnetworks@dial.pipex.com>
> > > 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:nwnetworks@dial.pipex.com]
> > > > Sent: Thursday, April 07, 2005 2:56 PM
> > > > To: Rainer Gerhards; syslog-sec@employees.org
> > > > Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog
> > > > Protocol -09-Part II
> > > >
> > > > <below>
> > > > Tom Petch
> > > >
> > > <snip>
> > >
> > >
> > _______________________________________________
> > 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