Hi, I agree that we cannot demand mechanisms for correct synchronization. We can provide a means to set the timezone, and recommend it be set automatically via NTP. Following the recommendations of draft-jones-opsec-03.txt, we should also allow an admin to set an object that contains the offset from UTC.
These are two objects that could be defined in the syslog mib. Since other protocols may also want to have such a capability, and a standard mib for time-sync could be done at some time, I recommend developing syslog objects for this, which other protocols could reuse of desired, but also design them such that they could rfelect the values set via other mechanisms, such as NTP. dbh > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 11, 2004 8:48 AM > To: Anton Okmianski; [EMAIL PROTECTED] > Subject: RE: RFC 3339 & UTC offset > > > Just noticed this in RFC 3339 (Section 4.4): > > > > "Systems that are configured with a local time, are unaware > > of the corresponding UTC offset, and depend on time > > synchronization with other Internet systems, MUST use a > > mechanism that ensures correct synchronization with UTC." > > > > Since -protocol is a distributed protocol where multiple > > hosts can generate syslog messages to one syslog server, one > > can say that syslog "depends on hosts synchronization with > > other Internet systems". Does this mean that syslog clients > > and servers MUST be aware of their UTC offset? Are we going > > to require this in -protocol? Besides, I don't think RFC > > 3339 specifies any designation for "unknown" offset, so what > > will such client provide? > > Actually, I think we can't ensure this. The real world is against us. > You are right, I should specify that a syslog sender MUST offer a way > learn its time zone, but I am very hesitant to demand time sync for > syslog. I guess everybody in this WG knows how important time sync is, > yet this is a real-life issue. Admin's don't use NTP, they don't > configure time zones and device clocks are often set to wild values. > > So I think we should demand the capability to set the time zone in any > syslog sender - but not go any further. > > > > > Anton. > > > > PS: BTW, just as an FYI, I searched rfc-editor.org web site > > and came across only one other RFC which uses RFC 3339 format > > (RFC3340). I think if we are worried about acceptability of > > -protocol, this could be yet another slight concern. I think > > RFC 3339 time stamp is unlike anything that is in wide use > > and people may have some initial reservations about it until > > it becomes more accepted. I like it, accept for "T" and "Z" > > characters. > > I, too, disliked this when I came across it the first time. > But when you > begin to actually develop applications, the "T" is a great, quick > shortcut to detect that it is actually an ISO date. > > > Unfortunately, ANSI and ISO standards are worse. > > I think this is the most important argument why I selected 3339 - I > don't like to invent yet another timestamp, the older > timestamps either > lack the year or the time zone or resolution or ... and the other > standards are worse. Plus, I like to stick refering to RFCs, because > these are available without purchasing (expensive) books [which also > means RFCs are instantly available when you need them...]. > > Rainer > > >
