Hi, Who makes the assertion that "you can trust my timestamp"? An application? As Devin points out, an application has no way to determine whether a timestsamp is valid, and thus cannot be trusted to make a valid assertion on its own.
The best you could do is allow an administrator to set a value (maybe via a mib object) that asserts "the timestamps used by this syslog engine are reasonably valid", and it would be up to the administrator to make sure the assertion is reasonably valid. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 12:26 PM > To: Devin Kowatch > Cc: Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: RFC 3339 & UTC offset > > one more thing... I just got a - I think - good idea. We > could say that > by default, we don't fully trust the timestamp. Then, we > could define an > optional structured data element (hey, we've got those!) that > says "yes, > you can trust my time". This could also be extended for use by > timestamper services. > > Out of the options so far, I like this one most... > > Rainer > > > -----Original Message----- > > From: Devin Kowatch [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 12, 2004 6:19 PM > > To: Rainer Gerhards > > Cc: Anton Okmianski; [EMAIL PROTECTED] > > Subject: Re: RFC 3339 & UTC offset > > > > On Wed, Feb 11, 2004 at 06:35:28PM +0100, Rainer Gerhards wrote: > > > Anton, > > > > > > this is a tough one ;) > > > > > > > Well, I think demanding that capability is more about host > > > > implementation. I think it is better to focus on the > > > > protocol and what > > > > the client/sender must put into the UTC offset field if > > one is not set > > > > on the system. > > > > > > This is right. And I have to admit it is an important > > issue. We always > > > have nightmares about non-timesynced devices, as many > > customers have. In > > > fact, the default of our product is to use time of > > reception, not the > > > time from the message timestamp. I guess this shows it > > actually *is* a > > > real world issue... > > [ snip ] > > > > The problem that I have with these solutions is that they > require the > > syslog daemon to know if the time and timezone on the machine > > are valid. > > I can't think of any way of doing that. I'd would be > perfectly happy > > with a recomendadtion that the hosts should hove the correct > > time/timezone information. However, ultimatly it's the sys admin's > > problem if their machines have incorrect time/timezone. And the sys > > admin which will suffer for it. > > > > This isn't meat to trivialize the issue, but I don't think > that it's a > > problem which we should try to solve in the syslog > protocol. You can > > only do so much to protect people from them selves. > > > > My $0.02 > > > > -- > > Devin Kowatch > > [EMAIL PROTECTED] > > > > >
