Hi! I will reply to various emails in one.
> 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. Application can know if NTP is configured. Or administrator can set it. In fact, Cisco devices follow a similar convention in logging (including through syslog). I am not advocating doing anything just because Cisco does it and I work there :), but it just shows that some vendors find some convention for time sync indication useful. Cisco devices prefix the timestamp with "*" or "." when they know that time is not authoritative, i.e. NTP is not setup or is not working properly (i.e network connection lost). NTP can be integrated into whatever application I think. I like the general idea of some indication since we can't require time synchronization AND what's important won't always be possible. What if you want to report an NTP client error? > From: Devin Kowatch ... > I guess the biggest problem I have with > this is that if the "reliable time info" flag is not reliable > then what's the point? Well, what part of syslog is reliable? Security is a different issue IMO. Sure people can lie, but that does not mean we should not give good admins a useful option to simplify their administration of a large farm of servers. How people decide to use or not use this indication will be different in different deployments I think. So, I'd go for something that does not take to much space. > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] ... > 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. I just don't like "punishing" the good client which has synchronized time by making it send more data in a structured element. I think the overhead, if any should be on the clients which don't know if time is authoritative. IMO we should assume that people should setup time sync in most cases. > -----Original Message----- > From: Devin Kowatch > Sent: Thursday, February 12, 2004 12:39 PM ... > If you are dead set on having some indication of time > correctness, try adding a timestamp for each relay that the > message passes through (and the final server, but that is a > file format issue), I like this idea, but I don't think it solves the problem. Time of origination is what is used to establish message order for one and multiple hosts. Time of reception can be different including order. I think time of reception is a good thing to keep (for cases where origin time is unreliable), and I think it would be nice if first relay could add this information (but not overwrite original data). Maybe add a structured element? BTW, is relay prohibited from adding information to the message? I also talked about source IP as potentially another thing you may want relay to add. >or use RFC3195 with SYSLOG/COOKED and > path elements. But what about UDP transport? ---------- We jumped to time synchronization issue (which is fine), while my original issue got forgotten. I was actually raising the issue of UTC offset. Some systems may know their time, but have no idea about their offset from UTC. What should they put as UTC offset value in the timestamp? Random value? I think this is an issue we have to address even if we provide for some flag that is incorrect. I propose that they put "-----" instead of an offset or we come up with another suffix like "U" for unknown. ---------- Still on the same subject of timestamps, but yet another issue. Do we want to come up with some timestamp format that devices can put when they don't know their time? For example: --------T-----------Z? It seems we have scoped it out, but it is a problem. Cisco has a number of devices that maybe unaware of their clock. Cisco currently sends messages with uptime (like 8d5h3m) instead of timestamp when this is the case. If Cisco where to adopt -protocol, they will need to deal with this one way or the other. How? Unless -protocol specifies this, they will have to invent something, then Nortel will invent something, Juniper, etc... Not good. I am not speaking for Cisco, but from experience of trying to standardize logging within Cisco. When I tried to scope out devices that have no knowledge of time, I got a pushback & we had to add support for unknown date/time. I think "uptime" can be left out of scope and be a vendor structured parameter for now. Thanks, Anton.
