rfc9748v1.txt		rfc9748.txt
	skipping to change at line 16 ¶		skipping to change at line 16 ¶
	ISSN: 2070-1721		ISSN: 2070-1721
	Updating the NTP Registries		Updating the NTP Registries
	Abstract		Abstract
	The Network Time Protocol (NTP) and Network Time Security (NTS)		The Network Time Protocol (NTP) and Network Time Security (NTS)
	documents define a number of registries, collectively called the NTP		documents define a number of registries, collectively called the NTP
	registries.		registries.
	Some registries have wrong values, some registries do not follow		Some registries are correct, but some include incorrect assignments
	current common practice, and some are just right. For the sake of		and some don’t follow common practice. For the sake of completeness,
	completeness, this document reviews all NTP and NTS registries, and		this document reviews all NTP and NTS registries, and corrects the
	makes updates where necessary.		registries where necessary.
	This document updates RFCs 5905, 5906, 7821, 7822, and 8573.		This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	skipping to change at line 59 ¶		skipping to change at line 59 ¶
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Existing Registries		2. Existing Registries
	2.1. Reference ID and Kiss-o'-Death Registries		2.1. Reference ID and Kiss-o'-Death Registries
	2.2. Extension Field Types		2.2. Extension Field Types
	2.3. Network Time Security Registries		2.3. Network Time Security Registries
	3. Registry Updates		3. NTP Registry Updates
	3.1. Guidance to Designated Experts		3.1. Designated Experts
	4. IANA Considerations		4. IANA Considerations
	4.1. NTP Reference Identifier Codes		4.1. NTP Reference Identifier Codes
	4.2. NTP Kiss-o'-Death Codes		4.2. NTP Kiss-o'-Death Codes
	4.3. NTP Extension Field Types		4.3. NTP Extension Field Types
	5. Security Considerations		5. Security Considerations
	6. Normative References		6. Normative References
	Acknowledgements		Acknowledgements
	Author's Address		Author's Address
	1. Introduction		1. Introduction
	The Network Time Protocol (NTP) and Network Time Security (NTS)		The Network Time Protocol (NTP) and Network Time Security (NTS)
	documents define a number of registries, collectively called the NTP		documents define a number of registries, collectively called the NTP
	registries. The NTP registries can all be found at		registries. The NTP registries can all be found at
	<https://www.iana.org/assignments/ntp-parameters> and the NTS		<https://www.iana.org/assignments/ntp-parameters> and the NTS
	registries can all be found at <https://www.iana.org/assignments/		registries can all be found at <https://www.iana.org/assignments/
	nts>.		nts>.
	Some registries have wrong values, some registries do not follow		Some registries are correct, but some include incorrect assignments
	current common practice, and some are just right. For the sake of		and some don’t follow common practice. For the sake of completeness,
	completeness, this document reviews all NTP and NTS registries, and		this document reviews all NTP and NTS registries, and corrects the
	makes updates where necessary.		registries where necessary.
	The bulk of this document can be divided into two parts:		The bulk of this document can be divided into two parts:
	* First, each registry, its defining document, and a summary of its		* a summary of the relevant registries, including syntax
	syntax is defined.		requirements, registration procedures, and the defining documents.
	* Second, the revised format and entries for each registry that is		* a revised format and entries for each registry being modified.
	being modified is specified.
	2. Existing Registries		2. Existing Registries
	This section describes the registries and the rules for them. It is		This section describes the registries and the rules for them. It is
	intended to be a short summary of the syntax and registration		intended to be a short summary of the syntax and registration
	requirements for each registry. The semantics and protocol		requirements for each registry. The semantics and protocol
	processing rules for each registry -- that is, how an implementation		processing rules for each registry -- that is, how an implementation
	acts when sending or receiving any of the fields -- are not described		acts when sending or receiving any of the fields -- are not described
	here.		here.
	2.1. Reference ID and Kiss-o'-Death Registries		2.1. Reference ID and Kiss-o'-Death Registries
	[RFC5905] defines two registries: "NTP Reference Identifier Codes" in		[RFC5905] defines two registries: "NTP Reference Identifier Codes" in
	Section 7.3 and the "NTP Kiss-o'-Death Codes" in Section 7.4. Both		Section 7.3 and the "NTP Kiss-o'-Death Codes" in Section 7.4.
	of these are allowed to be four ASCII characters; padded on the right		Reference identifiers and kiss codes can be up to four ASCII
	with all-bits-zero if necessary. Entries that start with 0x58, the		characters, padded on the right with all-bits-zero if necessary.
	ASCII letter uppercase X, are reserved for Private or Experimental		Entries that start with 0x58, the ASCII letter uppercase X, are
	Use. Both registries are First Come First Served. The registries		reserved for Private or Experimental Use. Both registries are First
	were created per Section 16 of [RFC5905].		Come First Served. The registries were created per Section 16 of
			[RFC5905].
	2.2. Extension Field Types		2.2. Extension Field Types
	Section 7.5 of [RFC5905] defines the on-the-wire format of extension		Section 7.5 of [RFC5905] defines the on-the-wire format of extension
	fields but does not create a registry for them.		fields but does not create a registry for them.
	Section 13 of [RFC5906] mentions the "NTP Extension Field Types"		Section 13 of [RFC5906] mentions the "NTP Extension Field Types"
	registry, and defines it indirectly by defining 30 extensions (10		registry, and defines it indirectly by defining 30 extensions (10
	each for request, response, and error response). It does not provide		each for request, response, and error response). It does not provide
	a formal definition of the columns in the registry. Section 10 of		a formal definition of the columns in the registry. Section 10 of
	skipping to change at line 139 ¶		skipping to change at line 139 ¶
	one would expect the next extension field header.		one would expect the next extension field header.
	[RFC8573] changes the cryptography used in the MAC field.		[RFC8573] changes the cryptography used in the MAC field.
	[RFC8915] adds four new entries to the "NTP Extension Field Types"		[RFC8915] adds four new entries to the "NTP Extension Field Types"
	registry.		registry.
	The following problems exist with the current registry:		The following problems exist with the current registry:
	* Many of the entries in the "NTP Extension Field Types" registry		* Many of the entries in the "NTP Extension Field Types" registry
	have swapped some of the nibbles; 0x1234 is listed as 0x1432, for		have swapped some of the nibbles; for example, 0x0302 was listed
	example. This was due to documentation errors with the original		for Cookie Message Request instead of 0x0203. The errors are due
	implementation of Autokey. This document marks the erroneous		to documentation errors with the original implementation of
	values as reserved, in case there is an implementation using the		Autokey. This document marks the erroneous values as reserved, in
	registered values instead of what the original implementation		case there is an implementation using the registered values
	used. Applications that used those values would have realized		instead of what the original implementation used. Applications
	that they did not interoperate with the dominant (if not only)		that used those values would have realized that they did not
	implementation at the time. Marking the values as reserved		interoperate with the dominant (if not only) implementation at the
	ensures that any such applications continue to work as is.		time. Marking the values as reserved ensures that any such
			applications continue to work as is.
	* Some values were mistakenly reused.		* Some values were mistakenly reused.
	2.3. Network Time Security Registries		2.3. Network Time Security Registries
	[RFC8915] defines the NTS protocol. The related registries are		[RFC8915] defines the NTS protocol. The related registries are
	listed here for completeness, but there are no changes specified in		listed here for completeness, but there are no changes specified in
	this document.		this document.
	In [RFC8915]:		In [RFC8915]:
	skipping to change at line 174 ¶		skipping to change at line 175 ¶
	registration policies: IETF Review, Specification Required, and		registration policies: IETF Review, Specification Required, and
	Private or Experimental Use.		Private or Experimental Use.
	Section 7.7 created the "Network Time Security Next Protocols"		Section 7.7 created the "Network Time Security Next Protocols"
	registry that similarly partitions the range.		registry that similarly partitions the range.
	Section 7.8 created the "Network Time Security Error Codes" and		Section 7.8 created the "Network Time Security Error Codes" and
	"Network Time Security Warning Codes" registries. Both registries		"Network Time Security Warning Codes" registries. Both registries
	are partitioned the same way.		are partitioned the same way.
	3. Registry Updates		3. NTP Registry Updates
	The following general guidelines apply to all registries updated
	here:
	* Each registry reserves a partition for Private or Experimental		The following general guidelines apply to the NTP registries:
	Use.
	* Entries with ASCII fields are now limited to uppercase letters or		* A partition of the "NTP Extension Field Types" registry is
	digits; fields starting with 0x58, the uppercase letter "X", are
	reserved for Private or Experimental Use.		reserved for Private or Experimental Use.
	* The policy for every registry is now Specification Required, as		* 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 starting with 0x58, the
			uppercase letter "X", are reserved for Private or Experimental
			Use.
			* The policy for each registry is now Specification Required, as
	defined in [RFC8126], Section 4.6.		defined in [RFC8126], Section 4.6.
	The IESG is requested to choose three designated experts, with		3.1. Designated Experts
			The IESG is requested to choose three designated experts (DEs), with
	approvals from two being required to implement a change. Guidance		approvals from two being required to implement a change. Guidance
	for the experts is given below.		for the experts is given below.
	Each entry described in the sub-sections below is intended to		The DEs should be familiar with [RFC8126], particularly Section 5.
	completely replace the existing entry with the same name.		As that reference suggests, the DE should ascertain the existence of
			a suitable specification and verify that it is publicly available.
	3.1. Guidance to Designated Experts		The DE is also expected to check the clarity of purpose and use of
			the requested code points.
	The designated experts (DE) should be familiar with [RFC8126],
	particularly Section 5. As that reference suggests, the DE should
	ascertain the existence of a suitable 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,		In addition, the DE is expected to be familiar with this document,
	specifically the history documented here.		specifically the history documented here.
	4. IANA Considerations		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		4.1. NTP Reference Identifier Codes
	The registration procedure has been changed to Specification Required		The registration procedure has been changed to Specification Required
	and this document has been added as a reference.		and this document has been added as a reference.
	The Note has been changed to read as follows:		The Note has been changed to read as follows:
	| Codes beginning with the character "X" are reserved for		| Codes beginning with the character "X" are reserved for
	| experimentation and development. IANA cannot assign them.		| experimentation and development. IANA cannot assign them.
	skipping to change at line 419 ¶		skipping to change at line 421 ¶
	+---------------+------------------------------------+-------------+		+---------------+------------------------------------+-------------+
	| 0xF000-0xFFFF | Reserved for Experimental Use | RFC 9748 |		| 0xF000-0xFFFF | Reserved for Experimental Use | RFC 9748 |
	+---------------+------------------------------------+-------------+		+---------------+------------------------------------+-------------+
	Table 1		Table 1
	5. Security Considerations		5. Security Considerations
	This document adds no new security considerations, as they are		This document adds no new security considerations, as they are
	defined in the document that defines the extension. See the		defined in the document that defines the extension. See the
	References column of the appropriate table.		References column of the appropriate IANA registry.
	6. Normative References		6. Normative References
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
	[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol		[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
	Version 4: Autokey Specification", RFC 5906,		Version 4: Autokey Specification", RFC 5906,
End of changes. 15 change blocks.
	50 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.48.