First, to review, as I noted on this list just over a month ago, there is an IETF NTP working group now, working on version 4:
http://www.ietf.org/html.charters/ntp-charter.html NIST has a leap seconds table: ftp://time.nist.gov/pub/leap-seconds.list Current xntpd code can use that table, and transport leap second tables around using an "autokey" feature: http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/db2f5f47aab68a3d/ There was some discussion of leap seconds at the NTP working group session of the Internet Engineering Task Force (IETF) meeting in Vancouver in September: http://www3.ietf.org/proceedings/05nov/ntp.html It is unclear whether the current "autokey" security mechanism will end up in an IETF standard, since it is rather different from other standard internet security mechanisms. On Tue, Feb 14, 2006 at 02:28:34PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Rob Seaman <[EMAIL PROTECTED]> writes: > : On Feb 14, 2006, at 12:50 PM, Markus Kuhn wrote: > : > : > You can, of course, define, publish, implement, and promote a new > : > version (4?) of NTP that can also diseminate TAI, EOPs, leap-second > : > tables, and other good things. I'm all for it. > : > : But why are you for it? Before investing large amounts of time and > : money in developing and deploying a large new timekeeping system, > : wouldn't one want to invest smaller amounts in exploring the issues > : and options? Heck - one has to imagine that a number of successful > : grant applications are lurking around here somewhere. Time is an > : issue that cuts across every funding agency out there. > > UTC time stamps in NTP are ambiguous. TAI ones are not. UTC time > stamps do not convey enough information to properly implement things > like intervals, while TAI ones do. The NTPNG stuff that I've seen > appears to consider these problems as worthy of needing a solution and > they plan on solving them. It isn't rocket science, but one has to > divorce ones self from the chauvinistic view that UTC is always best. > For time exchange, it is not the best, and has many problems around > the edges. Yes it is messy, but the tradeoffs are complex. I don't think the latest drafts specify NTP timestamps. I suspect they still rely on the leap second bit to disambiguate the timestamp on a leap second, but I haven't checked recently. They are all linked to from the charter page I noted above. > Doing NTP with TAI (and the implied requirement for DTAI) doesn't > change what time is displayed for users. It does make it *MUCH* > easier to get leap seconds right for those users that need them. > Anything else is madness. UTC is a display convention, not a sane[*] > counting convention. I think that changing to a different over-the-wire timestamp epoch would just add to the confusion, not make things simpler in practice. People still need to know UTC, and transmitting the leap second table info, especially via autokey, is much more complex than the basic protocol. But at least this is a standards process conducted in the open, where you can just get involved directly if you have something to add. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 > Warner > > [*] All variable radix counting conventions are insane by (my humble) > definition :-).
