RE: [logs] Syslog payload format

rgerhardsat_private

Andrew,

> >The "Internet standard" is CRLF.  Most protocols do use 
> CRLF, but, then 
> >again, most daemons also happily accept LF.  Make it an 
> either/or for 
> >senders, where receivers MUST accept both?
> 
> Could we make the preferred terminator CRLF and have LF as optional?

The "Internet standard" thing made my opinion. So I'd go for CRLF, too.
We should say MUST be CRLF, but LF should also be accepted.

> 
> 
> >What about messages "terminated" by end-of-stream?
> >Assume that they're broken and shouldn't be stored, or 
> assume that EOS 
> >is a valid terminator?  (I just think that a "SHOULD" would be in 
> >place, here.)
> 
> >My suggestion: EOS means "broken message", so the "messages MUST end
> >with (CR)LF" really means _must_.  This makes it easier for 
> receivers;
> >if their socket layer is too hidden from view, it may be hard to 
> >differentiate between "graceful FIN handshake" and 
> "connection b0rken".
> 
> Agreed. Keep buffering the input stream until we get a valid 
> terminator OR reach the max message size.
> 
> What should we use for max message size? My suggestion is 
> ~65520. Are you still wanting a larger message size Rainer?

Mmmmhhh, well, 65520 would definitely make my day (year)... But I am a
little concerned about compatibility, again. Everything we have done so
far can be easily mapped to traditional syslog. But once we go over 1024
Byte, it is hard to imagine how to handle this. On the other hand, in
our products we have a strict RFC3164 mode which simply discards
everything after byte 1024. So maybe we should handle it the same way?
Allow close to 64K but ask the developer to put important stuff early in
the message and warn him that it might become truncated?

> 
> >A less-than-important thing: a standard port number would be 
> >nice, but 514/tcp is officially taken :/   
> 
> Hmmm, good point.
> 
> PIX uses 1468 normally. Like you say, we should keep this one 
> separate and use another port.

Yes - and I think we won't receive an IANA assignment as this seems not
to turn into an RFC in the short term...

So I opt to suggest a default port (whatever it is - maybe 1514?) and
allow this to be overridden by the admin...

> 
> 
> >Explicitly: high resolution timing is valid but optional, so 
> >2003-01-05T12:08:50.12345678+01:00  and 
> 2003-01-05T12:08:50+01:00  are 
> >both valid
>    
> Yep, happy with that too.
> 
> 
> > - Who will support it? (this is the big one ;-))
> 
> Count the Kiwi in too :-)

:-D

Andrew: I know that you have a much enhanced spec for syslog over TCP.
How do you plan to proceed with this? I guess you noted that I
explicitely said it is not included. I did so because I think it is now
time to implement a quick hack in a number of products. If I count
right, I am at 4 possible implementations at the end of this month ;)

Chris: do you think it makes sense to re-address this in the syslog-sec
WG? Honestly, I am a bit tired of re-iterating it there as there seems
so much opposition against such an easy but helpful hack... (that kind
of hack that brought us original syslog). 

Rainer
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis