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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross
Sent: Wednesday, November 23, 2005 2:53 AM
To: 'Rainer Gerhards'
Cc: [EMAIL PROTECTED]
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
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
