headers
Sharon Chisholm | 4 Apr 2005 15:16
Favicon

RE: 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 <at> willers.employees.org
[mailto:syslog-sec-bounces <at> willers.employees.org] On Behalf Of Chisholm,
Sharon [CAR:5K50:EXCH]
Sent: Wednesday, March 23, 2005 3:34 PM
To: syslog-sec <at> 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;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 4 Apr 2005 17:39

RE: syslog message truncation

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 <at> www.employees.org 
> [mailto:syslog-sec-bounces <at> www.employees.org] On Behalf Of 
> Sharon Chisholm
> Sent: Monday, April 04, 2005 3:17 PM
> To: syslog-sec <at> 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 <at> willers.employees.org
> [mailto:syslog-sec-bounces <at> willers.employees.org] On Behalf 
> Of Chisholm,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albert Mietus | 5 Apr 2005 09:16

Status of -sign

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/read.ITsyslog-sec <at> employees.org

_______________________________________________
Syslog-sec mailing list
Syslog-sec <at> www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec
Permalink | Reply | 1 comment |
headers
Chris Lonvick | 5 Apr 2005 14:42
Picon
Favicon

Re: Status of -sign

Hi Albert,

We're pushing to get syslog-protocol and syslog-transport-udp out before 
we finalize syslog-sign.  It is still in our Charter to do that.  I'll 
ask Jon to update it so it won't expire.

Thanks,
Chris

On Tue, 5 Apr 2005, Albert Mietus wrote:

> 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?)
> 
> 
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Gerhards | 6 Apr 2005 17:04

RE: Detailed Review Comments on Syslog Protocol -09- Part II

Sharon,

I snipped some things which now have separate threads - I'll post the
reply to those threads. 

> S7. In relation to section 6.2.3, do we want to add a 
> section called 
> > 'Relationship to the Alarm MIB' so we can discuss the mapping of 
> > severities? This is something that has come up in private 
> discussions
> > since these do
> > differ somewhat from ever popular OSI severities. I could 
> > write this section
> > up if there is interest. Terribly useful in the case of 
> > someone logging
> > alarms.
> > 
> 
> This has been added - text proposed to WG, some feedback 
> received but should
> be further reviewed
> 
> </Rainer>
<Sharon>
> Um. I seem to have missed this. Let me propose the following text
> 
> "Relation to the Alarm MIB"
> 
> The Alarm MIB [RFC3877] defines ITU perceived severities 
> which are useful to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rainer Gerhards | 6 Apr 2005 17:58

RE: syslog message truncation

Sharon,

I just integrated your suggestion into the draft. During that, I noticed
a small but eventually important thing. You wrote:

> 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
> -----Original Message-----
> From: syslog-sec-bounces <at> www.employees.org 
> [mailto:syslog-sec-bounces <at> www.employees.org] On Behalf Of 
> Sharon Chisholm
> Sent: Monday, April 04, 2005 3:17 PM
> To: syslog-sec <at> employees.org
> Subject: RE: [Syslog-sec] syslog message truncation
> 
> hi
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sharon Chisholm | 6 Apr 2005 19:48
Favicon

RE: syslog message truncation

hi

I believe I meant dropping the entire set of parameters.

Sharon

-----Original Message-----
From: syslog-sec-bounces <at> willers.employees.org
[mailto:syslog-sec-bounces <at> willers.employees.org] On Behalf Of Rainer
Gerhards
Sent: Wednesday, April 06, 2005 11:58 AM
To: syslog-sec <at> employees.org
Subject: RE: [Syslog-sec] syslog message truncation

Sharon,

I just integrated your suggestion into the draft. During that, I noticed a
small but eventually important thing. You wrote:

> 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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tom Petch | 7 Apr 2005 14:56

Re: Detailed Review Comments on Syslog Protocol -09-Part II

<below>
Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <rgerhards <at> hq.adiscon.com>
To: <syslog-sec <at> employees.org>
Sent: Wednesday, April 06, 2005 5:04 PM
Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09-Part
II
<snip>

I think that 'SHOULD identify a specific instance' opens up a can of worms.
Identification implies uniqueness whereas the process ids I see on small systems
are small integers, which may be replicated after a few reboot/process-restarts,
perhaps on the next reboot/restart.  I do not believe a process id can support
the burden of a 'SHOULD' ('MAY' perhaps).  To get a 'SHOULD' over say 10
consecutive reboots, you have to start forcing some randomness into process ids,
eg basing them on a high-resolution clock (think TCP sequence numbers) or else
having non-volatile storage to record the last n values.

Perhaps some router manufacturer or producer of Linux systems can convince me
that such technology exists in low end devices but currently I am sceptical.

And, a minor point, when I first read this, the use of instance threw me; I took
it to be the identification of one box as opposed to another (as I think Sharon
did), rather than a restart of the processes within a box; but I am struggling
for a better work.

Sharon,
I am now proposing the following text for APP-INST (formerly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Petch | 7 Apr 2005 18:14

Fw: Detailed Review Comments on Syslog Protocol -09 - Part III

Trying to post this - attempt 2.

Tom Petch

----- Original Message -----
From: "Tom Petch" <nwnetworks <at> dial.pipex.com>
To: "Sharon Chisholm" <schishol <at> nortel.com>
Sent: Thursday, April 07, 2005 3:16 PM
Subject: Re: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part
III

> <inline>
> Tom Petch
>
> ----- Original Message -----
> From: "Sharon Chisholm" <schishol <at> nortel.com>
> To: <syslog-sec <at> employees.org>
> Sent: Friday, March 18, 2005 9:40 PM
> Subject: RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 -
Part
> III
>
> ><snip>
> > As far as sysUptime is concerned, I think we should stick with the SNMP
> > definition of the number of milliseconds since boot, with a max value of
> > 4294967295 and automatic reset to zero thereafter. Is this understanding
> > correct?
> >
> I think not;  [RFC 3418] defines sysUpTime as having a SYNTAX of TimeTicks and
> [RFC 2578] defines TimeTicks as
(Continue reading)

Permalink | Reply | 1 comment |
headers
David B Harrington | 7 Apr 2005 22:15
Picon

RE: Detailed Review Comments on Syslog Protocol -09 -Part III

Hi,

Please note that the starting epoch for SysUpTime is the
reinitialization of the network management system (e.g. the SNMP
agent). This may be different than "boot" which typically refers to
reinitialization of the hardware device. Granularity is in hundredths,
not thousandths of a second.

If you want the amount of time in TimeTicks since the device was last
initialized, you might consider hrSystemUptime from the Host Resources
MIB [RFC 2790].

> > ><snip>
> > > As far as sysUptime is concerned, I think we should stick 
> with the SNMP
> > > definition of the number of milliseconds since boot, with 
> a max value of
> > > 4294967295 and automatic reset to zero thereafter. Is 
> this understanding
> > > correct?
> > >
> > I think not;  [RFC 3418] defines sysUpTime as having a 
> SYNTAX of TimeTicks and
> > [RFC 2578] defines TimeTicks as
> >   "...represents a non-negative integer which represents
> >    the time, modulo 2^32 (4294967296 decimal), in 
> hundredths of a second
> >    between two epochs."

David Harrington
(Continue reading)

Permalink | Reply | 0 comments |

Gmane