Subject: RE: [Syslog] RE: Message format

From: "Moehrke, John \(GE Healthcare\)" <[email-masked]>
Date: Wed, 23 Nov 2005 07:36:26 -0600

To all,

The view that syslog must only be used to transport "human readable
syslog messages" is disturbing. Is this the view of the syslog
community? If it is then I know that healthcare will take it's security
audit message (RFC3881) and build our own transport likely using web
services. We will need to find experts in security audit event analysis,
but we are tiring of this syslog community behavior.

Don't get me wrong, I am ok with putting a MTU on the message when it is
transported over UDP. As was pointed out 4k should be fine. 

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Ross
> Sent: Wednesday, November 23, 2005 2:53 AM
> To: 'Rainer Gerhards'
> Cc: [email-masked]
> Subject: [Syslog] RE: Message format
> 
> 
> >> Mapping over UDP should be limited to a single message per packet.
> >I agree on that. If we need an ultra-compact UDP delivery, we could
> >later add it in a separate transport mapping.
> 
> Yes, good idea. I doubt anyone will ever want to do this, or 
> at least go to
> the effort of trying to get it drafted into an RFC ;-)
> 
> >> When mapping over plain TCP I believe we should limit the 
> >> total message size
> >> to 65507 bytes (to keep it compatible with UDP) and delimit 
> >> each message
> >> stream with an LF, or CRLF. Either delimiter would work for me.
> 
> >I would prefer not to restart the size discussion at this 
> point. I think
> >the current compromise (everyone must support 2K, anyone 
> might support
> >as much as he likes) is sufficient for most, if not all, 
> cases. I would
> >not like to see an application to become non-compliant just 
> because it
> >needs to transmit 65508 bytes inside a message.
> 
> <SOAPBOX>
> I realise this should have been brought up earlier in the 
> draft process,
> however, I would really like to see a limit on the message 
> size so that it
> is directly compatible with UDP. If we allow an opened ended 
> message size,
> people *will* use it for non syslog related things. I feel 
> that any message
> longer than will fit into a UDP packet should be broken into 
> two or more
> separate messages by the sender, even if sent over TCP. This 
> allows me to
> allocate a maximum known buffer size for incoming TCP 
> messages. There is a
> potential for huge messages filling the memory and memory 
> buffer overflows
> happening if the messages are not limited in size. "Syslog" 
> is meant to be a
> human readable system log message. Anything longer (including 
> binary crash
> dumps or other things people misuse syslog for) should be broken into
> separate messages by the sender, or sent over a different protocol.
> </SOAPBOX>
> 
> I think we should keep syslog simple and flexible, but not at 
> the expense of
> making it handle things it was never meant for. If a message 
> needs to be
> broken into many chunks, the SD-ID tags could be used to tie all the
> messages together again by the parser. The syslog receiver or 
> relay will
> just handle them as separate messages and not even know they 
> were split.
> This makes things so much simpler.
> 
> Cheers
> 
> Andrew
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Darren Reed <[email-masked]>
Date: Thu, 24 Nov 2005 01:08:34 +1100 (EST)

> community?

At present what we're concerned with is a logging facility that does
generate and consume human readable messages.

At some point in the future, when we have agreement on the human
readable version, then we can consider what to do with messages
that aren't human readable.

So while I accept your assertion, addressing it is out of scope for
the current discussion.  We have smaller fish to fry, first, before
attempting the big ones.  Trying to solve "all the problems" is what
got this group into the situation we are in now.  We need to take a
step back and focus on resolving smaller and more well defined
problems before looking at a "grand unified logging protocol" (GULP).

Nothing lasts forever, not even standards.

Darren