> Issue 8: Length of syslog messages > http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.ht > ml#format > > From Archive: > http://www.mail-archive.com/syslog-sec%40employees.org/msg01118.html > http://www.mail-archive.com/syslog-sec%40employees.org/msg01119.html > http://www.mail-archive.com/syslog-sec%40employees.org/msg01120.html > > It's defined as 1024 in several places. Mike McFaden offers a good > suggestion in the 3rd pointer above: > > I prefer that the minimum size a conformant > implementation must support be defined. > SNMP over UDP specifies a minimum message size of 484. > If one wants to support a larger msg size, just configure for it. > The same goes for switches these days too. > Otherwise why not just recommend a transport that has > path mtu discovery in cases where syslog msg length > 1024. > > Any comments or other suggestions?
Actually, I honstely think path MTU discovery is probably not within the "simple" spirit of syslog: #1 it is not done easily (especially if ICMP is filtered) #2 I think it is not suffcient to look at the transport layer, as we may have different transports, which makes it even harder Let me focus on #2. Let's assume the relay chain below: Device -- RFC3164 --> Relay 1 Relay 1 -- 3195/COOKED --> Relay 2 Relay 2 -- RFC3164 --> Relay 3 Relay 3 -- 3195/RAW --> Relay 4 Relay 4 -- 3195/COOKED --> Collector OK, I agree this is probably not what we often see. But we could see it. But we could also look at this simpler sample: Device -- 3195/COOKED --> Collector What is the MTU in this case? Is it the default BEEP window size? Is it unlimited as I can fragment the message without any need to change the syslog message (AND it will arrive reliably & in order)? In addition to that, syslog messages are sometimes transferred via proprietary solutions (e.g. syslog over plain tcp with syslog-ng, winsyslog and kiwi syslog the least) in parts of the relay chain. Of course, they are non-standard so we don't need to take care ... but will we get acceptance for a standard if it forces users to switch to a totally different logging infrastrucutre? will we get developers to implement those solutions if they cause big interop (and thus customer support) issues for them? ... probably not. I would prefer if we stick with a slightly upwards trimmed 1024 byte limit for a single plain syslog message. It has prooven to work even over udp in (obviously) almost all cases (smaller MTUs!). Many have pointed out that 1024 bytes is by far enough for their needs. I would, however, like to extend the core syslog format (either via a separate rfc or in -international) to support app-aware fragmentation of syslog messages so that a sender who needs to send a larger message - for whatever reason - can put that larger message into multiple 1024 byte messages in a standard-conformant way. Rainer
