<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.3) -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ntp-update-registries-16" number="9748" category="std" consensus="true" submissionType="IETF" obsoletes="" updates="5905, 5906, 8573, 7821, 7822, 7821" 8573" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 --> version="3" xml:lang="en">

  <front>
    <title>Updating the NTP Registries</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ntp-update-registries-16"/> name="RFC" value="9748"/>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <date year="2024" month="August" day="20"/> year="2025" month="February"/>
    <area>INT</area>
    <workgroup>ntp</workgroup>
    <keyword>NTP</keyword>
    <keyword>extensions</keyword>
    <keyword>registries</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <?line 34?>
<t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents
define a number of assigned number registries, collectively called the NTP
registries.</t>
<!-- [rfced] May we update this text for clarity?  Note that it appears in the Abstract and the Introduction.

Original:
   Some registries have wrong values, some registries do not follow
   current common practice, and some are just right.  For the sake of
   completeness, this document reviews all NTP and NTS registries, and
   makes updates where necessary.

Perhaps:
   Some registries are correct, but some include incorrect assignments
   and some don’t follow common practice. For the sake of completeness,
   this document reviews all NTP and NTS registries, and corrects the
   registries where necessary.
-->

      <t>Some registries have wrong values, some registries
do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries,
and makes updates where necessary.</t>
      <t>This document updates RFC RFCs 5905, RFC 5906, RFC 8573, RFC 7821, 7822, and
RFC 7821.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Notes</name>
      <t>This document is a product of the
    <eref target="https://dt.ietf.org/wg/ntp">NTP Working Group</eref>.
    Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/richsalz/draft-rsalz-update-registries"/>. 8573.
</t>
      <t>RFC Editor: Please update 'this RFC' to refer to this document,
    once its RFC number is known, through the document.</t>
    </note>
    </abstract>
  </front>
  <middle>
    <?line 48?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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
<eref target="https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml">https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml</eref> target="https://www.iana.org/assignments/ntp-parameters" brackets="angle"/>
and the NTS registries can all be found at
<eref target="https://www.iana.org/assignments/nts/nts.xhtml">https://www.iana.org/assignments/nts/nts.xhtml</eref>.</t> target="https://www.iana.org/assignments/nts" brackets="angle"/>.</t>
      <t>Some registries have wrong values, some registries
do not follow current common practice, and some are just right.
For the sake of completeness, this document reviews all NTP and NTS registries,
and makes updates where necessary.</t>
<!-- [rfced] To better align with the text in section 2 and for clarity, may we update the text as follows?

Original:
   The bulk of this document can be divided into two parts:

   *  First, each registry, its defining document, and a summary of its
      syntax is defined.

   *  Second, the revised format and entries for each registry that is
      being modified is specified.

Perhaps:
   The bulk of this document can be divided into two parts:

   *  a summary of the relevant registries, including syntax requirements,
      registration procedures, and the defining documents.

   *  a revised format and entries for each registry
      being modified.
-->

      <t>The bulk of this document can be divided into two parts:</t>
      <ul spacing="normal">
        <li>
          <t>First, each registry, its defining document, and a summary of its
syntax is defined.</t>
        </li>
        <li>
          <t>Second, the revised format and entries for each registry that is
being modified is specified.</t>
        </li>
      </ul>
    </section>
    <section anchor="existing-registries">
      <name>Existing Registries</name>
      <t>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.</t>
      <section anchor="reference-id-kiss-o-death">
        <name>Reference ID, Kiss-o'-Death</name> ID and Kiss-o'-Death Registries</name>
<!-- [rfced] As we believe "these" refers to the code points (not the registries), may we update the text as described below?  Also, are the codes 4 ASCII characters or are they allowed to be up to 4 ASCII characters?

Original:
   Both of these are allowed to
   be four ASCII characters; padded on the right with all-bits-zero if
   necessary.

Perhaps:
   Reference identifiers and kiss codes can be up to four ASCII characters,
   padded on the right with all-bits-zero if necessary.
-->

<!-- [rfced] Because the registries were created (i.e., it's no longer a request), we updated the text as follows.  Please let us know if corrections are needed.

Original:
   The formal request to define the registries
   is in [RFC5905], Section 16.

Perhaps:
   The registries were created per
   Section 16 of [RFC5905].
-->

        <t><xref target="RFC5905"/> defined defines two registries; the registries:
	"NTP Reference ID Identifier Codes" in Section 7.3, <xref target="RFC5905" section="7.3" sectionFormat="bare"/> and the
"NTP Kiss-o'-Death Codes" in Section 7.4. <xref target="RFC5905" section="7.4" sectionFormat="bare"/>.  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 or Experimental Use.
Both registries are first-come first-served. First Come First Served. The formal request to define
the registries is in were created
per <xref section="16" sectionFormat="comma" sectionFormat="of" target="RFC5905"/>.</t>
      </section>
      <section anchor="extension-field-types">
        <name>Extension Field Types</name>
        <t><xref section="7.5" sectionFormat="comma" sectionFormat="of" target="RFC5905"/> defined defines the on-the-wire format of extension
fields but did does not create a registry for them.</t>
        <t><xref section="13" sectionFormat="comma" target="RFC5906"/> mentioned target="RFC5906" sectionFormat="of" section="13"/> 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.
<xref section="10" sectionFormat="comma" sectionFormat="of" target="RFC5906"/> splits the Field Type into four subfields,
only for use within the Autokey extensions.</t>
        <t><xref target="RFC7821"/> added adds a new entry, Checksum Complement, to the "NTP Extension Field Types Types" registry.</t>
        <t><xref target="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.</t>
        <t><xref target="RFC8573"/> changed changes the cryptography used in the MAC field.</t>
        <t><xref target="RFC8915"/> added adds four new entries to the "NTP Extension Field Types Types" registry.</t>
        <t>The following problems exist with the current registry:</t>
        <ul spacing="normal">
          <li>
            <t>Many
<!-- [rfced]  Is this a real example of something that was registered incorrectly? We don't see either of these values in <https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3> or <http://web.archive.org/web/20230927142951/https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml#ntp-parameters-3>.   Would it be helpful to use a real example (e.g., 0x0203 vs 0x0302 (Cookie Message Request))?

Original:
   *  Many of the entries in the Extension Field Types registry have
      swapped some of the nibbles; 0x1234 is listed as 0x1432 for
      example.
-->

            <t>Many of the entries in the "NTP Extension Field Types" registry have
swapped some of the nibbles; 0x1234 is listed as 0x1432, for example.
This was 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-is.</t> as is.</t>
          </li>
          <li>
            <t>Some values were mistakenly re-used.</t> reused.</t>
          </li>
        </ul>
      </section>
      <section anchor="network-time-security-registries">
        <name>Network Time Security Registries</name>
        <t><xref target="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.</t>

<t>In <xref target="RFC8915"/>:</t>
        <t>Sections 7.1 <xref target="RFC8915" section="7.1" sectionFormat="bare"/> through 7.5 <xref target="RFC8915" section="7.5" sectionFormat="bare"/> (inclusive) added entries to existing registries.</t>

        <t>Section 7.6 <xref target="RFC8915" section="7.6" sectionFormat="bare"/> 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.</t>
        <t>Section 7.7 <xref target="RFC8915" section="7.7" sectionFormat="bare"/> created a new registry, NTS the "Network Time Security Next Protocols, Protocols" registry that similarly partitions the assigned numbers.</t> range.</t>
        <t>Section 7.8 <xref target="RFC8915" section="7.8" sectionFormat="bare"/> 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.</t>
      </section>
    </section>
    <section anchor="updated-registries">
      <name>Updated Registries</name>
      <name>Registry Updates</name>
<!-- [rfced] Section 3: Because this document seems to only update the NTP registries, may we update the text as follows?

Original:
   The following general guidelines apply to all registries updated here:

Perhaps:
   The following general guidelines apply to the NTP registries:
-->

      <t>The following general guidelines apply to all registries updated here:</t>
      <ul spacing="normal">
        <li>
          <t>Every
          <t>Each registry reserves a partition for Private or Experimental Use.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>The policy for every registry is now Specification Required, as defined
in <xref section="4.6" sectionFormat="comma" target="RFC8126"/>.</t>
        </li>
      </ul>
      <t>The IESG is requested to choose three designated experts, with approvals from two being required to approve implement a registry change. Guidance for such the experts is given below.</t>
<!-- [rfced] Section 3: This text seems misplaced.  Perhaps this is intended to appear in Section 4?

Original:
   Each entry described in the sub-sections below is intended to
   completely replace the existing entry with the same name.
-->

      <t>Each entry described in the sub-sections below is intended to completely
replace the existing entry with the same name.</t>
      <section anchor="guidance-to-designated-experts">
        <name>Guidance to Designated Experts</name>
        <t>The designated experts (DE) should be familiar with <xref target="RFC8126"/>, particularly
Section 5. <xref target="RFC8126" section="5" sectionFormat="bare"/>. 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.</t>
        <t>In addition, the DE is expected to be familiar with this document,
specifically the history documented here.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>

      <section anchor="ntp-reference-identifier-codes">
        <name>NTP Reference Identifier Codes</name>
        <t>The
<!-- [rfced] Note that we have added "and this document has been added as a reference" to the text in the IANA Considerations section.  Please let us know if any corrections are needed.

For example:
Original:
   The registration procedure is changed to Specification Required.</t> Required.

Current:
   The registration procedure has been changed to Specification Required
   and this document has been added as a reference.
-->

        <t>The registration procedure has been changed to Specification Required and this document has been added as a reference.</t>
        <t>The Note is has been changed to read as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Codes

	<blockquote>Codes beginning with the character "X" are reserved for
	experimentation and development. IANA cannot assign them.</t>
          </li>
        </ul> them.</blockquote>

        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>ID (required):
        <dl spacing="compact" newline="false">
          <dt>ID (required):</dt><dd> a four-byte value padded on the right
          with all-bits-zero.  Each byte other than padding must be an ASCII
          uppercase letter letters or digits.</t>
          </li>
          <li>
            <t>Clock digits.</dd>
          <dt>Clock source (required): A (required):</dt><dd>a brief text description of the ID.</t>
          </li>
          <li>
            <t>Reference (required): the ID.</dd>
          <dt>Reference (required):</dt><dd>the publication defining the ID.</t>
          </li>
        </ul> ID.</dd>
        </dl>

        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="ntp-kiss-o-death-codes">
        <name>NTP Kiss-o'-Death Codes</name>
        <t>The registration procedure is changed to Specification Required.</t> Required and this document has been added as a reference.</t>
        <t>The Note is has been changed to read as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Codes

        <blockquote>Codes beginning with the character "X" are reserved for
        experimentation and development. IANA cannot assign them.</t>
          </li>
        </ul> them.</blockquote>

        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>ID (required): a
        <dl spacing="compact" newline="false">
          <dt>ID (required):</dt><dd>a four-byte value padded on the right
          with all-bits-zero.  Each byte other than padding must be an ASCII
          uppercase letter letters or digits.</t>
          </li>
          <li>
            <t>Meaning digits.</dd>
          <dt>Meaning source (required): A (required):</dt><dd>a brief text description of the ID.</t>
          </li>
          <li>
            <t>Reference (required): the ID.</dd>
          <dt>Reference (required):</dt><dd>the publication defining the ID.</t>
          </li>
        </ul> ID.</dd>
        </dl>
        <t>The existing entries are left unchanged.</t>
      </section>
      <section anchor="ntp-extension-field-types">
        <name>NTP Extension Field Types</name>
        <t>The
<!-- [rfced] We have updated the text as follows to note that this document has been added as a reference to the NTP Extension Field Types registry. Please let us know if any updates are needed.

Original:
   The registration procedure is changed to Specification Required.</t>
        <t>The Required.

   The reference <xref target="RFC5906"/> [RFC5906] should be added, if possible.</t> possible.

Current:
   The registration procedure has been changed to Specification Required
   and [RFC5906] and this document have been added as references.
-->

        <t>The registration procedure has been changed to Specification Required and <xref target="RFC5906"/> and this document have been added as references.</t>
        <t>The following two Notes are have been added:</t>
        <ul spacing="normal">
          <li>
            <t>Field

        <blockquote>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.</t>
          </li>
          <li>
            <t>The message.</blockquote>

        <blockquote>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.</t>
          </li>
        </ul> used.</blockquote>

        <t>The columns are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Field
        <dl spacing="compact" newline="false">
          <dt>Field Type (required): A (required):</dt><dd>a two-byte value in hexadecimal.</t>
          </li>
          <li>
            <t>Meaning (required): A hexadecimal.</dd>
          <dt>Meaning (required):</dt><dd>a brief text description of the field type.</t>
          </li>
          <li>
            <t>Reference (required): the type.</dd>
          <dt>Reference (required):</dt><dd>the publication defining the field type.</t>
          </li>
        </ul>
        <t>The table is replaced with the following entries.
IANA is requested to replace "This RFC" with type.</dd>
        </dl>

        <t>IANA has updated the actual RFC number once
assigned.</t>
        <table> registry as shown in <xref target="tab1"/>.</t>
        <table anchor="tab1">
          <thead>
            <tr>
              <th align="left">Field Type</th>
              <th align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x0000</td>
              <td align="left">Crypto-NAK; authentication failure</td>
              <td align="left">RFC 5905</td> align="left"><xref target="RFC5905"/></td>
            </tr>
            <tr>
              <td align="left">0x0002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0104</td>
              <td align="left">Unique Identifier</td>
              <td align="left">RFC 8915, Section 5.3</td> align="left"><xref target="RFC8915" sectionFormat="comma" section="5.3"/></td>
            </tr>
            <tr>
              <td align="left">0x0200</td>
              <td align="left">No-Operation Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0201</td>
              <td align="left">Association Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0202</td>
              <td align="left">Certificate Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0203</td>
              <td align="left">Cookie Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0204</td>
              <td align="left">Autokey Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0204</td>
              <td align="left">NTS Cookie</td>
              <td align="left">RFC 8915, Section 5.4</td> align="left"><xref target="RFC8915" sectionFormat="comma" section="5.4"/></td>
            </tr>
            <tr>
              <td align="left">0x0205</td>
              <td align="left">Leapseconds Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0206</td>
              <td align="left">Sign Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0207</td>
              <td align="left">IFF Identity Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0208</td>
              <td align="left">GQ Identity Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0209</td>
              <td align="left">MV Identity Message Request</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x0302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0304</td>
              <td align="left">NTS Cookie Placeholder</td>
              <td align="left">RFC 8915, Section 5.5</td> align="left"><xref target="RFC8915" sectionFormat="comma" section="5.5"/></td>
            </tr>
            <tr>
              <td align="left">0x0402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0404</td>
              <td align="left">NTS Authenticator and Encrypted Extension Fields</td>
              <td align="left">RFC 8915, Section 5.6</td> align="left"><xref target="RFC8915" sectionFormat="comma" section="5.6"/></td>
            </tr>
            <tr>
              <td align="left">0x0502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0802</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x0902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x2005</td>
              <td align="left">UDP Checksum Complement</td>
              <td align="left">RFC 7821</td> align="left"><xref target="RFC7821"/></td>
            </tr>
            <tr>
              <td align="left">0x8002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8200</td>
              <td align="left">No-Operation Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8201</td>
              <td align="left">Association Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8202</td>
              <td align="left">Certificate Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8203</td>
              <td align="left">Cookie Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8204</td>
              <td align="left">Autokey Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8205</td>
              <td align="left">Leapseconds Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8206</td>
              <td align="left">Sign Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8207</td>
              <td align="left">IFF Identity Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8208</td>
              <td align="left">GQ Identity Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8209</td>
              <td align="left">MV Identity Message Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0x8302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8802</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0x8902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC002</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC102</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC200</td>
              <td align="left">No-Operation Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC201</td>
              <td align="left">Association Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC202</td>
              <td align="left">Certificate Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC203</td>
              <td align="left">Cookie Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC204</td>
              <td align="left">Autokey Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC205</td>
              <td align="left">Leapseconds Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC206</td>
              <td align="left">Sign Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC207</td>
              <td align="left">IFF Identity Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC208</td>
              <td align="left">GQ Identity Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC209</td>
              <td align="left">MV Identity Message Error Response</td>
              <td align="left">RFC 5906</td> align="left"><xref target="RFC5906"/></td>
            </tr>
            <tr>
              <td align="left">0xC302</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC402</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC502</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC602</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC702</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC802</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xC902</td>
              <td align="left">Reserved for historic reasons</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
            <tr>
              <td align="left">0xF000-<br/>0xFFFF</td> align="left">0xF000-0xFFFF</td>
              <td align="left">Reserved for Experimental Use</td>
              <td align="left">This RFC</td> align="left">RFC 9748</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
<!-- [rfced] To what does "the appropriate table" refer?  Is it the Reference column in table 1, or the tables as they appear in the IANA registry?

Original:
   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.
-->
      <t>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.</t>
    </section>

  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5906.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7821.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7822.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8573.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8915.xml"/>
    </references>

    <section anchor="acknowledgements"> anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The members of the NTP Working Group helped a great deal.
Notable contributors include:</t>
      <ul spacing="normal">
        <li>
          <t>Miroslav Lichvar,
          <t><contact fullname="Miroslav Lichvar"/>, Red Hat</t>
        </li>
        <li>
          <t>Daniel Franke,
          <t><contact fullname="Daniel Franke"/>, formerly at Akamai Technologies</t>
        </li>
        <li>
          <t>Danny Mayer,
          <t><contact fullname="Danny Mayer"/>, Network Time Foundation</t>
        </li>
        <li>
          <t>Michelle Cotton,
          <t><contact fullname="Michelle Cotton"/>, formerly at IANA</t>
        </li>
        <li>
          <t>Tamme Dittrich,
          <t><contact fullname="Tamme Dittrich"/>, Tweede Golf</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC5905">
        <front>
          <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
          <author fullname="D. Mills" initials="D." surname="Mills"/>
          <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
          <author fullname="J. Burbank" initials="J." surname="Burbank"/>
          <author fullname="W. Kasch" initials="W." surname="Kasch"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5905"/>
        <seriesInfo name="DOI" value="10.17487/RFC5905"/>
      </reference>
      <reference anchor="RFC5906">
        <front>
          <title>Network Time Protocol Version 4: Autokey Specification</title>
          <author fullname="B. Haberman" initials="B." role="editor" surname="Haberman"/>
          <author fullname="D. Mills" initials="D." surname="Mills"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.</t>
            <t>This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of
<!-- [rfced] Please review the protocol states, events, and transition functions is included. A prototype "Inclusive Language" portion of the Autokey design based on this memo has been implemented, tested, online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5906"/>
        <seriesInfo name="DOI" value="10.17487/RFC5906"/>
      </reference>
      <reference anchor="RFC7821">
        <front>
          <title>UDP Checksum Complement in the Network Time Protocol (NTP)</title>
          <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
          <date month="March" year="2016"/>
          <abstract>
            <t>The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets let us know if any changes are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets needed.  Updates of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7821"/>
        <seriesInfo name="DOI" value="10.17487/RFC7821"/>
      </reference>
      <reference anchor="RFC7822">
        <front>
          <title>Network Time Protocol Version 4 (NTPv4) Extension Fields</title>
          <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
          <author fullname="D. Mayer" initials="D." surname="Mayer"/>
          <date month="March" year="2016"/>
          <abstract>
            <t>The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7822"/>
        <seriesInfo name="DOI" value="10.17487/RFC7822"/>
      </reference>
      <reference anchor="RFC8126">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author fullname="M. Cotton" initials="M." surname="Cotton"/>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <author fullname="T. Narten" initials="T." surname="Narten"/>
          <date month="June" year="2017"/>
          <abstract>
            <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
            <t>To make assignments nature typically
result in a given registry prudently, guidance describing the conditions under more precise language, which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework helpful for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues readers.

Note that are likely our script did not flag any words in the operation of a registry.</t>
            <t>This is the third edition of particular, but this document; it obsoletes RFC 5226.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="26"/>
        <seriesInfo name="RFC" value="8126"/>
        <seriesInfo name="DOI" value="10.17487/RFC8126"/>
      </reference>
      <reference anchor="RFC8573">
        <front>
          <title>Message Authentication Code for the Network Time Protocol</title>
          <author fullname="A. Malhotra" initials="A." surname="Malhotra"/>
          <author fullname="S. Goldberg" initials="S." surname="Goldberg"/>
          <date month="June" year="2019"/>
          <abstract>
            <t>The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should
still be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 reviewed as a replacement.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8573"/>
        <seriesInfo name="DOI" value="10.17487/RFC8573"/>
      </reference>
      <reference anchor="RFC8915">
        <front>
          <title>Network Time Security for the Network Time Protocol</title>
          <author fullname="D. Franke" initials="D." surname="Franke"/>
          <author fullname="D. Sibold" initials="D." surname="Sibold"/>
          <author fullname="K. Teichel" initials="K." surname="Teichel"/>
          <author fullname="M. Dansarie" initials="M." surname="Dansarie"/>
          <author fullname="R. Sundblad" initials="R." surname="Sundblad"/>
          <date month="September" year="2020"/>
          <abstract>
            <t>This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).</t>
            <t>NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8915"/>
        <seriesInfo name="DOI" value="10.17487/RFC8915"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1bW3PbxhV+31+x4zzU7pCM7paZTKcqJbma1G5qKW1nOp3O
