National Institute of Standards and Technology Internet Time Services, 16772-16774 [2014-06683]
Download as PDF
<![CDATA[
16772
Federal Register / Vol. 79, No. 58 / Wednesday, March 26, 2014 / Notices
sroberts on DSK5SPTVN1PROD with NOTICES
of the antidumping duty orders on ball
bearings and parts thereof from Japan
and the United Kingdom pursuant to
section 751(c) of the Tariff Act of 1930,
as amended (the Act).3 We received no
notice of intent to participate in
response to the Initiation Notice from
domestic interested parties by the
applicable deadline.4 As a result, the
Department has concluded that no
domestic party intends to participate in
these sunset reviews.5 On January 22,
2014, we notified the International
Trade Commission, in writing, that we
intend to revoke the antidumping duty
orders on ball bearings and parts thereof
from Japan and the United Kingdom.6
Scope of the Orders
The products covered by the orders
are ball bearings and parts thereof.
These products include all antifriction
bearings that employ balls as the rolling
element. Imports of these products are
classified under the following
categories: Antifriction balls, ball
bearings with integral shafts, ball
bearings (including radial ball bearings)
and parts thereof, and housed or
mounted ball bearing units and parts
thereof.
Imports of these products are
classified under the following
Harmonized Tariff Schedule of the
United States (HTSUS) subheadings:
3926.90.45, 4016.93.10, 4016.93.50,
6909.19.50.10, 8414.90.41.75,
8431.20.00, 8431.39.00.10, 8482.10.10,
8482.10.50, 8482.80.00, 8482.91.00,
8482.99.05, 8482.99.35, 8482.99.25.80,
8482.99.65.95, 8483.20.40, 8483.20.80,
8483.30.40.00, 8483.50.90, 8483.90.20,
8483.90.30, 8483.90.70, 8708.50.50,
8708.60.50, 8708.60.80, 8708.93.30,
8708.93.60.00, 8708.99.06,
8708.99.31.00, 8708.99.41.00,
8708.99.49.60, 8708.99.58,
8708.99.80.80, 8803.10.00, 8803.20.00,
8803.30.00, 8803.90.30, 8803.90.90,
8708.30.50.90, 8708.40.75.70,
8708.40.75.80, 8708.50.51, 8708.50.61,
8708.50.79.00, 8708.50.89.00,
8708.50.91.50, 8708.50.99.00,
8708.70.60.60, 8708.80.65.90,
8708.93.75.00, 8708.94.75,
8708.95.20.00, 8708.99.55.00,
8708.99.68, and 8708.99.81.80.
Although the HTSUS item numbers
above are provided for convenience and
customs purposes, the written
descriptions of the scope of the orders
remain dispositive.
The size or precision grade of a
bearing does not influence whether the
3 See
Initiation Notice.
4 See 19 CFR 351.218(d)(1)(i).
5 See 19 CFR 351.218(d)(1)(iii)(A).
6 See 19 CFR 351.218(d)(1)(iii)(B)(2).
VerDate Mar<15>2010
17:43 Mar 25, 2014
Jkt 232001
bearing is covered by one of the orders.
The orders cover all the subject bearings
and parts thereof (inner race, outer race,
cage, rollers, balls, seals, shields, etc.)
outlined above with certain limitations.
With regard to finished parts, all such
parts are included in the scope of the
orders. For unfinished parts, such parts
are included if they have been heattreated or if heat treatment is not
required to be performed on the part.
Thus, the only unfinished parts that are
not covered by the orders are those that
will be subject to heat treatment after
importation. The ultimate application of
a bearing also does not influence
whether the bearing is covered by the
orders. Bearings designed for highly
specialized applications are not
excluded. Any of the subject bearings,
regardless of whether they may
ultimately be utilized in aircraft,
automobiles, or other equipment, are
within the scope of the orders.
Revocation
Pursuant to section 751(c)(3)(A) of the
Act and 19 CFR 351.218(d)(1)(iii)(B)(3),
if no domestic interested party files a
notice of intent to participate, the
Department shall issue a final
determination revoking the order within
90 days of the initiation of the review.
Because no domestic interested party
filed a timely notice of intent to
participate in these sunset reviews, the
Department finds that no domestic
interested party is participating in these
sunset reviews. Therefore, we are
revoking the antidumping duty orders
on ball bearings and parts thereof from
Japan and the United Kingdom. The
effective date of revocation is September
15, 2011, the fifth anniversary of the
most recent notice of continuation of the
antidumping duty orders.7
Pursuant to section 751(c)(3)(A) of the
Act and 19 CFR 351.222(i)(2)(i), the
Department intends to issue instructions
to U.S. Customs and Border Protection
(CBP) to terminate the suspension of
liquidation of entries of the
merchandise subject to the orders which
were entered, or withdrawn from
warehouse, for consumption on or after
September 15, 2011. Entries of subject
merchandise prior to September, 15,
2011, will continue to be subject to the
suspension of liquidation and
requirements for deposits of estimated
antidumping duties. The Department
will conduct administrative reviews of
the orders with respect to subject
7 See Tapered Roller Bearings and Parts Thereof
from the People’s Republic of China and Ball
Bearings and Parts Thereof from France, Germany,
Italy, Japan, and the United Kingdom: Continuation
of Antidumping Duty Orders, 71 FR 54469
(September 15, 2006).
PO 00000
Frm 00019
Fmt 4703
Sfmt 4703
merchandise entered prior to the
effective date of revocation in response
to appropriately filed requests for
review.
These final results of the five-year
(sunset) reviews and notice are
published in accordance with sections
751(c) and 777(i)(1) of the Act.
Dated: March 20, 2014.
Paul Piquado,
Assistant Secretary for Enforcement and
Compliance.
[FR Doc. 2014–06702 Filed 3–25–14; 8:45 am]
BILLING CODE 3510–DS–P
DEPARTMENT OF COMMERCE
National Institute of Standards and
Technology
[Docket No.: 140305197–4197–01]
National Institute of Standards and
Technology Internet Time Services
National Institute of Standards
and Technology (NIST), Department of
Commerce.
ACTION: Request for information.
AGENCY:
The National Institute of
Standards and Technology (NIST) seeks
information from the public on NIST’s
potential transition of time services
from a NIST-only service to private
sector operation of an ensemble of time
servers that will provide NIST-traceable
time information in a number of
different formats over the public
Internet.
SUMMARY:
Comments are due on or before
11:59 p.m. Eastern Time on May 27,
2014.
DATES:
Comments will be accepted
by email only. Comments must be sent
to thomas.obrian@nist.gov with the
subject line ‘‘Internet Time Service
Comments.’’
Comments submitted after the due
date may not be considered.
All comments will be made publicly
available on https://tf.nist.gov as
submitted. Accordingly, proprietary or
confidential information should not be
included in any comments, as they will
be posted without change.
FOR FURTHER INFORMATION CONTACT:
Thomas O’Brian; 303–497–4570;
thomas.obrian@nist.gov.
SUPPLEMENTARY INFORMATION:
Pursuant to 15 U.S.C. 261(b), the
Secretary of Commerce, in coordination
with the Secretary of the Navy, is
responsible for maintaining and
interpreting Coordinated Universal
Time (UTC) as official time for the
United States. UTC is the time scale
ADDRESSES:
E:\FR\FM\26MRN1.SGM
26MRN1
sroberts on DSK5SPTVN1PROD with NOTICES
Federal Register / Vol. 79, No. 58 / Wednesday, March 26, 2014 / Notices
maintained through the General
Conference on Weights and Measures.
The Secretary of Commerce has
delegated authority for maintaining and
interpreting UTC to the Director of the
NIST. The NIST version of UTC is
designated as UTC(NIST).
To facilitate broad access to
UTC(NIST), the Time and Frequency
Division of the NIST Physical
Measurement Laboratory currently
operates an ensemble of time servers,
which are located at a number of sites
in the continental U.S. (A list of the
current locations is on the Internet Time
Service page at https://tf.nist.gov/tf-cgi/
servers.cgi.) The servers are connected
to the public Internet and respond to
requests for time in three formats:
Network Time Protocol (NTP), the
DAYTIME format and the TIME format.
The generally accepted voluntary
standards, containing detailed
descriptions, for these three time
formats is set forth in a series of Request
for Comment (RFC) documents from the
Internet Engineering Task Force (IETF).
These RFCs can be accessed through the
IETF Web site: https://www.rfceditor.org/rfc-index.html:
NTP format: RFC 1305 https://www.rfceditor.org/rfc/rfc1305.txt.
DAYTIME format: RFC 867 https://
www.rfc-editor.org/rfc/rfc867.txt.
TIME format: RFC 868 https://www.rfceditor.org/rfc/rfc868.txt.
Higher level summaries of these time
formats are available at the NIST
Internet Time Service Web site: https://
www.nist.gov/pml/div688/grp40/its.cfm.
The servers are synchronized to UTC
as maintained by an ensemble of atomic
clocks at the NIST Boulder Laboratories.
This time is generally referred to as
UTC(NIST) to distinguish it from UTC,
a paper time scale computed
periodically by the International Bureau
of Weights and Measures (the BIPM).
The UTC(NIST) time scale is steered
towards UTC using occasional
adjustments in frequency, and the
difference is typically on the order of a
few nanoseconds.
The ensemble also includes three time
servers that are synchronized to
UTC(NIST) and that support only the
authenticated version of NTP using the
symmetric-key method and the Message
Digest 5 (MD5) hash algorithm. The
authenticated service is limited to users
who register with NIST and receive a
unique key that is linked to their
network address. The key is used to
authenticate the time packets from NIST
by means of the MD5 hash method as
described in the RFC documents
referenced above.
The servers also support anonymous
read-only connections that use the File
VerDate Mar<15>2010
17:43 Mar 25, 2014
Jkt 232001
Transfer Protocol (FTP), which allow
users to download example software,
‘‘read me’’ files and similar documents.
The FTP service also allows users to
download a list of leap seconds,
including future leap seconds that have
been announced but have not yet
occurred.
The ensemble of servers receives
approximately 6.5 billion time requests
per day, or about 75,000 requests per
second. Approximately 85% of these
requests are for time in the NTP format,
and the balance are about equally
divided between the DAYTIME and
TIME formats. The number of
simultaneous FTP connections is not
closely monitored, but, based on
occasional random sampling, there are
approximately 1000 simultaneous FTP
connections at any time.
NIST is considering transitioning the
provision of its time services from a
NIST-only service to private sector
operation of an ensemble of time servers
that will provide NIST-traceable time
information to improve provision of
these services, and hereby requests
information on how best to realize this
transition so as to assure the continued
integrity, availability, and accuracy of
the time messages. NIST views the
transition as a means of broadening the
availability of the NIST time-scale data
and fostering the creation of new time
services and layered products that could
make use of that data. At the same time,
NIST seeks to ensure that the time
messages provided by the servers are as
accurate as possible, consistent with the
technical limitations of the public
Internet. This requirement is especially
important for current (and prospective)
financial and commercial users of the
service, many of whom are legally
required to ensure that the time stamps
that they use in their data centers are
traceable to the national standard time
as maintained at NIST. NIST will work
with private sector operator(s) to ensure
that these legal traceability requirements
are satisfied.
The goals of the time service are:
a. Respond to requests for time in a
number of network-standard formats.
The accuracy of the time at the server
should be significantly better than 0.01
millisecond (0.00001 s), to support both
current applications and enable nearterm future enhancements. A number of
existing users of the NIST services have
already expressed the need for time data
with an accuracy approaching 1
microsecond, and the system should be
designed to provide this level of service
in the future without significant
modification. The accuracy received by
a user depends on the stability of the
network delay and is usually not under
PO 00000
Frm 00020
Fmt 4703
Sfmt 4703
16773
the control of the server. However,
improvements in the stability of the
network delays are already available in
principle, and it is likely that these
improvements will enable support for
greater accuracy of the time service in
the not too distant future, possibly using
formats that are not currently supported
by the NIST service.
b. Provide geographical diversity in
the location of the time servers. This
goal seeks to minimize the impact of a
single network failure or the failure of
the hardware at any site. In addition,
geographical diversity generally
provides better accuracy by reducing the
network delay for a larger number of
users.
c. Provide a local reference time scale
at each server that can support the full
accuracy of the time service for a
minimum of 180 days, even if the link
to the NIST time scale is lost. The local
reference scale should have redundant
components and be designed with no
single point of failure. This ‘‘hold-over’’
capability is particularly important if
the links between the servers and NIST
are realized by means of signals from
satellites such as the signals from the
Global Positioning System, even if the
signals are used in common-view. (The
common-view method, in which several
stations receive the signals from the
same satellite at the same time, reduces,
but does not eliminate the sensitivity of
the synchronization process to errors in
the data and time signals transmitted by
the satellites.) The signals from
navigation satellites are increasingly
degraded by jamming and spoofing, and
these problems are becoming more
common, so that a simple reliance on
these signals (without a local very stable
reference clock) is not adequately robust
for a national time service.
d. Provide links between each server
location and the NIST atomic clock
ensemble that supports the accuracy of
the time service as outlined in
paragraph a., and is as robust as
possible. The accuracy of the link and
the accuracy of the local time reference
discussed in the previous paragraph
will probably be designed together, with
the result that the combination is more
robust than either component alone
would be.
e. Provide network bandwidth and
connectivity that can support the
current number of requests with a
significant margin for future growth.
The messages used to exchange timing
information are small—100 octets or
less—but there are a large number of
them, so that the load on the network
elements, which typically must process
every request independent of its size, is
larger than a simple estimate based on
E:\FR\FM\26MRN1.SGM
26MRN1
sroberts on DSK5SPTVN1PROD with NOTICES
16774
Federal Register / Vol. 79, No. 58 / Wednesday, March 26, 2014 / Notices
the number of octets in each request
multiplied by the number of requests. In
addition, the accuracy and stability of
the time service depends on (and is
usually limited by) the stability of the
network delay, and this delay tends to
become less stable and predictable once
the message traffic becomes a significant
fraction of the bandwidth of the
hardware.
f. Provide adequate physical security,
environmental controls, backup power,
and related service consistent with the
critical contribution of the time servers
to the national infrastructure.
g. The time servers do not contain or
transmit any confidential information.
There is no Personally Identifiable
Information (PII) associated with the
services, and both the time messages
themselves and the files that are
provided for download are freely
available and are based on principles
and practices that have been widely
disseminated. The requirements of
paragraph f. are intended only to
prevent alteration or destruction of the
data.
h. The system should provide
adequate internal and external
monitoring to ensure the integrity of the
time messages. Both the NTP and the
DAYTIME format should include bits
that specify the health of the server, and
these bits should be used to indicate
that the time transmitted in the message
was transmitted from a server whose
time accuracy was known to be
incorrect or when the accuracy could
not be established. These bits should be
set if an internal or external monitoring
program detects a problem and not reset
until the normal state is restored.
Conversely, when the bits of the
message are not set, this shall indicate
that the server is operating normally
based on a combination of internal and
external checks. (Some implementations
of the NTP do not use this capability
and push the detection of a failed server
into the application software running on
the client system. This method is not
adequate and is not acceptable for a
service traceable to a national timing
laboratory.) The NTP and DAYTIME
formats also have parameters in the
message that can be used to indicate
that the server is operating at reduced
accuracy. Depending on these
parameters as the sole means for
indicating the health of the service is
discouraged, since they are usually
based on statistical estimators that may
or may not be an accurate description of
the true state of affairs. The terms of
service between NIST and any future
service provider shall clearly specify
that any implication of accuracy or
traceability to national standards is
VerDate Mar<15>2010
17:43 Mar 25, 2014
Jkt 232001
suspended when any of these indicators
is set. The TIME format does not have
any way of transmitting the health of the
server, and the server shall not respond
to a request for time in this format if it
is known or suspected of being
unhealthy.
i. The time servers shall transmit time
signals based on UTC(NIST) and shall
support insertion of leap seconds as
defined and implemented by the
International Telecommunications
Union (ITU), the International Earth
Rotation Service (IERS), and the
International Bureau of Weights and
Measures (BIPM).
j. In addition to implementing leap
seconds in the time messages as
described in paragraph i., the servers
shall provide advance notice of leap
seconds as specified in the
documentation for the NTP and
DAYTIME formats.
k. The time service is currently used
by many users who are not expert in
time and frequency principles or in the
design of the network services that are
used to communicate between the
server and the hardware of the end-user.
Therefore, the operator(s) should
support a ‘‘help desk’’ facility to assist
users who are having difficulty in using
the services.
Request For Information: The
objective of this request for information
is to assist NIST in determining the best
ways to structure possible private sector
provision of Internet Time Service.
Based on the information provided,
NIST may or may not issue a request for
proposals or other announcement of an
opportunity for such private sector
provision of Internet Time Service. In
this connection, the questions below are
intended to assist in the formulation of
comments and should not be construed
as a limitation on the number of
comments that interested persons may
submit or as a limitation on the issues
that may be addressed in such
comments. Comments containing
references, studies, research, and other
empirical data that are not widely
published should include copies of the
referenced materials. Again, note that all
comments will be made publicly
available as submitted; therefore
proprietary or confidential information
should not be included. NIST is
specifically interested in receiving input
pertaining to one or more of the
following questions:
1. What diversity of the geographical
locations of the servers will provide the
best balance between cost and accuracy
consistent with the requirements
outlined above?
2. How should the sites be configured
to provide the integrity, reliability, and
PO 00000
Frm 00021
Fmt 4703
Sfmt 9990
accuracy that are required as part of a
time service that must support the
national infrastructure?
3. How should the monitoring and
supervisory functions be configured to
ensure that the time signals are accurate
and that any failure be detected? In
addition, how should logging functions
be implemented so that the log files can
be used in the case that the accuracy of
the time signals become involved in a
legal proceeding?
4. How should the link to the NIST
atomic time scale be realized? What is
the appropriate relationship between
NIST and time service provider(s)? How
should this relationship be designed to
preserve the requirements of legal and
technical traceability of the time stamps
to national time standards?
5. What are ways in which the
relationship between the private
operator(s) and NIST can best be
realized? A formal agreement will be
established between NIST and each
private operator, and NIST seeks input
on what type of agreement would best
support the program.
6. Should NIST hold a competition to
select a private sector organization(s) to
operate an ensemble of time servers to
provide NIST-traceable time
information, or should NIST make the
opportunity available to all eligible
parties?
7. What are advantages and
disadvantages of NIST’s potential
transition of time services from a NISTonly service to private sector operation
of an ensemble of time servers that will
provide NIST-traceable time
information via the Internet? Note that
NIST would continue to provide
oversight of the accuracy and integrity
of the Internet-based time services, and
that the transition would not affect the
traceability of the distributed time
signals to national and international
standards.
8. What other considerations should
be important in the design of the time
services?
Dated: March 20, 2014.
Willie E. May,
Associate Director for Laboratory Programs.
[FR Doc. 2014–06683 Filed 3–25–14; 8:45 am]
BILLING CODE 3510–13–P
E:\FR\FM\26MRN1.SGM
26MRN1
]]>Agencies
[Federal Register Volume 79, Number 58 (Wednesday, March 26, 2014)]
[Notices]
[Pages 16772-16774]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2014-06683]
-----------------------------------------------------------------------
DEPARTMENT OF COMMERCE
National Institute of Standards and Technology
[Docket No.: 140305197-4197-01]
National Institute of Standards and Technology Internet Time
Services
AGENCY: National Institute of Standards and Technology (NIST),
Department of Commerce.
ACTION: Request for information.
-----------------------------------------------------------------------
SUMMARY: The National Institute of Standards and Technology (NIST)
seeks information from the public on NIST's potential transition of
time services from a NIST-only service to private sector operation of
an ensemble of time servers that will provide NIST-traceable time
information in a number of different formats over the public Internet.
DATES: Comments are due on or before 11:59 p.m. Eastern Time on May 27,
2014.
ADDRESSES: Comments will be accepted by email only. Comments must be
sent to thomas.obrian@nist.gov with the subject line ``Internet Time
Service Comments.''
Comments submitted after the due date may not be considered.
All comments will be made publicly available on https://tf.nist.gov
as submitted. Accordingly, proprietary or confidential information
should not be included in any comments, as they will be posted without
change.
FOR FURTHER INFORMATION CONTACT: Thomas O'Brian; 303-497-4570;
thomas.obrian@nist.gov.
SUPPLEMENTARY INFORMATION:
Pursuant to 15 U.S.C. 261(b), the Secretary of Commerce, in
coordination with the Secretary of the Navy, is responsible for
maintaining and interpreting Coordinated Universal Time (UTC) as
official time for the United States. UTC is the time scale
[[Page 16773]]
maintained through the General Conference on Weights and Measures. The
Secretary of Commerce has delegated authority for maintaining and
interpreting UTC to the Director of the NIST. The NIST version of UTC
is designated as UTC(NIST).
To facilitate broad access to UTC(NIST), the Time and Frequency
Division of the NIST Physical Measurement Laboratory currently operates
an ensemble of time servers, which are located at a number of sites in
the continental U.S. (A list of the current locations is on the
Internet Time Service page at https://tf.nist.gov/tf-cgi/servers.cgi.)
The servers are connected to the public Internet and respond to
requests for time in three formats: Network Time Protocol (NTP), the
DAYTIME format and the TIME format.
The generally accepted voluntary standards, containing detailed
descriptions, for these three time formats is set forth in a series of
Request for Comment (RFC) documents from the Internet Engineering Task
Force (IETF). These RFCs can be accessed through the IETF Web site:
https://www.rfc-editor.org/rfc-index.html:
NTP format: RFC 1305 https://www.rfc-editor.org/rfc/rfc1305.txt.
DAYTIME format: RFC 867 https://www.rfc-editor.org/rfc/rfc867.txt.
TIME format: RFC 868 https://www.rfc-editor.org/rfc/rfc868.txt.
Higher level summaries of these time formats are available at the
NIST Internet Time Service Web site: https://www.nist.gov/pml/div688/grp40/its.cfm.
The servers are synchronized to UTC as maintained by an ensemble of
atomic clocks at the NIST Boulder Laboratories. This time is generally
referred to as UTC(NIST) to distinguish it from UTC, a paper time scale
computed periodically by the International Bureau of Weights and
Measures (the BIPM). The UTC(NIST) time scale is steered towards UTC
using occasional adjustments in frequency, and the difference is
typically on the order of a few nanoseconds.
The ensemble also includes three time servers that are synchronized
to UTC(NIST) and that support only the authenticated version of NTP
using the symmetric-key method and the Message Digest 5 (MD5) hash
algorithm. The authenticated service is limited to users who register
with NIST and receive a unique key that is linked to their network
address. The key is used to authenticate the time packets from NIST by
means of the MD5 hash method as described in the RFC documents
referenced above.
The servers also support anonymous read-only connections that use
the File Transfer Protocol (FTP), which allow users to download example
software, ``read me'' files and similar documents. The FTP service also
allows users to download a list of leap seconds, including future leap
seconds that have been announced but have not yet occurred.
The ensemble of servers receives approximately 6.5 billion time
requests per day, or about 75,000 requests per second. Approximately
85% of these requests are for time in the NTP format, and the balance
are about equally divided between the DAYTIME and TIME formats. The
number of simultaneous FTP connections is not closely monitored, but,
based on occasional random sampling, there are approximately 1000
simultaneous FTP connections at any time.
NIST is considering transitioning the provision of its time
services from a NIST-only service to private sector operation of an
ensemble of time servers that will provide NIST-traceable time
information to improve provision of these services, and hereby requests
information on how best to realize this transition so as to assure the
continued integrity, availability, and accuracy of the time messages.
NIST views the transition as a means of broadening the availability of
the NIST time-scale data and fostering the creation of new time
services and layered products that could make use of that data. At the
same time, NIST seeks to ensure that the time messages provided by the
servers are as accurate as possible, consistent with the technical
limitations of the public Internet. This requirement is especially
important for current (and prospective) financial and commercial users
of the service, many of whom are legally required to ensure that the
time stamps that they use in their data centers are traceable to the
national standard time as maintained at NIST. NIST will work with
private sector operator(s) to ensure that these legal traceability
requirements are satisfied.
The goals of the time service are:
a. Respond to requests for time in a number of network-standard
formats. The accuracy of the time at the server should be significantly
better than 0.01 millisecond (0.00001 s), to support both current
applications and enable near-term future enhancements. A number of
existing users of the NIST services have already expressed the need for
time data with an accuracy approaching 1 microsecond, and the system
should be designed to provide this level of service in the future
without significant modification. The accuracy received by a user
depends on the stability of the network delay and is usually not under
the control of the server. However, improvements in the stability of
the network delays are already available in principle, and it is likely
that these improvements will enable support for greater accuracy of the
time service in the not too distant future, possibly using formats that
are not currently supported by the NIST service.
b. Provide geographical diversity in the location of the time
servers. This goal seeks to minimize the impact of a single network
failure or the failure of the hardware at any site. In addition,
geographical diversity generally provides better accuracy by reducing
the network delay for a larger number of users.
c. Provide a local reference time scale at each server that can
support the full accuracy of the time service for a minimum of 180
days, even if the link to the NIST time scale is lost. The local
reference scale should have redundant components and be designed with
no single point of failure. This ``hold-over'' capability is
particularly important if the links between the servers and NIST are
realized by means of signals from satellites such as the signals from
the Global Positioning System, even if the signals are used in common-
view. (The common-view method, in which several stations receive the
signals from the same satellite at the same time, reduces, but does not
eliminate the sensitivity of the synchronization process to errors in
the data and time signals transmitted by the satellites.) The signals
from navigation satellites are increasingly degraded by jamming and
spoofing, and these problems are becoming more common, so that a simple
reliance on these signals (without a local very stable reference clock)
is not adequately robust for a national time service.
d. Provide links between each server location and the NIST atomic
clock ensemble that supports the accuracy of the time service as
outlined in paragraph a., and is as robust as possible. The accuracy of
the link and the accuracy of the local time reference discussed in the
previous paragraph will probably be designed together, with the result
that the combination is more robust than either component alone would
be.
e. Provide network bandwidth and connectivity that can support the
current number of requests with a significant margin for future growth.
The messages used to exchange timing information are small--100 octets
or less--but there are a large number of them, so that the load on the
network elements, which typically must process every request
independent of its size, is larger than a simple estimate based on
[[Page 16774]]
the number of octets in each request multiplied by the number of
requests. In addition, the accuracy and stability of the time service
depends on (and is usually limited by) the stability of the network
delay, and this delay tends to become less stable and predictable once
the message traffic becomes a significant fraction of the bandwidth of
the hardware.
f. Provide adequate physical security, environmental controls,
backup power, and related service consistent with the critical
contribution of the time servers to the national infrastructure.
g. The time servers do not contain or transmit any confidential
information. There is no Personally Identifiable Information (PII)
associated with the services, and both the time messages themselves and
the files that are provided for download are freely available and are
based on principles and practices that have been widely disseminated.
The requirements of paragraph f. are intended only to prevent
alteration or destruction of the data.
h. The system should provide adequate internal and external
monitoring to ensure the integrity of the time messages. Both the NTP
and the DAYTIME format should include bits that specify the health of
the server, and these bits should be used to indicate that the time
transmitted in the message was transmitted from a server whose time
accuracy was known to be incorrect or when the accuracy could not be
established. These bits should be set if an internal or external
monitoring program detects a problem and not reset until the normal
state is restored. Conversely, when the bits of the message are not
set, this shall indicate that the server is operating normally based on
a combination of internal and external checks. (Some implementations of
the NTP do not use this capability and push the detection of a failed
server into the application software running on the client system. This
method is not adequate and is not acceptable for a service traceable to
a national timing laboratory.) The NTP and DAYTIME formats also have
parameters in the message that can be used to indicate that the server
is operating at reduced accuracy. Depending on these parameters as the
sole means for indicating the health of the service is discouraged,
since they are usually based on statistical estimators that may or may
not be an accurate description of the true state of affairs. The terms
of service between NIST and any future service provider shall clearly
specify that any implication of accuracy or traceability to national
standards is suspended when any of these indicators is set. The TIME
format does not have any way of transmitting the health of the server,
and the server shall not respond to a request for time in this format
if it is known or suspected of being unhealthy.
i. The time servers shall transmit time signals based on UTC(NIST)
and shall support insertion of leap seconds as defined and implemented
by the International Telecommunications Union (ITU), the International
Earth Rotation Service (IERS), and the International Bureau of Weights
and Measures (BIPM).
j. In addition to implementing leap seconds in the time messages as
described in paragraph i., the servers shall provide advance notice of
leap seconds as specified in the documentation for the NTP and DAYTIME
formats.
k. The time service is currently used by many users who are not
expert in time and frequency principles or in the design of the network
services that are used to communicate between the server and the
hardware of the end-user. Therefore, the operator(s) should support a
``help desk'' facility to assist users who are having difficulty in
using the services.
Request For Information: The objective of this request for
information is to assist NIST in determining the best ways to structure
possible private sector provision of Internet Time Service. Based on
the information provided, NIST may or may not issue a request for
proposals or other announcement of an opportunity for such private
sector provision of Internet Time Service. In this connection, the
questions below are intended to assist in the formulation of comments
and should not be construed as a limitation on the number of comments
that interested persons may submit or as a limitation on the issues
that may be addressed in such comments. Comments containing references,
studies, research, and other empirical data that are not widely
published should include copies of the referenced materials. Again,
note that all comments will be made publicly available as submitted;
therefore proprietary or confidential information should not be
included. NIST is specifically interested in receiving input pertaining
to one or more of the following questions:
1. What diversity of the geographical locations of the servers will
provide the best balance between cost and accuracy consistent with the
requirements outlined above?
2. How should the sites be configured to provide the integrity,
reliability, and accuracy that are required as part of a time service
that must support the national infrastructure?
3. How should the monitoring and supervisory functions be
configured to ensure that the time signals are accurate and that any
failure be detected? In addition, how should logging functions be
implemented so that the log files can be used in the case that the
accuracy of the time signals become involved in a legal proceeding?
4. How should the link to the NIST atomic time scale be realized?
What is the appropriate relationship between NIST and time service
provider(s)? How should this relationship be designed to preserve the
requirements of legal and technical traceability of the time stamps to
national time standards?
5. What are ways in which the relationship between the private
operator(s) and NIST can best be realized? A formal agreement will be
established between NIST and each private operator, and NIST seeks
input on what type of agreement would best support the program.
6. Should NIST hold a competition to select a private sector
organization(s) to operate an ensemble of time servers to provide NIST-
traceable time information, or should NIST make the opportunity
available to all eligible parties?
7. What are advantages and disadvantages of NIST's potential
transition of time services from a NIST-only service to private sector
operation of an ensemble of time servers that will provide NIST-
traceable time information via the Internet? Note that NIST would
continue to provide oversight of the accuracy and integrity of the
Internet-based time services, and that the transition would not affect
the traceability of the distributed time signals to national and
international standards.
8. What other considerations should be important in the design of
the time services?
Dated: March 20, 2014.
Willie E. May,
Associate Director for Laboratory Programs.
[FR Doc. 2014-06683 Filed 3-25-14; 8:45 am]
BILLING CODE 3510-13-P
