See inline...-----Original Message-----From: [email protected]: 05/25/2010 03:54 AMRFC 4346 (from which this text comes from) mostly did not use RFC2119 keywords, but instead informal language like the lowercase "should not" you quoted. AFAIK it was meant to express a strict limit, not a recommendation (this is implied by other text in the spec, and as you noticed, we clarified this in RFC 5246). But even though DTLS records are limited to 2^14 bytes, syslog messages are not! The current spec seems to support 64K (minus some small number of overhead) just fine -- the message will be split to multiple DTLS records (max. 2^14 bytes each), but those DTLS records are then combined to a single UDP datagram. <tievens> Ahh... Only if DTLS sequence numbers are used and if they are implemented using a reorder queueing method can a message be split into "chunks" that are transmitted over multiple DTLS records. This leads to the issue of what happens when a packet is dropped? Even if you follow the DTLS sequence numbers, UDP and DTLS do not support retransmission, thus that lost packet is lost forever. This would lead to one message "chunk" being concatenated with a different message altogether. This is why I was suggesting a SYSLOG-FRAME-ID. </tievens> Best regards, Pasi
_______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