EliSW4FYFguIYmr/937n7C4IUCAth3loptVMEhLAnvv5zgVMv98XqU1yNddD
mRZqUvaNLif9vFz0q0WqSt0v9NS4sjDa9Q/PhL/ohvL0zcFpj/591pPnp6+P
e/L1+dER//tQlKbMQPAHetjkU1nOtHx/9738UNMSCchMbbEaSlemAhe1mg/l
zdXdtVja4n5a2GoxlJBDmEUxlGVRufLo4ODNwZHA0ypP/6Eym4PJCsQWZiik
LG3iv0rpbAGKE1d/X82bXxM7X6ikrO9W4/pKboW41yvIkA7l3yB0T+rHUufO
2Nz15NoaPXlz8f7i70KoqpzZggTo4x8pvTE/mGQmb1X2I1+zxXQoL+7VXBl5
p5NZbjM7NcxcSo2r2VAWDk//VvFDA8gjclvMYb8HTbQ/XI/I5MP4ob50Fi+d
+UvkgGH8UF86ipeO/KXzwyN/kD6ES/DiMH4Il94ceo70QYh+vy/VGOrDUkLc
kVN1Sd6Sd2au5feFhQtsJl/CbK8kfNS+f6uTqjDliu7fvpKIu2qu89KJVE9M
rqWSeTUf60LaiVTOmWmu03ipaXewyHRChslWMlH4ksYIE+vnBkLcWnBdX5Ez
9aDlsrCIyAeVVUTLtR9BMiACSjkBC7uUkLeAhBQvc5vLBSluEt1j3fioKrT8
J0JTFmY6Kwfi2hYsi1P3mvSguMo04kc7cCtnxtV6g+2D0UsnoQFnBxvs7rap
q6Brc9ByMmSeXM40eOY6AUVVrAbkiCbV+By8FpI0fDrzn3yy0iefsOAgwrfD
gffx3KRppoX4St7kZWHTClrb/Bfg8buAMw2fJypnA481nFpBQFWKb2dluXDD
r79eLpcDo3I1QH5+7QVg+b4m/FuoAplc6mLz6+BxVs6z37BvvBS3PwdH/ifQ
/l8KXi3HVXZP/NocyI6wYWoeTAp/m7y0ErEl4YjSDRGp8toUrgQ+K0Bt4Lvq
SVOCCMUXVZ5IzWutAPXzORgTNzwn3Cov1aM04YROByCLqLV52mNTkJoO3CeM
xUwE1NghuNRmjQN4xDgx1sR6blMzMSS5k26hE/4yoKy6esTz9EijHvosdppT
DdK4pDBjcPFC1FEQY66osiACvs0H4oYYk410TsaCqcaUXg6VqWwqze71ShOp
QFlxfhf6X5UpNMfjU+18djkUqxxh5CVZxPzHB3Ip6bSWrG0c4EqwT0/MEJ7w
rqHwInbMXyI+OUJycMlTomUJBhKNCMAXldcawJJZ6kBSUAhTzEeDpZIijKz8
Faw7wec80fLmsie/M8717a/6l1qVMyH+/e9QSD99ir7n6Frb+htm1SQC+1Jw
sLCvB8e96A3Rot1+6mQg5e8srnrRnc86RRla+wkwUciL29HNjUhmivIUKPMN
Aj0lX4IMe5xyVC4NSOF0f4zw7f+oCyvNpJlQVyE62dZolIpw5uDx9NyHtGeE
vAYXJOZCF4mCWH/tsWQFRCwefMQD380D8pb8cPWIBw07K5M/OJiYtWqGZkGO
QUb2EwIX/9ETG0iKHc6hTFKYaYAOdPeGFxsxzoEsawf1amsenn365F17FVsy
YABCQd6tFpRDHWdeD1oeBieb9/Gf/tIUOqY1fFM3eSIE17hCVJmUoytBd1pS
PtXRvM68mulZQ9Bj8CRb4Uvg2ilxA7UolKKUphQGCYDQL1Hvxqs1nB0fNLpR
+fLwwCfZhBOFzUotqlvgrgd6oYuCb/prrxgpolrIWsJW6BVc4/mwCiHTkNzV
PGeHNLyEOOvS+gBau0VGAEwPrxX14M1hjl7bG7gnbJ55Q1YIPwrSwOSiKi1a
8Iam0crUo4CHzws0D3rJaAzzjWY6uQfOyZGNoNKjCGuZXnSZvkH7CLSTTBUe
tuloJ651urInqC6ZpMJ5qKUKLv1Eg0CZay8OcCrSxXeUr1PWdUZxkngIHlm4
4+W7i9Erj3EDqq0PJ4CC5F7DrHOF/sciB2EqJfGcz3OFLFZFKK+wK8xpK0im
kbRJyQxzWHNtUU8dWKlSXUQLUGdIFpipfBr0T4rVorTTQi1mK3JTGgOBWHsJ
42FMCLVr2NPRO4xG9hlJELoB376QyWH9MXzpIDceWBsvdjbxIDcD7xr1IbIN
wu5my52VcEsyYmiMApncjMEfSHzweHh0fELAlOEIxZ6jayfHR77QPSoKuoGv
4UvcTCvN+Ba6D1/fOBXdWg0LSDc50q5dBwW4hxQYbPT2qOL3PreIVq5t5UIz
SBJF6O6R3ozpJceDcR3FluOGPbrOazycBnoAIHxXKZliSY/uEJjJDMTFAqnv
4ziUnzmXLG5cAycLoYLAPkL5JtA1Mz/qVJSB06qGKE4ei9JD+FtbLrVzyAGD
vKTih8cISl6JzX7CS12iag3EO5guriKemgwR46oilk2KJFcBV1VTJS8wGrcs
E9RcITTIxzztKNc3jntHCp+oIfW6c9gVLTBBXaH73lJUwbrnpGZD2EwrXxlc
PW7Exovg3G0W4RCj3GpTeLbbeKpruQ1Z7oTPzDkfrLtUnziNyKN5xKO8Q0U9
xE3g23RG1RU+yJOschjOXoX0b2S9jq1uezCvi/NZqK0RztcFkdT8DpFwBfuN
odKMM+ADevOihlz2FuNujDq9OUe6MDjMCk2zxIS7ubLd+C4svGxoq0X7J/Cg
0QZ1zZvD+x9XuTtOfane2Rk19Hu9U7/3BMpxiI76ODM3voh8RrMWo/OaEXWx
DVY8QBOzK+4EqMK4elr7iyq4r+Cr3S2dypxdSxLwwmEUBtCteJzhNR9utKeZ
JpBPEXsFrDOt0G5kHMmUWiuKEBogGyyrQIyil3H96kEXqzVYh4wFgbVQn+9V
iU4ISgYR7oHjGOFniCXyZm5K35Sv22LfJzsimwL9SlQDf0xwc03abfTXm2fl
i7++2Nlbi055yYIcmL5H0m0zIDdJ5K0hWg+0IrbStOhb92onA99LE5ebq9u3
RDB0kN4CycxariCcN5oij/1CLQXm714A4yUNMDBCHB75LHyLzrLVL3u4Gci3
iABF0xTpxBgbCNLcPAWG0MyPqIFoV9TZcnvXmO5CRUcX2XcRkPjA5vgbQS9b
QbRFphLt62bEI0+4rigc0LS59ehciwlKl2vlr7ys3mxPjSJfXl69opmbCgXN
dQqZbFTh2dRe+PSpJ5vNYp3FpwN5EUpQUY+drpoCp0vng+vyKtJXLgFPFQzC
etHz1D3QmsOUXKBcM0A8dCGQzCQuK3htsKgAsAl1rQ8K0INzfmC7vOLegQDA
d5IxNNBr+0aMmuWS265FVSwoYIgD9fOhhapjSiTU2i6soSWXEDc51QrjpQqK
Gddi88SArYrUE7VqGQEJSOB2aSlawiONZQDv6oFy6AJT7VHf+TLMbyXqET+l
Xhz5HXDSO7pZK/xEkKJXIHHrVtluycSQYe9tufl8Qc2VcgEk/T7LY/MY7PK8
Bha2c9wKEJY8hRK9xg+uZ36WfEBaLLh4e+0TlVOr5KtIHF7vGjMe0Y0j6IZk
N5fyZczwV0MeGKuiP16Vodl55q5i4JOaz1lqTikKcz7MGzPaRVJrlQeAfgKl
NQozRI4yi0B0EAW+a8p3IcfAekQg1VcPHovmVHtzyefXjm8e5rmPM0KFXVwY
vuuTd5tAUndeeoKmOg9uHtQR1t4P/T+0/vtD651WbKdfQHBt2YX9POG1rkP1
woeWPHWJY9/0aAcJ9HeGSsdm80c9AkVpaCfpQNjer2fxuF4iodBKXR8cHNQz
Br7ij4baMGa0mynREaby+WHKLS+1wiNr742vX3EBFZc0H8LGkofVultYy/8N
NVnx/YovU9yfldSk+h0GRX29uW5s0ZeG3xSJlN4szTk/xqsQwPyiI0bV3MtS
t4YvPjTT1Jc+k1DuO9S2FyTAhEN6EhxI2V8utWbFRT3Kt1cUpP3GFL3eRkj/
Pqe4d+ILVxCyawUhPrOCkLtWEJuzfhisn4k5jc1kO7MRq03ogRIz/ahSJMhc
ZS1g+BJE8E4vwe6nIkOLAinpuztu2rm5TdeIvs68gB4DwdG/2eHHtvgF75iQ
3C/WNBDKFYKD3gvHN7TUW8YJFEJ8bBrxY22WXX8fG5p/FB+H/fVf68vWv+ZT
IABkOCCg8LRHvKrsv7/47hupWltVtJEmI9wjCcJbcSlrAke1cDsSqlYhGqsm
cLg/gZNw64fcwD/NLrTTiPQS/81h4x3H6eA4Ejuq7fHe9v+4CL1ujWCdxAjU
5ZrAYbh14ZxNjD+/iYQ7CUR7jDCf+MKiv4zAcSTgIXnb2e0EokG3AfmzCTQK
w9a/bo+crImdhsf+oNXC8btl92X2OAu3bqls7bTGFgKvw62b6+sQXeVWo3QS
OA+33v7ps+e7CbwJt979+ScRON43yY67XPo94d/MZulmpnW79DQSO9lXmpOW
NI13QKBCRfYq5xcvvHFoNXdui2hnkfLpvqKd7Uvg9b4E3uxJABAYM+6Hy++7
3gx2+JreLEYC5/vWhPN9a8L5Vhj3r3Hb0dqRMOefg/E2nU4Cu2H8GQS2wniH
Ep0EtsP4UwqdBHYj7zNU2IK8z/fCZ5C3RaiTwG7kfYYKu5H3swT2Rd7zfcHy
fF9IO98X0s73hbTz830J7IuJo30hbbQvpI22QJp/K/UkpZ5G4mg3pG3S6SSw
C9KeRWALpHUq0UlgG6R1UegksAvSnqVCJ6R9iRd2QtoGoU4CuyDtWSrsgrRn
ENgX0kb7QtpoX0gb7Qtpo30hbbQvpI32hTTaEfa/HRe/8fvBDlKbr1U7SYmv
1r++2Hw/1P7xjUpTWurxu3UXjyStI72w5ls1l08iLDdrQrz3av6io/5Z1kBC
GN3+3akLC62wTBL8cnVRGMIu3gLx+62L5D63y0ynU//7Xb8lmmv/E4iwh6Jt
8V+s/x3MW/ofbORMZwv+bcKUfjwAoWjL9d767RL90KwwYyAV/4oiyaqUXsn/
Wr4zhXWZepB/MMnsQRU9SJvK36sS9y5VjkFFXhcqv9c9/mGh5h/ElZ3//wsf
yJG+aqVBp/WrmGv6CZ1fFRLPBMJCqpEtS3pp2KRM+y08c6fmOHZpSoidzHry
bql1quVbm03EfwCfoe+j6jQAAA== best practice.
-->

  </back>
</rfc>