ntp
Internet Engineering Task Force (IETF) R. Salz
Internet-Draft
Request for Comments: 9748 Akamai Technologies
Updates: 5905, 5906, 8573, 7821, 7822, 7821 (if 20 August 2024
approved)
Intended status: Standards Track
Expires: 21 8573 February 2025
Category: Standards Track
ISSN: 2070-1721
Updating the NTP Registries
draft-ietf-ntp-update-registries-16
Abstract
The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of assigned number registries, collectively called the NTP
registries.
Some registries have wrong values, are correct, but some registries do not follow
current common practice, include incorrect assignments
and some are just right. don’t follow common practice. For the sake of completeness,
this document reviews all NTP and NTS registries, and
makes updates corrects the
registries where necessary.
This document updates RFC RFCs 5905, RFC 5906, RFC 8573, RFC 7821, 7822, and RFC
7821.
Notes 8573.
Status of This Memo
This note is to be removed before publishing as an RFC. Internet Standards Track document.
This document is a product of the NTP Working Group
(https://dt.ietf.org/wg/ntp). Source for this draft and an issue
tracker can be found at https://github.com/richsalz/draft-rsalz-
update-registries.
RFC Editor: Please update 'this RFC' to refer to this document, once
its RFC number is known, through Internet Engineering Task Force
(IETF). It represents the document.
Status consensus of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 IETF community. It has
received public review and BCP 79.
Internet-Drafts are working documents of has been approved for publication by the
Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 February 2025.
https://www.rfc-editor.org/info/rfc9748.
Copyright Notice
Copyright (c) 2024 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Existing Registries . . . . . . . . . . . . . . . . . . . . . 3
2.1. Reference ID, ID and Kiss-o'-Death . . . . . . . . . . . . . . . 3 Registries
2.2. Extension Field Types . . . . . . . . . . . . . . . . . . 3
2.3. Network Time Security Registries . . . . . . . . . . . . 4
3. Updated Registries . . . . . . . . . . . . . . . . . . . . . 5 NTP Registry Updates
3.1. Guidance to Designated Experts . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. NTP Reference Identifier Codes . . . . . . . . . . . . . 5
4.2. NTP Kiss-o'-Death Codes . . . . . . . . . . . . . . . . . 6
4.3. NTP Extension Field Types . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . 10
Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Network Time Protocol (NTP) and Network Time Security (NTS)
documents define a number of assigned number registries, collectively called the NTP
registries. The NTP registries can all be found at
https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml
(https://www.iana.org/assignments/ntp-parameters/ntp-
parameters.xhtml)
<https://www.iana.org/assignments/ntp-parameters> and the NTS
registries can all be found at
https://www.iana.org/assignments/nts/nts.xhtml
(https://www.iana.org/assignments/nts/nts.xhtml). <https://www.iana.org/assignments/
nts>.
Some registries have wrong values, are correct, but some registries do not follow
current common practice, include incorrect assignments
and some are just right. don’t follow common practice. For the sake of completeness,
this document reviews all NTP and NTS registries, and
makes updates corrects the
registries where necessary.
The bulk of this document can be divided into two parts:
* First, each registry, its defining document, and a summary of its the relevant registries, including syntax is defined.
* Second,
requirements, registration procedures, and the defining documents.
* a revised format and entries for each registry that is being modified is specified. modified.
2. Existing Registries
This section describes the registries and the rules for them. It is
intended to be a short summary of the syntax and registration
requirements for each registry. The semantics and protocol
processing rules for each registry -- that is, how an implementation
acts when sending or receiving any of the fields -- are not described
here.
2.1. Reference ID, ID and Kiss-o'-Death Registries
[RFC5905] defined defines two registries; the registries: "NTP Reference ID Identifier Codes" in
Section 7.3, 7.3 and the "NTP Kiss-o'-Death Codes" in Section 7.4. Both of these are allowed to
Reference identifiers and kiss codes can be up to four ASCII characters;
characters, padded on the right with all-bits-zero if necessary.
Entries that start with 0x58, the ASCII letter uppercase X, are
reserved for Private or Experimental Use. Both registries are
first-come first-served. First
Come First Served. The formal request to define the registries
is in [RFC5905], were created per Section 16. 16 of
[RFC5905].
2.2. Extension Field Types
[RFC5905],
Section 7.5 defined of [RFC5905] defines the on-the-wire format of extension
fields but did does not create a registry for them.
[RFC5906],
Section 13 mentioned of [RFC5906] mentions the "NTP Extension Field Types Types"
registry, and defined defines it indirectly by defining 30 extensions (10
each for request, response, and error response). It did does not provide
a formal definition of the columns in the registry. [RFC5906], Section 10 of
[RFC5906] splits the Field Type into four subfields, only for use
within the Autokey extensions.
[RFC7821] added adds a new entry, Checksum Complement, to the "NTP
Extension Field Types Types" registry.
[RFC7822] clarified clarifies the processing rules for Extension Field Types,
particularly around the interaction with the Message Authentication
Code (MAC) field. NTPv4 packets may contain a MAC that appears where
one would expect the next extension field header.
[RFC8573] changed changes the cryptography used in the MAC field.
[RFC8915] added adds four new entries to the "NTP Extension Field Types Types"
registry.
The following problems exist with the current registry:
* Many of the entries in the "NTP Extension Field Types Types" registry
have swapped some of the nibbles; 0x1234 is listed as 0x1432 for
example. This example, 0x0302 was listed
for Cookie Message Request instead of 0x0203. The errors are due
to documentation errors with the original implementation of
Autokey. This document marks the erroneous values as reserved, in
case there is an implementation that used using the registered values
instead of what the original implementation used. Applications
that might have used those values would have realized that they did not
interoperate with the dominant (if not only) implementation at the
time. Marking the values as reserved ensures that any such
applications would still be able continue to work as- as is.
* Some values were mistakenly re-used. reused.
2.3. Network Time Security Registries
[RFC8915] defines the NTS protocol. Its The related registries are
listed here for completeness, but there are no changes to them are specified in
this document.
In [RFC8915]:
Sections 7.1 through 7.5 (inclusive) added entries to existing
registries.
Section 7.6 created a new registry, NTS the "Network Time Security Key Establishment
Record
Types, Types" registry that partitions the assigned numbers range into three different
registration policies: IETF Review, Specification Required, and
Private or Experimental Use.
Section 7.7 created a new registry, NTS the "Network Time Security Next Protocols, Protocols"
registry that similarly partitions the assigned numbers. range.
Section 7.8 created two new registries, NTS the "Network Time Security Error Codes Codes" and NTS
"Network Time Security Warning Codes. Codes" registries. Both registries
are also partitioned the same way.
3. Updated Registries NTP Registry Updates
The following general guidelines apply to all registries updated
here: the NTP registries:
* Every registry reserves a A partition of the "NTP Extension Field Types" registry is
reserved for Private or Experimental Use.
* Entries In the "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death
Codes" registries, entries with ASCII fields are now limited to
uppercase letters or
digits; fields digits. Fields starting with 0x58, the
uppercase letter "X", are reserved for Private or Experimental
Use.
* The policy for every each registry is now Specification Required, as
defined in [RFC8126], Section 4.6.
3.1. Designated Experts
The IESG is requested to choose three designated experts, experts (DEs), with
approvals from two being required to approve implement a registry change. Guidance
for such the experts is given below.
Each entry described in the sub-sections below is intended to
completely replace the existing entry with the same name.
3.1. Guidance to Designated Experts
The designated experts (DE) DEs should be familiar with [RFC8126], particularly Section 5.
As that reference suggests, the DE should ascertain the existence of
a suitable specification, specification and verify that it is publicly available.
The DE is also expected to check the clarity of purpose and use of
the requested code points.
In addition, the DE is expected to be familiar with this document,
specifically the history documented here.
4. IANA Considerations
Each entry described in the subsections below is intended to
completely replace the existing entry with the same name.
4.1. NTP Reference Identifier Codes
The registration procedure is has been changed to Specification Required. Required
and this document has been added as a reference.
The Note is has been changed to read as follows:
*
| Codes beginning with the character "X" are reserved for
| experimentation and development. IANA cannot assign them.
The columns are defined as follows:
*
ID (required): a four-byte value padded on the right with all-
bits-zero. all-bits-
zero. Each byte other than padding must be an ASCII uppercase letter
letters or digits.
*
Clock source (required): A a brief text description of the ID.
*
Reference (required): the publication defining the ID.
The existing entries are left unchanged.
4.2. NTP Kiss-o'-Death Codes
The registration procedure is changed to Specification Required. Required and
this document has been added as a reference.
The Note is has been changed to read as follows:
*
| Codes beginning with the character "X" are reserved for
| experimentation and development. IANA cannot assign them.
The columns are defined as follows:
*
ID (required): a four-byte value padded on the right with all-
bits-zero. all-bits-
zero. Each byte other than padding must be an ASCII uppercase letter
letters or digits.
*
Meaning source (required): A a brief text description of the ID.
*
Reference (required): the publication defining the ID.
The existing entries are left unchanged.
4.3. NTP Extension Field Types
The registration procedure is has been changed to Specification Required.
The reference Required
and [RFC5906] should be added, if possible. and this document have been added as references.
The following two Notes are have been added:
*
| Field Types in the range 0xF000 through 0xFFFF, inclusive, are
| reserved for experimentation and development. IANA cannot assign
| them. Both NTS Cookie and Autokey Message Request have the same
| Field Type; in practice this is not a problem as the field
| semantics will be determined by other parts of the message.
*
| The "Reserved for historic reasons" is for differences between the
| original documentation and implementation of Autokey and marks the
| erroneous values as reserved, in case there is an implementation
| that used the registered values instead of what the original
| implementation used.
The columns are defined as follows:
*
Field Type (required): A a two-byte value in hexadecimal.
*
Meaning (required): A a brief text description of the field type.
*
Reference (required): the publication defining the field type.
The table is replaced with the following entries.
IANA is requested
to replace "This RFC" with has updated the actual RFC number once assigned.
+============+====================================+=============+ registry as shown in Table 1.
+===============+====================================+=============+
| Field Type | Meaning | Reference |
+============+====================================+=============+
+===============+====================================+=============+
| 0x0000 | Crypto-NAK; authentication failure | RFC 5905 [RFC5905] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0002 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0102 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0104 | Unique Identifier | RFC 8915, [RFC8915], |
| | | Section 5.3 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0200 | No-Operation Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0201 | Association Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0202 | Certificate Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0203 | Cookie Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0204 | Autokey Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0204 | NTS Cookie | RFC 8915, [RFC8915], |
| | | Section 5.4 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0205 | Leapseconds Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0206 | Sign Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0207 | IFF Identity Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0208 | GQ Identity Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0209 | MV Identity Message Request | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0302 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0304 | NTS Cookie Placeholder | RFC 8915, [RFC8915], |
| | | Section 5.5 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0402 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0404 | NTS Authenticator and Encrypted | RFC 8915, [RFC8915], |
| | Extension Fields | Section 5.6 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0502 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0602 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0702 | Reserved for historic reasons | This RFC 9748 |
+---------------+------------------------------------+-------------+
| 0x0802 | Reserved for historic reasons | RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x0902 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x2005 | UDP Checksum Complement | RFC 7821 [RFC7821] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8002 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8102 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8200 | No-Operation Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8201 | Association Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8202 | Certificate Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8203 | Cookie Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8204 | Autokey Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8205 | Leapseconds Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8206 | Sign Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8207 | IFF Identity Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8208 | GQ Identity Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8209 | MV Identity Message Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8302 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8402 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8502 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8602 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8702 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8802 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0x8902 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC002 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC102 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC200 | No-Operation Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC201 | Association Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC202 | Certificate Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC203 | Cookie Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC204 | Autokey Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC205 | Leapseconds Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC206 | Sign Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC207 | IFF Identity Message Error | RFC 5906 [RFC5906] |
| | Response | |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC208 | GQ Identity Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC209 | MV Identity Message Error Response | RFC 5906 [RFC5906] |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC302 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC402 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC502 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC602 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC702 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC802 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xC902 | Reserved for historic reasons | This RFC 9748 |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
| 0xF000- 0xF000-0xFFFF | Reserved for Experimental Use | This RFC 9748 |
| 0xFFFF | | |
+------------+------------------------------------+-------------+
+---------------+------------------------------------+-------------+
Table 1
5. Security Considerations
This document adds no new security considerations, as they are
defined in the document that defines the extension. See the
References column of the appropriate table.
6. Acknowledgements
The members of the NTP Working Group helped a great deal. Notable
contributors include:
* Miroslav Lichvar, Red Hat
* Daniel Franke, formerly at Akamai Technologies
* Danny Mayer, Network Time Foundation
* Michelle Cotton, formerly at IANA
* Tamme Dittrich, Tweede Golf
7. registry.
6. Normative References
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>.
<https://www.rfc-editor.org/info/rfc5905>.
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/rfc/rfc5906>.
<https://www.rfc-editor.org/info/rfc5906>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/rfc/rfc7821>. <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/rfc/rfc7822>. <https://www.rfc-editor.org/info/rfc7822>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", RFC 8573,
DOI 10.17487/RFC8573, June 2019,
<https://www.rfc-editor.org/rfc/rfc8573>.
<https://www.rfc-editor.org/info/rfc8573>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/rfc/rfc8915>.
<https://www.rfc-editor.org/info/rfc8915>.
Acknowledgements
The members of the NTP Working Group helped a great deal. Notable
contributors include:
* Miroslav Lichvar, Red Hat
* Daniel Franke, formerly at Akamai Technologies
* Danny Mayer, Network Time Foundation
* Michelle Cotton, formerly at IANA
* Tamme Dittrich, Tweede Golf
Author's Address
Rich Salz
Akamai Technologies
Email: rsalz@akamai.com