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: <6BB0D094-0707-458D-B804-D172DA182EAF_at_noao.edu>
> Rob Seaman <seaman_at_noao.edu> 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 :-).
Received on Tue Feb 14 2006 - 14:25:04 PST