RE: [logs] Syslog payload format

rgerhardsat_private

Benett, Chris, Andrew, ...

Ok, ok, I give up ;) Looks like I was severely overdoing... OK, if
syslog is sent over TCP, the timestamp will be replaced with an RFC3339
timestamp.

Other than that, is there agreement on only a slight extension to
support TCP? Let me sum up:

It is RFC3164 except:

- TCP is the transport
- messages MUST end with (CR)LF - should it be LF or CRLF?
- the timestamp MUST be RFC3339
- there MAY be multiple messages within a single TCP stream
- client and/or server are free to disconnect the stream when they see
fit

Specifically, this means:

- (single) message size is still limited to 1024 chars
- no push/pull type of event ordering as suggested by some others
- not compliant with what PIX does!!! (should we allow an alternate
termination to take care of this -- I would suggest so as the PIX is
definetely important and chances are great we'll write code to support
it anyhow...)
- non of the fancy ideas of some other syslog-over-tcp floks like Andrew
Ross in there...

It would call for a very simple extension to RFC3164, wouldn't server
all needs but would be trivial enough to - at least I think - get
quickly momentum.

Questions now:

- should it be that way? What needs to be changed?
- Who will support it? (this is the big one ;-))

Rainer

> -----Original Message-----
> From: Bennett Todd [mailto:betat_private] 
> Sent: Monday, January 06, 2003 3:06 PM
> To: Rainer Gerhards
> Cc: Mikael Olsson; loganalysisat_private; Darren Reed
> Subject: Re: [logs] Syslog payload format
> 
> 
> 2003-01-04T08:06:32 Rainer Gerhards:
> > [ re syslog (RFC 3164) -vs- ISO 8601 / RFC 3339 timestamps 
> ] But it is 
> > a key question. If some of us go for a total syslog replacement and 
> > new protocol, and others would prefer to stay with the current RFCs 
> > (and extremely slight modifications), then we are in fact splitting 
> > the goup and implementation becomes less likely.
> 
> It would be nice if we could agree on one thing. I'm having 
> trouble seeing the motivation for retaining the [deficient, 
> partial] timestamp of classic syslog in the name of 
> "interop", when we're defining a protocol which is profoundly 
> not interoperable with it (TCP -vs- UDP). Rather than wasting 
> space on a useless timestamp then putting the useful one in 
> the "payload", let's just put a useful timestamp on the front 
> of the messages.
> 
> > Remember: if you change the timestamp, you also give up compatibity 
> > with RFC3195, which I assume will become more important over time.
> 
> I don't see that at all; folks who want multiplexed 
> MIME-encoded channels will go that route; and the result once 
> again won't be interoperable with either traditional syslog, 
> or with a simple syslog-over-TCP.
> 
> And for heterogenous systems, it's easy to recode complete 
> timestamps to make partial ones; the reverse operation, 
> reconstructing full timestamps with timezone info, requires 
> heuristics and external knowlege.
> 
> -Bennett
> 
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis