2.1.Reference ID and Kiss-o'-Death Registries

[RFC5905] defines two registries: "NTP Reference Identifier Codes" in Section7.3 and the"NTP Kiss-o'-Death Codes" in Section7.4. Reference identifiers and kiss codes can be up to four ASCII characters, padded on the right with all-bits-zero if necessary.Entries that start with 0x58, the ASCIIletter uppercase X, are reserved for Private or Experimental Use.Both registries are First Come First Served. The registries were createdperSection 16 of [RFC5905].¶

2.2.Extension Field Types

Section 7.5 of [RFC5905] defines the on-the-wire format of extensionfields but does not create a registry for them.¶

Section 13 of [RFC5906] mentions the "NTP Extension Field Types" registry, and defines itindirectly by defining 30 extensions (10 each for request, response, anderror response).It does not provide a formal definition of the columns in the registry.Section 10 of [RFC5906] splits the Field Type into four subfields,only for use within the Autokey extensions.¶

[RFC7821] adds a new entry, Checksum Complement, to the "NTP Extension Field Types" registry.¶

[RFC7822] clarifies the processing rules for Extension Field Types,particularly around the interaction with the Message AuthenticationCode (MAC) field. NTPv4 packets may contain a MAC that appears whereone would expect the next extension field header.¶

[RFC8573] changes the cryptography used in the MAC field.¶

[RFC8915] adds four new entries to the "NTP Extension Field Types" registry.¶

The following problems exist with the current registry:¶

• Many of the entries in the "NTP Extension Field Types" registry haveswapped some of the nibbles; for example, 0x0302 was listed for Cookie Message Request instead of 0x0203. The errors are due to documentation errors with the original implementationof Autokey.This document marks the erroneous values as reserved, in case thereis an implementation using the registered valuesinstead of what the original implementation used.Applications that used those values would have realizedthat they did not interoperate with the dominant (if not only)implementation at the time.Marking the values as reserved ensures that any such applications continueto work as is.¶

• Some values were mistakenly reused.¶

2.3.Network Time Security Registries

[RFC8915] defines the NTS protocol.The related registries are listed here for completeness, but there are nochanges specified in this document.¶

In[RFC8915]:¶

Sections7.1 through7.5 (inclusive) added entries to existing registries.¶

Section7.6 created the "Network Time Security Key Establishment Record Types" registry that partitions the range into three different registration policies:IETF Review, Specification Required, and Private or Experimental Use.¶

Section7.7 created the "Network Time Security Next Protocols" registry that similarly partitions the range.¶

Section7.8 created the "Network Time Security Error Codes" and "Network Time Security Warning Codes" registries. Both registries are partitioned the same way.¶

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 for the experts is given below.¶

The DEs should be familiar with[RFC8126], particularlySection5. As that reference suggests, the DE should ascertain the existenceof a suitable specification and verify that it is publicly available. The DEis also expected to check the clarity of purpose and use of the requestedcode points.¶

In addition, the DE is expected to be familiar with this document,specifically the history documented here.¶

4.1.NTP Reference Identifier Codes

The registration procedure has been changed to Specification Required and this document has been added as a reference.¶

The Note 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. Each byte other than padding must be ASCII uppercase letters or digits.¶

Clock source (required):

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 and this document has been added as a reference.¶

The Note 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. Each byte other than padding must be ASCII uppercase letters or digits.¶

Meaning source (required):

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 has been changed to Specification Required and[RFC5906] and this document have been added as references.¶

The following two Notes 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 two-byte value in hexadecimal.¶

Meaning (required):

a brief text description of the field type.¶

Reference (required):

the publication defining the field type.¶

IANA has updated the registry as shown inTable 1.¶