RE: [logs] Syslog payload format

From: Rainer Gerhards (rgerhardsat_private)
Date: Tue Jan 07 2003 - 01:20:59 PST

  • Next message: Rainer Gerhards: "RE: [logs] EventLog library"

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

    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 08:09:08 PST