Re: [syslog-sec] Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Magosanyi Arpad
A levelezõm azt hiszi, hogy Volker Wiegand a következõeket írta: It must be a single port one way tcp connection. One way means "one tcp socket", not "packets going only to one direction". No, IMHO we want TCP _and_ UDP. I use two loghosts and many clients. That would mean a

Re: [syslog-sec] Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Chris Calabrese
Authentication/encryption services don't have to be directly provided by the logging system itself, but the logging system must have enough intimate contact to guarantee that logs are only going to where they're supposed to and that logs came from where they were supposed to. Also, the logging

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Robert Webber
At 12:58 PM 10/20/1999 +0200, Andreas Siegert wrote: Quoting Kriss Andsten ([EMAIL PROTECTED]) on Wed, Oct 20, 1999 at 12:14:11AM +: Also the lack of timeZONE info in the timestamp is a common gripe. It might be worthwhile to add a short field with this info i.e:

Re: [syslog-sec] Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread by way of Chris M. Lonvick [EMAIL PROTECTED]
"cstone" == cstone [EMAIL PROTECTED] writes: cstone Keeping backwards compatibility with traditional syslog by accepting cstone its UDP messages is a useful goal--I don't really like the idea cstone of running two syslog daemons speaking two entirely different protocols This is _entirely_

Re: [syslog-sec] Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Darren Reed
In some email I received from Bennett Todd, sie wrote: [...] Yet, I would suggest the most common place for losing a UDP packet is not across a LAN but in the buffering at either the sender or the receiver. That's probably the commonest place, with buffering at routers in between

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Russ Allbery
Calabrese, Christopher [EMAIL PROTECTED] writes: Huh? 11 digits worth of seconds takes you out to 5138, and there's nothing here that limits the number of digits (I was just pointing out that you'll use less than 11 digits for the foreseeable future - in fact 10 digits gets you to

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread by way of Chris M. Lonvick [EMAIL PROTECTED]
"Roger" == Roger Marquis [EMAIL PROTECTED] writes: Roger Again, from the perspective of an administrator, 5 bytes of timezone Roger info cab be a great help in a number of ways. For reports it is much Roger easier than determining the source timezone by looking at the source Roger hostname

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Chris Calabrese
Roger Marquis wrote: [...] from the perspective of an administrator, 5 bytes of timezone info cab be a great help in a number of ways. For reports it is much easier than determining the source timezone by looking at the source hostname (required with existing syslog format). That's

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Klaus Moeller
A 64-bit binary microsecond counter comes out like this: * Resolution - excellent * Bandwidth - 8 bytes * Ease of processing off the wire -poor on processors not capable of doing 64-bit processing, especially if different endianness than net transmission

RE: timestamps and timezones (was: time-sync)

2000-04-10 Thread Calabrese, Christopher
-Original Message- From:Andreas Siegert [SMTP:[EMAIL PROTECTED]] Sent:Thursday, October 21, 1999 5:27 PM To: [EMAIL PROTECTED] Subject: Re: timestamps and timezones (was: time-sync) Quoting Chris Calabrese ([EMAIL PROTECTED]) on Thu, Oct 21, 1999

Re: timestamps and timezones (was: time-sync)

2000-04-10 Thread Darren Reed
In some email I received from Calabrese, Christopher, sie wrote: [...] Yeah, I'm willing to concede the point. I'm beginning to think YYMMDDmmhhss.fraction really is better since it's easier to deal with in a tcpdump, etc. Y2K bug alert! How about