Michael Sokolov msokolov at ivan.Harhan.ORG
Thu Jan 5 00:04:58 EST 2012

mike cook <michael.cook at sfr.fr> wrote:

> I think an RFC for an NTP extension to support a rubbery time scale =

> will be required so that all who wish to keep something approaching UT1 =

> as civil time can do so.

But are you sure that NTP would be the right protocol? The first and
most immediate problem with NTP is that if the ITU bastards have their
way this month, NTP over the public Internet will immediately become
unreliable: some NTP servers will switch to the new ITU2012 timescale
(my preferred unambiguous term for what will be deceptively called
"UTC") while others will continue serving the existing UTC1972
timescale. As there would be no reliable way to tell which timescale
is served from UDP port 123 at a given public server's IP address, NTP
will cease to be a dependable protocol except when talking to servers
which you administer yourself.

So why bother with NTP at all then? The only reason in my mind to
support NTP on the rubber duckie (in addition to the new protocol on a
different UDP port specifically designed for disseminating UTR) is to
force-feed UTR to existing closed-source NTP-expecting devices such as
NAS (network-attached storage) appliances. These devices expect UTC
via NTP from UDP port 123 on a server whose IP address you configure,
but if you give it the IP address of a server you control yourself
which serves UTR instead of UTC in packets which look no different
from standard NTP, the target device will be forced to swallow it.


More information about the LEAPSECS mailing list