[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] syslog message truncation
hi
I would agree that a truncation bit in the header if truncation is performed
is better than at the end of the message. I would also agree that truncation
within the structured data is too expensive and unstable. I still worry
though, about the loss of information that would result from messages being
systematically dropped due to length mismatches, so would propose something
along the following lines:
If truncation is required, then the point of truncation be determined. If it
is within the message text, then the truncation bit be set within the
message header and the message be sent with its reduced size. If the point
of truncation is somewhere before the message text, then this message be
discarded.
Sharon
-----Original Message-----
From: syslog-sec-bounces@willers.employees.org
[mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer
Gerhards
Sent: Tuesday, February 15, 2005 5:33 AM
To: syslog-sec@employees.org
Subject: [Syslog-sec] syslog message truncation
Hi WG,
Sharon has provided the following good comment:
###
> S3. In section 6.1, we need some guidelines on how to truncate
> SD-BOUNDARIES. Can the structured data become non-compliant or must it
> still be valid? If
> within the message part, is it just arbitrary? Should we indicate
> truncation has occurred in the header or at the very end of
> the message? Do
> we need to leave room for some extra characters at the end to
> signify the
> message has been truncated?
###
I've thought and re-thought about this, but I do not have a clear
preferrence, so I would like to bring this up on the WG mailing list.
I think the best solution would be to NOT allow truncation of structured
data elements. I personally think it would complicate things at the analysis
end if we allow truncation of structured data. Keep in mind that we
currently ALLOW such truncations, because we have set up no specific rules
for that. If we now go ahead and disallow it, it might become more
complicated for a relay to carry out the necessary truncation. This, some
might say, is an unnecessary burden. As you can see, there are pros and cons
for each scenario.
The same goes for indication of message (not only structured data)
truncation. I am tempted to add a header field "message truncated". However,
I am not sure if that is something that we actually need. Or, better said,
that is worth it. Keep in mind that we have very limited space inside the
message and such a header would cost additional 2 octets (from a 480 octet
minimum size). If we indicate truncation, I would strongly opt to add this
to the header and NOT at the end of the message (indication at the end of
the message would make a MSG delimiter mandatory, which we do not have
currently).
Any comments are deeply appreciated.
Rainer
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec