Anton, I could not go in-depth through the draft, but I have some comments...
> One area I am not quite sure about yet is what minimum size > of messages should implementations be forced to support. It > definitely can't be the full allowed size of 16MB as some > hardware won't support it. Right now it is set at 65k, which > means implementations are forced to support fragmentation. I I think this is the most important one. I strongly think that we should NOT say the max MUST is 65k - if we really do this, we acutally say that everything beyond 65k can not really be expected to work. We must guarantee that the max size of 16 MB can be reliably transmitted, else the whole thing is useless. After reading this parts of the draft, I have to admit I am not sure if it really was a good idea to move the fragmentation into the transport. As it was designed in -protocol, it were multi-part message, very low overhead, very easy to deal with enourmous amounts of data. A key to that simplicity was that each receiver was free to *ignore* multi-part messaging, because each multi-part message was a valid syslog message in itself and could be treated as such - no complexity at the receiver/relay, nothing that could overrun a low-end device. Now, we mandate that everybody support the full sizes ... And begin to get into trouble. In any case, however, I strongly suggest that we require that full message size is supported, because otherwise it is pointless to mention it. As I said, with the current proposed ID the max size is actually 65k, which I think is not in the spirit of -protocol. Re 4.1: ### 4.1 Target Port Syslog receivers MUST support accepting syslog message datagrams on a well-known UDP port 514. Syslog senders MUST support sending syslog message datagrams to the UDP port 514. ## Is this really a MUST? Many admins will not allow this, any real-world syslog deamon must support non-514 ports (only), because else it will probably be ditched for security reasons by some admins. Re 4.2: ### 4.2 Source Port Syslog senders can use any source UDP port for transmitting messages. Senders MAY randomly select a source port, but MUST use the port in an exclusive fashion. No concurrent port reuse on the same host is allowed. ### I think I can not guarantee "no concurrent port reuse" in our implementatons - this may be very hard to avoid in multi-process, multi-threading apps. I suggest we drop this requirement. I've seen RFC 3164 being referenced multiple times. AFIK, this can cause problems in becomeing a standards-track RFC (because 3164 is informational). Just a hint to check with those experienced in these issues - I may be totally wrong. Rainer
