Subject: RE: [Syslog-sec] syslog message truncation

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 4 Apr 2005 09:16:57 -0400

hi

Is silence consent on this one? I'm interested to know if we agree with
this.

Thanks,

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chisholm,
Sharon [CAR:5K50:EXCH]
Sent: Wednesday, March 23, 2005 3:34 PM
To: [email-masked]
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:[email-masked]] 
Sent: Tuesday, February 15, 2005 7:42 AM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
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
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 23 Mar 2005 15:33:46 -0500

hi

So, the preference is

1) No truncation

Sharon

-----Original Message-----
From: Rainer Gerhards [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2005 7:42 AM
To: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
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

Comments?

Rainer

mployees.org  Tue Apr  5 03:17:10 2005
To: [email-masked]
From: Albert Mietus <[email-masked]>
Date: Tue, 5 Apr 2005 09:16:49 +0200
Subject: [Syslog-sec] Status of -sign
Sender: [email-masked]

Question:

Will there ever be an "syslog-sign" RFC?

There are lost of drafts, I started to implement  for some years, but 
currently I don't see a lot of progress on it.
Yes, there are "other/better" syslog-RFC discussions. But the best part 
of -sign is that is will work on each
current/old syslog-network.

The current draft (15) will expire in a few weeks. Please continue with 
this document. It isn't bad. So Let finalize it. If the future will 
learn it can a little better, there is room for improvements (Didn't we 
'invent' version numbers for that?)

--Groetjes
ALbert Mietus
	Send prive mail to:          ALbert at ons-huis dot net
	Send business mail to:  Albert dot Mietus at PTS dot nl
	Don't send spam mail!
http://albert.mietus.nl               
http://albert.mietus.nl/[email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 6 Apr 2005 17:58:20 +0200

Sharon,

I just integrated your suggestion into the draft. During that, I noticed

> 2) Truncation by dropping SD-PARAMS; 

An SD-PARAM is a parameter of an SD-ELEMENT. It describes this element.
I think we should not drop a single parameter but rather the full
SD-ELEMENT if we need to truncate. Otherwise we can run into subtle
complexities. As such, I have changed the text as follows:

1) No truncation
2) Truncation by dropping SD-ELEMENTS; 
3) If 2) not sufficient, truncate message

Please let me know if that is NOT what you would like to see. Sorry, I
didn't spot this until I cross-checked it with examples.

Rainer
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Sharon Chisholm
> Sent: Monday, April 04, 2005 3:17 PM
> determined.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 6 Apr 2005 13:48:48 -0400

hi

I believe I meant dropping the entire set of parameters.

Sharon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rainer
Gerhards
Sent: Wednesday, April 06, 2005 11:58 AM
To: [email-masked]
Subject: RE: [Syslog-sec] syslog message truncation

Sharon,

I just integrated your suggestion into the draft. During that, I noticed a

> 2) Truncation by dropping SD-PARAMS;

An SD-PARAM is a parameter of an SD-ELEMENT. It describes this element. I
think we should not drop a single parameter but rather the full SD-ELEMENT
if we need to truncate. Otherwise we can run into subtle complexities. As
such, I have changed the text as follows:

1) No truncation

Rainer