The update registries draft

2.1. Reference ID, Kiss-o'-Death

[RFC5905] defined two registries, the Reference ID in Section 7.3, and the Kiss-o'-Death in Section 7.4. Both of these are allowed to be four ASCII 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 experimentation and development. Both registries are first-come first-served. The formal request to define the registries is in Section 16.¶

Section 7.5 of [RFC5905] defined the on-the-wire format of extension fields but did not create a registry for it.¶

2.2. Extension Field Types

[RFC5906] mentioned the Extension Field Types registry, and defined it indirectly by defining 30 extensions (15 each for request and response) in Section 13. It did 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] added a new entry, Checksum Complement, to the Extension Field Types registry.¶

[RFC7822] clarified the processing rules for Extension Field Types, particularly around the interaction with the Message Authentication Code (MAC) field.¶

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

The following problems exists with the current registry:¶

• Many of the entries in the Extension Field Types registry have swapped some of the nibbles; 0x1234 is listed as 0x1432 for example. This document marks the erroneous values as reserved.¶
• Some values were mistakenly re-used.¶

2.3. Network Time Security Registries

[RFC8915] defines the Network Time Security (NTS) protocol. Sections 7.1 through 7.5 (inclusive) added entries to existing registries.¶

Section 7.6 created a new registry, NTS Key Establishment Record Types, that partitions the assigned numbers into three different registration policies: IETF Review, Specification Required, and Private or Experimental Use.¶

Section 7.7 created a new registry, NTS Next Protocols, that similarly partitions the assigned numbers.¶

Section 7.8 created two new registries, NTS Error Codes and NTS Warning Codes. Both registries are also partitioned the same way.¶

4.1. NTP Reference Identifier Codes

The registration procedure is changed to specification required.¶

The Note is changed to read as follows:¶

• Codes beginning with the character "-" 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 zero's. Each value must be an ASCII uppercase letter or minus sign¶
• 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.¶

The Note is changed to read as follows:¶

• Codes beginning with the character "-" 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 zero's. Each value must be an ASCII uppercase letter or minus sign.¶
• 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 is changed to specification required.¶

The reference should be [RFC5906] added, if possible.¶

The following Note is 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 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.¶

The table is replaced with the following entries.¶

4.4. Network Time Security Key Establishment Record Types

The registration procedure is changed to specification required.¶

The following note should be added:¶

• Record Type numbers in the range 0x4000 through 0x7FFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.¶

The existing entries are left unchanged.¶

4.5. Network Time Security Next Protocols

The registration procedure is changed to specification required.¶

The following note should be added:¶

• Protocol ID numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.¶

The existing entries are left unchanged.¶

4.6. Network Time Security Error Codes

The registration procedure is changed to specification required.¶

The following note should be added:¶

• Error code numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.¶

The existing entries are left unchanged.¶

4.7. Network Time Security Warning Codes

The registration procedure is changed to specification required.¶

The following note should be added:¶

• Warning code numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.¶

The existing entries are left unchanged.¶