In message <[EMAIL PROTECTED]>, "christopher hoover" writes: >Poul-Henning Kamp wrote: >> So yes, you have outlined a possible technical fix, but that is not >> the problem that is hard to solve, the one you need to solve first >> is "who is going to pay, and how do we make them ?" > >One way would to get the spec written into a major US gov't procurement bid >as a requirement.
Yes, that will give you a proof of concept implementation. And then what ? First somebody has to convince Microsoft that they have to support this technical infrastructure. The best you can hope for is a buggy version in Windows 2008 which arrives in 2010. Then around 2012 it might sort of work. Open source OS's will be ready before that if IPv6 and similar is any indication. Then you need to convince _everybody_, including the German government, NASA, your local water-utility, the radiologist at your favourite hospital, SSBN owning defenses, the CIA and _everybody_ else to do the necessary system updates and upgrades. Lets be optimistic and say that it's going to happen the time after next time they buy new kit, because the 3rd party vendors need to get their things working first. So, realistically, we might be able to have a technical fix implemented around 2050 -- 2040 at best. You have to remember, this is far more subtle *and* intrusive than just the IPv4/IPv6 thing, which so far has taken 15 years to get absolutely no where (see RFC 1287, which has about the same level of detail as the proposal Steve just published). And also remember: IPv6 has had the "we'll run out of IPv4 addresses" sword hanging over peoples head all along, we have no similar fulcrum issue for leap seconds. Compare this with "lets just forget about leapseconds" which will give us some astronomers complaining about their instruments and computers and potential problems that might happen 200 years from now, but which also means "we don't have to muck about with all the computers". How do you propose to sell against that ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
