I have gone through all of the good posts on this issue. I have the feeling that we currently have the following status:
- some people argue that a "synced/I know my TZ" indicator for the timestmap has advantages in the real world - some people argue that a "synced/I know my TZ" indicator for the timestamp has no advantege in the real world, because nobody can automatically assert the timestamp - among those who would like to have a timestamp, there are some that would favour chaging the RFC3339 stamp and others who not like this idea. All of those who do not like the indicator do also not like changing the timestamp in a non-standard way. - if an indicator would be provided, I think it is concensus that this indicator should take up only very limited message space in the usual [?;)] case of synced time and known TZ - there is more than one issue, effectively, it is o am I synced to a reliable source? o do I know my TZ? o how good is my timesync (precision issue) - in the real world, there we can't demand timesync is in place, so we can't really follow RFC 3339 in this regard This is my honest try to sum it up - PLEASE correct me if you think I am wrong. I've tried to be neutral, but as I have my own opinion, it might have influence the summary. In the light of this sum-up, I propose the following compromise: - we will continue to use the rfc 3339 timestamp in its unmodified way - we will ignore that RFC 3339 calls for timesync (because we can't ensure it) - there will be NO header field indicating the reliability of the time flag - there will be an optional structured data element which allows to specify the timestamp reliability in all three cases. If it is absent, it is assumed that the timestamp is correct. If an implementor has a good indication this may not be the case, his implementation SHOULD write the respective element indicating this - the ID in general and/or its security considerations should list this imperfection I know this probably is not the ideal form. But given the diversity of good (!) thoughts on this issue, I think it is an agreeable compromise ... or may be not ;) Rainer > -----Original Message----- > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 12, 2004 11:39 PM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: RFC 3339 & UTC offset > > Rainer: > > > #1 is more a spec-stunt than a real solution ;) > > In 4.4, RFC 3339 says > > > > ### > > o Use another host in the same local time zone as a > gateway to the > > Internet. This host MUST correct unqualified local > > times that are > > transmitted to other hosts. > > ### > > Definitely a stunt. :) This requirement is constraining deployment > options. > > > #2 is to "tweak" the format a little bit. Honestly, I don't > > like this messing with a standard, and this is very far to > the edge... > > > > All special sequences (like "-00:00") are already taken up. > > 3339, however, specifies that the "Z" UTC indicator can be > > either upper or lower case. I have choosen to allow only > > upper case for simplicity. We > > *could* say that if the device does not know its ZT and does > > not know if time is properly synced, it should use "z" (lower > > case) as the TZ indicator. This would still be a valid 3339 > > indicator, but definitely not be in the spirit of 3339. > > I think it is okay, although the distinction is not as clear as I'd > prefer. I like "-----" for offset because this removes ambiguity. I > know it is not consistent with RFC3339, but RFC3339 format is ONLY for > situations when you know the offset, which won't always be > the case for > syslog clients. So, I guess in some cases RFC3339 is not appropriate. > > > #3 is to actually add a syslog header field "I know my TZ > > info or I am synced" (Y/N) in -protcol, eventually adjecent > > to the timestamp field. Honestly, this, too, does not smell > > really good to me. > > I think the "I am sync'ed" maybe be different than "I know my TZ". For > example, you maybe no be sync'ed but know your time zone. > > This brings up another question that maybe other people raised before. > I guess there are cases when you know the time is definitely > NOT synced. > But when do we consider it synced? What's the precision of > sync'ed? Does > it mean it is sync'ed with NTP or set manually yesterday? > > I guess for some cases "set manually yesterday" is fine, but for other > cases (say when correlating messages from multiple systems based on > precise time) this is not good enough because clocks drift > and manually > set time can't be precise. So, maybe this is a deployment-specific > decision how the "authoritative-time" flag is interpreted? > > Anton. > > > >
