Subject: [Syslog] Sec 6.1: Truncation

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Fri, 6 Jan 2006 15:47:41 -0500

Rainer and all:

I started reading draft #16. Since we are revisiting everything... I am not very comfortable with the current truncation rules. 

"Receivers SHOULD follow this order of preference when it comes to truncation:

 1) No truncation
 2) Truncation by dropping SD-ELEMENTs
 3) If 2) not sufficient, truncate MSG"

I don't think that this is a good recommendation.  I would assume that in many cases people would try to tokenize more important data into structured data and use message text as a secondary user-friendly description. For example, for LINK_DOWN message, I would probably encode link ID in the structured elements as this is something that should be readily available for receivers. The MSGID could be "LINK_DOWN" and the MSG text may simply be "Link down".  If you truncate the structured data, it makes it harder. 

I also think, in general it is useful to put more important data first, which is another reason for putting more valuable data into structured data in a more compact way.  

Additionally, structured data can be used to provide message length or digest, which can help receiver to determine if message was truncated. 

Also, I think this statement is very convoluted:

"Please note that it is possible that the MSG field is truncated without dropping any SD-PARAMS.  This is the case if a message with an empty STRUCTURED-DATA field must be truncated."

I think I understand what you are driving at, but I don't see it as adding any requirements or clarification. 

This sentence is not clear although I know what you are trying to say:

"The limits below are minimum maximum lengths, not maximum length."

I propose replacing the entire section 6.1 with this text:

"Syslog message limits are dictated by the syslog transport mapping in use. Each transport mapping MUST define the minimum required message length support. Any syslog transport mapping MUST support messages of up to and including 480 octets in length. 

Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length.  All receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length larger than it supports, the receiver MAY discard the message or truncate the payload.  

If truncation is performed by the receiver, it MUST first truncate the MSG field as necessary to meet the supported length limit. If truncation of the entire MSG field is not sufficient, then additionally, the STRUCTURED-DATA field MUST be truncated by removing one or more SD-ELEMENT fields. A minimum number of SD-ELEMENT fields MUST be truncated starting from the end as necessary to meet the supported length limit. SD-ELEMENT field can't be truncated partially. If all SD-ELEMENT fields are removed, NILVALUE MUST be specified for STRUCTURED-DATA field. Truncation of HEADER field MUST NOT be performed."   

BTW, in your text or mine, what happens if message is malformed?  A proxy won't be able to truncate it properly then. We don't want to prevent it from truncating it in some way and sending the message further, I would think.  At least you will see something at the final destination, which maybe more useful than nothing. If we just made truncation a simple take the first X octets out of Y octets, it would not be an issue, but then proxy would be allowed to turn a well-formed message into malformed message upon truncation.   

What do you think?

Thanks,
Anton. 

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

---

From: Darren Reed <[email-masked]>
Date: Sat, 7 Jan 2006 21:59:50 +1100 (EST)

[ Charset ISO-8859-1 unsupported, converting... ]
> Rainer and all:
..
> I don't think that this is a good recommendation.

Is this likely to be how people implement truncation ?

I'm more inclined to believe that truncation will happen when the
incoming message is too big for a buffer, so you start reading in
data (and dropping it) until you reach the end of the buffer.

The above requirement forces everyone to accept all maximum length
messages before deciding one is too big.

> I also think, in general it is useful to put more important data first,

Agreed.

Darren