Re: [sip-clf] WGLC: SIPCLF Problem Statement(draft-gurbani-sipclf-problem-statement-01)

["Rainer Gerhards" <[e-mail]>]

> I was considering also saying compatibility with syslog definition of
> timestamp but my recollection of that (which may be very wrong - been
> awhile since I looked at it) left me more than a bit confused about
> syslog tmestamps. It seems that every syslog packet I have ever seen in
> the wild uses the BSD Syslog timestamp format in RFC 3164 but clearly
> that is more or less borked for any real correlation across time zones
> so it seems like 5424 version of timestamp would be better. The 5424
> allowed the local offsets which resulted in no real canonical format
> for time which mean some people implemented the full things and some
> ignored the local offsets results in interoperability problems.

Well, I don't know any such broken implementations, but they are clearly
broken. That is because time zone information MUST be part of the timestamp.
Basically, syslog reuses a RFC3339 timestamp (see section 5.6 for it's ABNF)
but places some further restrictions on it. We do not force implementers to
use a single canonical on-the-wire format, but it is always easy to obtain a
canonical representation for correlation. As far as I remember, it was
considered useful to have some information inside the timestamp of where it
was generated.

> Then
> there is the "-00:00" offset being something much different than
> "+00:00".

When parsing the timestamp, the sign s is read and "+" interpreted as 1, "-"
as -1. Then, the offset o is parsed. The final offset calculation is o * s,
and as 0*1 = 0*-1 there is no difference between the two. A agree that a
slightly more complex logic is needed to adjust the time to UTC, but the same
is true if you have UTC timestamps only and need to adjust them to local
time, what often is desired by operators. So I fail to see why this is a
problem or not "canonical enough".

> And then there is the leap seconds stuff which is nearly
> untested as far as I can tell in most products.

I have to admit I don't understand this comment. What is untested here?
RFC5424 specifically forbids leap seconds, as during our discussions we found
many cases where leap seconds caused grief. I also think the the TAI is
considering aborting the use of leap seconds for this reason as well. To the
best of my knowledge, GSP also does not use leap seconds. The ultimate reason
to abandon UTC leap seconds in syslog was the we failed to identify an
operating system that would expose leap seconds to a user process. So a
syslogd or any other syslog sender would not even be able to see that one was
introduced. From the syslog perspective, a leap second is just like any other
second, but time flows "somewhat slower". I guess we are in the same boat as
many operating systems with this perspective.

> I really don't
> understand how one write a 5424 compliant syslog message that occurs
> during the leap second but I'
>  m probably just confused. What exactly does one do if one wants to
> write something to a log file when an extra leap second is being added?

I have to admit we didn't explicitely state that case because we thought it
could actually never happen. But I would say that "Leap seconds MUST NOT be
used" to me means that it should be expressed as the 59th second of said
minute. But even if you bump the minute and use the 0 second, I cannot see
how this should be problematic. On a single system, time should still evolve
serially. For correlating events form multiple systems, the timestamp alone
is insufficient in any case. You cannot closely enough synchronize the
different real time clocks. So you need a different meachanism (like Lamport
clocks) for this in any case.

> SIP is using the email style time formats and mandating GMT. That seems
> pretty trivially translatable 

indeed, this is trivial ;) If the sip timestamp is "2010-02-02
23:15:10.1234", you just need to replace the space by "T" and add an extra
"Z", so it becomes the valid syslog timestamp
"2010-02-02T23:15:10.1234Z". It is equally trivial to convert back ;)

Rainer