RE: [Syslog-sec] syslog message truncation

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Sharon,

from my point of view, it's agreement. I am back in the office and will
also look at the other open issues this week. If I hear no objection, I
will include the suggestion below into the draft.

Rainer

> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org 
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of 
> Sharon Chisholm
> Sent: Monday, April 04, 2005 3:17 PM
> To: syslog-sec@employees.org
> Subject: RE: [Syslog-sec] syslog message truncation
> 
> hi
> 
> Is silence consent on this one? I'm interested to know if we 
> agree with
> this.
> 
> Thanks,
> 
> Sharon
> 
> -----Original Message-----
> From: syslog-sec-bounces@willers.employees.org
> [mailto:syslog-sec-bounces@willers.employees.org] On Behalf 
> Of Chisholm,
> Sharon [CAR:5K50:EXCH]
> Sent: Wednesday, March 23, 2005 3:34 PM
> To: syslog-sec@employees.org
> Subject: RE: [Syslog-sec] syslog message truncation
> 
> 
> hi
> 
> Ok. My current thinking on message truncation is that we want 
> to encourage
> the dropping of the SD-PARAMS and the retention of the 
> message text. This is
> the more unique bit and makes for much simpler truncation. We 
> can add a bit
> to the header if we want or indicate that if the SD-PARAM 
> list is blank,
> then truncation may have occurred. Ok. a bit in the header is probably
> better.
> 
> So, the preference is
> 
> 1) No truncation
> 2) Truncation by dropping SD-PARAMS; 
> 3) If 2) not sufficient, truncate message
> 4) In the case that truncation cannot result in a valid message then
> dropping. Note that given the current truncation algorithm, 
> this may not
> actually occur.
> 
> Sharon
> 
> 
> 
> -----Original Message-----
> From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] 
> Sent: Tuesday, February 15, 2005 7:42 AM
> To: Chisholm, Sharon [CAR:5K50:EXCH]; syslog-sec@employees.org
> Subject: RE: [Syslog-sec] syslog message truncation
> 
> 
> Sharon,
> 
> > 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.
> 
> I am not sure if it is appropriate to drop the message 
> completely. At least
> the drop should be optional (maybe with a rule that the 
> truncated message
> should not further be forwarded).
> 
> I am concerned because I think we might loose vital 
> information in this
> case.
> 
> As an alternate approach, the "truncation information field" 
> could have
> three values:
> 
> n - no truncation occured
> m - truncation im MSG part
> s - truncation in STRUCTURED-DATA part
> 
> that would convey enough information to the (ultimate) 
> receiver so that it
> can decide how to act on a message.
> 
> Comments?
> 
> 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
> 
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec