Take a sneak peek at the new NIST.gov and let us know what you think!
(Please note: some content may not be complete on the beta site.).

View the beta site
NIST logo
Bookmark and Share

Request for Information: Internet Time Service

Please Note: The Request for Information comment period closed 11:59 pm Eastern Daylight Time, May 27, 2014. Comments are no longer being accepted for public consideration.


The National Institute of Standards and Technology (NIST) published a Request for Information (RFI) to assist NIST in determining the best ways to structure possible private sector provision of the Internet Time Service (ITS).

Request for Information full text from the Federal Register.

The same Request for Information was also published on FedBizOps.gov.

Below are the comments received in response to the RFI. The comments are listed in chronological order of receipt. Comments are due on or before 11:59 pm Eastern Daylight Time on May 27, 2014.

Comment #1

I do not view myself as an expert on time services, but a researcher who is interested in the interface between how time is determined and how time is represented. My c.v. Is attached.

My general comment is based on my knowledge of the history of time services and of private enterprise. As you probably know, the first time services in the United States were provided by private contractors (Ian Bartky's work documents this) and railroads. The long-term viability of these enterprises was not great—many went bankrupt or were absorbed by other entities. If one looks at private enterprise in general, very few companies last a decade, even fewer for a century.

The dissemination of time is incredibly important to society, and its long-term stability and reliability must be protected. I do not think the private sector offers sufficient long-term stability and reliability to play the role of the first link between NIST time information and the public. I think that first link in the chain of time signal dissemination must remain in the hands of the government. For all the issues that one can point out with regards to the government, it is still here after 200+ years. What private enterprise in the country can one say that about? For that matter, how many companies are as old as the NIST/NBS?

Basically, when balancing claims of short-term cost savings versus long-term reliability and stability, I think that the long-term reliability must take priority. For instance, it is far more likely that the NIST will exist in some form for the rollovers of 32 bit and 64 bit systems in the 2030s than any contractor that could be hired. Heck, my bank and telephone carrier of 20 years ago no longer exist.

Kevin K. Birth, Professor
Department of Anthropology
Queens College, City University of New York

Comment #2

I read with interest your comment request on time service.

I note that the current time.nist.gov service appears to only support IP version 4.

This is probably obvious, but any roadmap for the service, whether NIST continues to operate it, or outsources it, must support IPv6.

Dan Pritts
ICPSR Computing & Network Services
University of Michigan

Comment #3

Thank you for giving Microsemi (formerly Symmetricom) an opportunity to respond to the "internet Time Service" RFI. Please see the attached document that provides a detailed response to the RFI. Kindly acknowledge the receipt of the RFI response from Microsemi, and let us know if you have further questions. We look forward to working with NIST on this very important initiative to provide an accurate and reliable time service to public in United States.

Best Regards

Ramki Ramakrishnan
Director Product Management & Business Development
Frequency & Time Division, Microsemi Corporation

NIST RFI Internet Time Service response.pdf

Comment #4

I am commenting on the NTP portion of RFI as an individual who has used ACTS-NTP extensively. I will refer to the NTP servers outside of Boulder & Ft Collins as remote sites. Presumably the Colorado servers will still be operated by NIST staff, though the RFI isn't clear on that point.

Today's ACTS-NTP service is led by NIST, but NIST staff have limited access to and control of many of the remote sites. Remote sites are important, but server hosting by volunteers has been erratic. As I type this note several remote sites are off-line with little indication if/when they will return to service. With adequate funding NIST themselves could provide consistent time service without relying on volunteers. Private sector operation is another option for improving service at remote sites.

Acceptable per-client NTP query rate limits for both should be specified by NIST. The private sector organizations should be prepared to block abusive users either manually or automatically.

RFC5905 obsoletes RFC1305.

After many years of service the role of ACTS requires reexamination. ACTS is unable to meet a 10 µsec accuracy requirement, but may play a role in less demanding applications. ACTS may still serve a function in the new system, providing a traceable backup time service that depends solely on PSTN connectivity.

The NIST NTP service will have open NTP access for non-authenticated users while authenticated service requires registration.

Will NIST or the private sector organizations be responsible for the client registration for authenticated services?

It would be cumbersome for authenticated users to deal with multiple provisioning systems. A goal should be that end users are unaware that the NTP servers are operated by both NIST and private sector operator(s).

NTP operation should include the following:

- IPv4 and IPv6 operation at all sites.

- Authenticated and non-authenticated operation at all sites.

- supply meaningful values for the mode 4 root delay. Typically the root delay for a stratum one server is zero, but depending on the time transfer mechanism other values may be appropriate.

- supply meaningful values for the mode 4 root dispersion. E.g., the root dispersion should slowly grow when the NTP server is operating from a backup local time source.

- Use of documented values for the reference ID that will distinguish high accuracy (10 µsec), local time reference (e.g., FLY), ACTS, etc.

- prepare for use of IP QoS to reduce network delay and jitter.

- Use of static NTP server IP addresses. Ideally the server addresses would never change, but this may not be feasible. In the rare cases where IP address changes are required 30 days notice should be given by the private sector operators. [There have been several unannounced ACTS IP address changes by remote sites.]

In addition to the help desk operation the status of all NTP servers should be available on a public web page similar to http://tf.nist.gov/tf-cgi/servers.cgi, but which is updated automatically in near-real time. Additionally a limited, documented set of NTP control messages should be available so that remote clients can query the status of individual servers in-band.

The use of server load balancers which hide multiple NTP servers behind one NTP IP address should be discouraged. There will be occasions when the multiple servers provide noticeably different responses.

FTP is a notoriously insecure protocol. Would it suffice to limit FTP service to the Colorado sites? Also, 1000 simultaneous FTP connections seems very high for information that changes infrequently.

Minimizing network delay is a required goal, not a consequence of geographic diversity.

Maintaining NTP server log files (e.g., loopstats, peerstats) is desirable.

All NIST NTP servers should be monitored by clients exercising the usual query/response mechanism. One possible implementation would place a monitoring client at each remote site. This client would regularly query the Boulder sites and all other remote sites.

Thanks for your attention.

Steven Sommars
Wheaton, IL

Comment #5

Submission by Packet Clearing House

We believe that separating the timekeeping expertise from the UDP service is a good idea, since the former is science and the latter is production engineering; both are serious and difficult areas, and nobody can expect to do a really first-rate job of both under the same roof. The UDP portion of these services is essentially an identical problem to the UDP portion of domain name system (DNS) data distribution, and back-end synchronization with a canonical source is a well-understood matter.

Packet Clearing House
San Francisco, CA