Rainer: > > "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.
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. We can't tell them to put "-00:00" or "+00:00" as this has special meaning in the RFC. I would say that UTC offset if a MUST, while time sync is a SHOULD. If offset is not a MUST, then we MUST specify what they put as offset to indicate it is unknown. Yaks. Crappy little rule? :) Anton.
