Re: [Syslog-sec] syslog-protocol

[Devin Kowatch <devink@sdsc.edu>]

On Mon, Jul 12, 2004 at 06:18:49PM +0200, Rainer Gerhards wrote:
> Hi list,
> 
> I am more or less finished with my next edit (which hopefully brings us
> very close to a final version). However there is one thing that I would
> one again like to bring to the attention of the list - simply because it
> is much that needs to be changed:
> 
> Anton suggested:
> > I know you wanted to keep some resemblance of the old ad-hoc syslog
> > format, but two separate fields for TAG would make life much easier
> > then having to find the last [ and only if there is ] at the end.  If
> > we make two fields, they would be APP-NAME (or PROCESS-NAME) and
> > PROCESS-ID.  This is much more intuitive then describing it as static
> > vs. dynamic. And this is what people are after in the end. We could
> > allow for say "-" for unknown process ID. But I think requiring
> > APP-NAME is a must. What do you think?
> 
> I responded:
> >That sounds good - I actually did not have this good idea. If there is
> >no objection, I'll change it to this in the next draft.
> 
> I am still of the opinion that this is a good idea - especially as it
> also solves some parsing nightmare with the colon characters. It just
> finally breaks the legacy TAG ... but that would be easily to re-create
> in change a process needs to relay to a RFC 3164 collector.

With out actually verifing anything.  My experiences on Linux and
Solaris suggest that it may not matter one way or the other.  Both
syslogd's only parse the message enough to add a time stamp or insert
the host name after the time stamp.

IIRC, RFC 3164 only allows something like alphanumerics in the TAG
field and everything else is considered the message/content anyway.  I
believe this is the reason that SDSC Syslog will consider [<pid>] as
part of the content.

The only area in which it may cause problems is that many existing
syslogd's will write out the message more or less as recieved, which
may cause syslog log file parsers to break.  But anyone who writes that
sort of thing should be fairly used to it breaking :)

> 
> So I, too, would opt for 2 "TAG" fields separated by SP. I'm not sure if
> the above names would be the most appropriate, maybe TAG-NAME and
> TAG-PID would be better to tie them back to the 3164 TAG.
> 
> I'd appreciate feedback on this issue. I definitely plan to submit the
> next draft before the cutoff date at the end of this week.
> 
> Rainer
> 	
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec

-- 
Devin Kowatch
devink@sdsc.edu
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec