<?xml version='1.0' encoding='utf-8'?> 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.2 (Ruby 3.0.2) -->
<?rfc strict="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-uuidrev-rfc4122bis-14" number="9562" submissionType="IETF" category="std" consensus="true" submissionType="IETF" obsoletes="4122" updates="" tocDepth="3" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->

  <front>
    <title abbrev="UUID">Universally abbrev="UUIDs">Universally Unique IDentifiers (UUID)</title> (UUIDs)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-uuidrev-rfc4122bis-14"/> name="RFC" value="9562"/>
    <author initials="K. R." initials="K." surname="Davis" fullname="Kyzer R. Davis">
      <organization>Cisco Systems</organization>
      <address>
        <email>kydavis@cisco.com</email>
      </address>
    </author>
    <author initials="B. G." initials="B." surname="Peabody" fullname="Brad G. Peabody">
      <organization>Uncloud</organization>
      <address>
        <email>brad@peabody.io</email>
      </address>
    </author>
    <author initials="P." surname="Leach" fullname="P. Leach">
      <organization>University of Washington</organization>
      <address>
        <email>pjl7@uw.edu</email>
      </address>
    </author>
    <date year="2023"/>
    <area>ART</area> year="2024" month="April"/>
    <area>art</area>
    <workgroup>uuidrev</workgroup>
    <keyword>uuid</keyword>
    <abstract>
      <?line 274?>

<t>This

<!--[rfced] We have the following questions/comments about this text
     in the Abstract and Introduction:

Original:
   This specification defines the UUIDs (Universally Unique IDentifiers)
   and the UUID Uniform Resource Name (URN) namespace.  UUIDs are also
   known as GUIDs (Globally Unique IDentifiers).

a) to reduce redundancy and align with the same text in RFC 4122, we have updated this text as follows.

Current:
   This specification defines a Uniform Resource Name namespace for
   Universally Unique IDentifiers (UUIDs) (also known as Globally
   Unique IDentifiers (GUIDs)).

b) Because this is the only mention of "URN namespace" in the document:

Original:
  The IANA URN namespace registration [URNNamespaces] for UUID filed in
  [RFC4122] should be updated to reference this document.

please confirm that this sentence should appear as is.

-->

    <abstract>
      <t>This specification defines UUIDs (Universally Unique IDentifiers)
      (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
      Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to
      guarantee uniqueness across space and time.  UUIDs were originally used
      in the Apollo Network Computing System and (NCS), later in the Open Software
      Foundation's (OSF) (OSF's) Distributed Computing Environment (DCE), and then
      in Microsoft Windows platforms.</t>
      <t>This

<!--[rfced] We had a few questions regarding the use of "DCE
     specification" in the document:

a) Will the reader understand what the "DCE specification" refers to
in the sentences below?  Or should some sort of citation be added?

b) Do "DCE specification" and "OSF DCE specification" refer to the
same thing?

Original:
   This specification is derived from the DCE specification with the
   kind permission of the OSF (now known as The Open Group).

Original:
   Information from earlier versions of the DCE specification have been
   incorporated into this document.

Original:
   This document draws heavily on the OSF DCE specification for UUIDs.

-->

      <t>This specification is derived from the OSF DCE specification with the
      kind permission of the OSF (now known as "The Open Group").  Information
      from earlier versions of the OSF DCE specification have been incorporated
      into this document. This document obsoletes RFC4122.</t> RFC 4122.</t>
    </abstract>
  </front>
  <middle>
    <?line 288?>

<section anchor="Background">
      <name>Introduction</name>
      <t>This specification defines the UUIDs (Universally Unique IDentifiers) and the UUID a Uniform Resource Name (URN) namespace. UUIDs are also namespace for
   Universally Unique IDentifiers (UUIDs) (also known as GUIDs (Globally Globally
   Unique IDentifiers). IDentifiers (GUIDs)).  A UUID is 128 bits long and
      requires no central registration process.</t>
      <t>The use of UUIDs is extremely pervasive in computing.  They comprise
      the core identifier infrastructure for many operating systems such as
      Microsoft Windows and applications such as the Mozilla Web browser and browser;
      in many cases, they can become exposed in many non-standard ways.</t>
      <t>This specification attempts to standardize that practice as openly as
      possible and in a way that attempts to benefit the entire Internet.  The information
      here is meant to be a concise guide for those wishing to implement
      services using UUIDs either in combination with URNs <xref
      target="RFC8141"/> or otherwise.</t>
      <t>There is an ITU-T Recommendation and an ISO/IEC Standard <xref
      target="X667"/> that are derived from <xref target="RFC4122"/>.  Both
      sets of specifications have been aligned and are fully technically
      compatible.  Nothing in this document should be construed to override
      the DCE standards that defined UUIDs.</t>
    </section>
    <section anchor="motivation">
      <name>Motivation</name>
      <t>One of the main reasons for using UUIDs is that no centralized
      authority is required to administer them (although two formats may
      leverage optional IEEE 802 node identifiers, Node IDs, others do not).  As a
      result, generation on demand can be completely automated and used for a
      variety of purposes.  The UUID generation algorithm described here
      supports very high allocation rates of 10 million per second per machine
      or more more, if necessary, so that they could even be used as transaction
      IDs.</t>
      <t>UUIDs are of a fixed size (128 bits), which is reasonably small
      compared to other alternatives.  This lends itself well to sorting,
      ordering, and hashing of all sorts, sorts; storing in databases, databases; simple
allocation,
      allocation; and ease of programming in general.</t>
      <t>Since UUIDs are unique and persistent, they make excellent Uniform
Resource Names. URNs.
      The unique ability to generate a new UUID without a
      registration process allows for UUIDs to be one of the URNs with the
      lowest minting cost.</t>
      <section anchor="update-motivation">
        <name>Update Motivation</name>
        <t>Many things have changed in the time since UUIDs were originally
        created.  Modern applications have a need to create and utilize UUIDs
        as the primary identifier for a variety of different items in complex
        computational systems, including but not limited to database keys,
        file names, machine or system names, and identifiers for event-driven
        transactions.</t>
        <t>One area in which UUIDs have gained popularity is database keys.
        This stems from the increasingly distributed nature of modern
        applications.  In such cases, "auto increment" "auto-increment" schemes that are often
        used by databases do not work
well, as well: the effort required to
        coordinate sequential numeric identifiers across a network can easily
        become a burden.  The fact that UUIDs can be used to create unique,
        reasonably short values in distributed systems without requiring
        coordination makes them a good alternative, but UUID versions 1-5,
        which were originally defined by <xref target="RFC4122"/>, lack
        certain other desirable characteristics:</t> characteristics, such as:</t>
        <ol spacing="normal" type="1"><li>
            <t>Non-time-ordered UUID type="1">
	  <li>UUID versions that are not time ordered, such as UUIDv4 (described in
	  <xref target="uuidv4"/>) target="uuidv4"/>), have poor database index database-index locality.  This
	  means that new values created in succession are not close to each
	  other in the index and thus index; thus, they require inserts to be performed at
	  random locations.  The resulting negative performance effects on the
	  common structures used for this (B-tree and its variants) can be dramatic.</t>
          </li>
          <li>
            <t>The
	  dramatic.</li>
          <li>The 100-nanosecond Gregorian epoch Epoch used in UUIDv1 timestamps (described in
          <xref target="uuidv1"/>) timestamps is uncommon and difficult to
          represent accurately using a standard number format such as that
          described in <xref target="IEEE754"/>.</t>
          </li>
          <li>
            <t>Introspection/parsing target="IEEE754"/>.</li>
          <li>Introspection/parsing is required to order by time sequence, as
          opposed to being able to perform a simple byte-by-byte comparison.</t> comparison.
          </li>
          <li>
            <t>Privacy
          <li>Privacy and network security issues arise from using a MAC Media Access Control (MAC)
          address in the node field of UUID version 1. UUIDv1.  Exposed MAC addresses
          can be used as an attack surface to locate network interfaces and
          reveal various other information about such machines (minimally manufacturer, potentially (minimally, the
          manufacturer and, potentially, other details). Additionally, with the
          advent of virtual machines and containers, uniqueness of the MAC address uniqueness is
          no longer guaranteed.</t>
          </li>
          <li>
            <t>Many guaranteed.</li>
          <li>Many of the implementation details specified in <xref
          target="RFC4122"/> involved trade
  offs trade-offs that are neither possible to
          specify for all applications nor necessary to produce interoperable implementations.</t>
          </li>
          <li>
            <t><xref
          implementations.</li>
          <li><xref target="RFC4122"/> did not distinguish between the
          requirements for generating a UUID and those for simply storing one,
          although they are often different.</t> different. </li>
        </ol>

        <t>Due to the aforementioned issues, many widely distributed database applications
and large application vendors have sought to solve the problem of creating
a better
time-based, sortable unique identifier for use as a database key. This has
led to numerous implementations
over the past 10+ years solving the same problem in slightly different ways.</t>
        <t>While preparing this specification, the following 16 different implementations
were analyzed for trends in total ID length, bit layout, lexical formatting/encoding, formatting and encoding,
timestamp type, timestamp format, timestamp accuracy, node format/components, format and components,
collision handling, and multi-timestamp tick generation sequencing:</t>
        <ol spacing="compact" type="1"><li>
            <t><xref target="ULID"/>

<!-- [rfced] We have cut author names in this list as readers can find
     this information in full using the citation tag.  Please let us
     know any objections.

Original:
   1.   [ULID] by A. Feerasta</t>
          </li>
          <li>
            <t><xref target="LexicalUUID"/> by Twitter</t>
          </li>
          <li>
            <t><xref target="Snowflake"/> by Twitter</t>
          </li>
          <li>
            <t><xref target="Flake"/>  Feerasta
   2.   [LexicalUUID] by Twitter
   3.   [Snowflake] by Twitter
   4.   [Flake] by Boundary</t>
          </li>
          <li>
            <t><xref target="ShardingID"/> Boundary
   5.   [ShardingID] by Instagram</t>
          </li>
          <li>
            <t><xref target="KSUID"/> by Segment</t>
          </li>
          <li>
            <t><xref target="Elasticflake"/> Instagram
   6.   [KSUID] by Segment
   7.   [Elasticflake] by P. Pearcy</t>
          </li>
          <li>
            <t><xref target="FlakeID"/>  Pearcy
   8.   [FlakeID] by T. Pawlak</t>
          </li>
          <li>
            <t><xref target="Sonyflake"/> by Sony</t>
          </li>
          <li>
            <t><xref target="orderedUuid"/>  Pawlak
   9.   [Sonyflake] by Sony
   10.  [orderedUuid] by IT. Cabrera</t>
          </li>
          <li>
            <t><xref target="COMBGUID"/>  Cabrera
   11.  [COMBGUID] by R. Tallent</t>
          </li>
          <li>
            <t><xref target="SID"/>  Tallent
   12.  [SID] by A. Chilton</t>
          </li>
          <li>
            <t><xref target="pushID"/> by Google</t>
          </li>
          <li>
            <t><xref target="XID"/>  Chilton
   13.  [pushID] by Google
   14.  [XID] by O. Poitrey</t>
          </li>
          <li>
            <t><xref target="ObjectID"/>  Poitrey
   15.  [ObjectID] by MongoDB</t>
          </li>
          <li>
            <t><xref target="CUID"/> MongoDB
   16.  [CUID] by E. Elliott</t>
          </li>  Elliott

Current:
   1.   [ULID]
   2.   [LexicalUUID]
   3.   [Snowflake]
   4.   [Flake]
   5.   [ShardingID]
   6.   [KSUID]
   7.   [Elasticflake]
   8.   [FlakeID]
   9.   [Sonyflake]
   10.  [orderedUuid]
   11.  [COMBGUID]
   12.  [SID]
   13.  [pushID]
   14.  [XID]
   15.  [ObjectID]
   16.  [CUID]
-->

<ol spacing="compact" type="1">
	  <li><xref target="ULID"/></li>
          <li><xref target="LexicalUUID"/></li>
          <li><xref target="Snowflake"/></li>
          <li><xref target="Flake"/></li>
          <li><xref target="ShardingID"/></li>
          <li><xref target="KSUID"/></li>
          <li><xref target="Elasticflake"/></li>
          <li><xref target="FlakeID"/></li>
          <li><xref target="Sonyflake"/></li>
          <li><xref target="orderedUuid"/></li>
          <li><xref target="COMBGUID"/></li>
          <li><xref target="SID"/></li>
          <li><xref target="pushID"/></li>
          <li><xref target="XID"/></li>
          <li><xref target="ObjectID"/></li>
          <li><xref target="CUID"/></li>
        </ol>

        <t>An inspection of these implementations and the issues described
        above has led to this document document, in which intends to adapt new UUIDs are adapted to
        address these issues.</t>
        <t>Further, <xref target="RFC4122"/> itself was in need of an overhaul to
        address a number of topics such as, but not limited to, the
        following:</t>

<!--[rfced] We suggest listing the EIDs that this text is referring to
     for clarity.  Please let us know which errata apply in this sentence.

Original:

   Further, [RFC4122] itself was in need an overhaul to address a number
   of topics such as but not limited to the following:</t>
        <ol spacing="normal" type="1"><li>
            <t>Miscellaneous following:

   1.  Miscellaneous erratas.  Mostly around bit layout clarifications
       which lead to inconsistent implementations.</t>
          </li>
          <li>
            <t>Decouple implementations.

Perhaps (with corresponding errata reference entries as described at
https://www.rfc-editor.org/styleguide/part2/#ref_errata):

   Further, [RFC4122] itself was in need an overhaul to address a number
   of topics such as, but not limited to, the following:

   1.  Implementation of miscellaneous errata reports (mostly bit-layout
       clarifications that lead to inconsistent implementations):
       [Err####], [Err###1], etc.

-->

        <ol spacing="normal" type="1">
	  <li>Implementation of miscellaneous errata reports. Mostly around
	  bit-layout clarifications, which lead to inconsistent
	  implementations <xref target="Err1957"/>, <xref target="Err3546"/>,
	  <xref target="Err4975"/>, <xref target="Err4976"/>, <xref
	  target="Err5560"/>, etc.</li>
          <li>Decoupling other UUID versions from the UUIDv1 bit layout so that
          fields like "time_hi_and_version" do not need to be referenced
          within a non-time-based UUID that is not time based while also providing "UUIDv1 like"
          definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and UUIDv5.</t>
          </li>
          <li>
            <t>Provide UUIDv5.</li>
          <li>Providing implementation best practices around many real-world
          scenarios and corner cases observed by existing and prototype implementations.</t>
          </li>
          <li>
            <t>Update the document to address
          implementations.</li>
          <li>Addressing security best practices and
          considerations for the modern age as it pertains to MAC addresses,
          hashing algorithms, secure randomness, and other topics.</t>
          </li>
          <li>
            <t>Provide topics.</li>
          <li>Providing implementations a standard-based option for implementation specific
          implementation-specific and/or experimental UUID designs.</t>
          </li>
          <li>
            <t>Provide designs.</li>
          <li>Providing more test vectors that illustrate real UUIDs created as
          per the specification.</t>
          </li> specification.</li>
        </ol>

      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <section anchor="requirements_language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.</t>
        <?line -18?>
      </section>
      <section anchor="acronyms">
        <name>Abbreviations</name>
        <t>The following abbreviations are used in this document:</t>
        <dl indent="14">
          <dt>UUID</dt>
          <dd>
            <t>Universally Unique Identifier</t>
          </dd>
          <dt>UUIDv1</dt>
          <dd>
            <t>Universally

<!-- [rfced] Regarding text in the "Abbreviations" section:

a) Would you like the abbreviations in Section 3.2 to be alphabetized?

b) Regarding UUID and its versions:

i) Is it necessary to list all of the versions with UUID?  This seems
common notation in RFCs.

Current:

   UUIDv1        Universally Unique Identifier Version 1</t>
          </dd>
          <dt>UUIDv2</dt>
          <dd>
            <t>Universally 1

   UUIDv2        Universally Unique Identifier Version 2</t>
          </dd>
          <dt>UUIDv3</dt>
          <dd>
            <t>Universally 2

   UUIDv3        Universally Unique Identifier Version 3</t>
          </dd>
          <dt>UUIDv4</dt>
          <dd>
            <t>Universally 3

   UUIDv4        Universally Unique Identifier Version 4</t>
          </dd>
          <dt>UUIDv5</dt>
          <dd>
            <t>Universally 4

   UUIDv5        Universally Unique Identifier Version 5</t>
          </dd>
          <dt>UUIDv6</dt>
          <dd>
            <t>Universally 5

   UUIDv6        Universally Unique Identifier Version 6</t>
          </dd>
          <dt>UUIDv7</dt>
          <dd>
            <t>Universally 6

   UUIDv7        Universally Unique Identifier Version 7</t>
          </dd>
          <dt>UUIDv8</dt>
          <dd>
            <t>Universally 7

   UUIDv8        Universally Unique Identifier Version 8</t>
          </dd>
          <dt>URN</dt>
          <dd>
            <t>Uniform Resource Names</t>
          </dd> 8

ii) Throughout the text, we will update instances of "UUID version #"
to instead read as "UUIDv#" unless we hear objection.

c) We note that the abbreviation for SHA-1 contains a number of bits.
This leads us to a few questions:

i) Is this convoluting the 1:1 relationship between initialism and
expansion?  That is, the other SHA abbreviations have a bit size that
correlates to their abbreviation.

Perhaps:
SHA-1     Secure Hash Algorithm 1

or

Perhaps:
SHA-1     Secure Hash Algorithm 1 (160 bits)

ii) If a bit size is included for SHA-1, should a bit size be included
for SHA-3?

d) We had the following questions/comments about the abbreviation MSB
(Most Significant Bit):

i) Please note that we have lowercased "Most Significant Byte" to
avoid confusion with this abbreviation.

ii) The tables in Sections 4.1 & 4.2 use "Msb#" format.  Should these be
made "MSB#"?

iii) To match the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we generally
use an abbreviation (instead of the expansion) once it has been
introduced.  However, we often see the expansion of MSB with text
interjected.  Should updates like the following be made (just
examples, not all cases listed)?

Original:
the most significant 4 bits

the most significant 12 bits

first 48 most significant bits

The most significant 32 bits

Perhaps:
the 4 MSBs

the 12 MSBs

first 48 MSBs

The 32 MSBs

-->

        <dl newline="false" spacing="normal" indent="14">
	  <dt>ABNF</dt>
          <dd>
            <t>Augmented <dd>Augmented Backus-Naur Form</t>
          </dd> Form</dd>
	  <dt>CSPRNG</dt>
          <dd>
            <t>Cryptographically <dd>Cryptographically Secure Pseudo-Random Pseudorandom Number Generator</t>
          </dd>
          <dt>MAC</dt>
          <dd>
            <t>Media Access Control</t>
          </dd>
          <dt>MSB</dt>
          <dd>
            <t>Most Significant Bit</t>
          </dd> Generator</dd>
	  <dt>DBMS</dt>
          <dd>
            <t>Database <dd>Database Management System</t>
          </dd> System</dd>
	  <dt>IEEE</dt>
          <dd>
            <t>Institute <dd>Institute of Electrical and Electronics Engineers, Inc.</t>
          </dd> Engineers</dd>
	  <dt>ITU</dt>
          <dd>
            <t>International <dd>International Telecommunication Union</t>
          </dd> Union</dd>
	  <dt>MAC</dt> <dd>Media Access Control</dd>
	  <dt>MD5</dt>
          <dd>
            <t>Message <dd>Message Digest 5</t>
          </dd> 5</dd>
	  <dt>MSB</dt> <dd>Most Significant Bit</dd>
	  <dt>OID</dt> <dd>Object Identifier</dd>
	  <dt>SHA</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm</t>
          </dd> Algorithm</dd>
	  <dt>SHA-1</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm 1 with (with message digest of 160 bits</t>
          </dd> bits)</dd>
	  <dt>SHA-3</dt> <dd>Secure Hash Algorithm 3 (arbitrary size)</dd>
	  <dt>SHA-224</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm 2 with message digest size of 224 bits</t>
          </dd> bits</dd>
	  <dt>SHA-256</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm 2 with message digest size of 256 bits</t>
          </dd> bits</dd>
	  <dt>SHA-512</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm 2 with message digest size of 512 bits</t>
          </dd>
          <dt>SHA-3</dt>
          <dd>
            <t>Secure Hash Algorithm 3</t>
          </dd> bits</dd>
	  <dt>SHAKE</dt>
          <dd>
            <t>Secure <dd>Secure Hash Algorithm 3 based on the KECCAK algorithm</t>
          </dd> algorithm</dd>
	  <dt>URN</dt> <dd>Uniform Resource Names</dd>
	  <dt>UTC</dt>
          <dd>
            <t>Coordinated <dd>Coordinated Universal Time</t>
          </dd>
          <dt>OID</dt>
          <dd>
            <t>Object Identifier</t>
          </dd> Time</dd>
	  <dt>UUID</dt> <dd>Universally Unique Identifier</dd>
	  <dt>UUIDv1</dt> <dd>Universally Unique Identifier version 1</dd>
	  <dt>UUIDv2</dt> <dd>Universally Unique Identifier version 2</dd>
	  <dt>UUIDv3</dt> <dd>Universally Unique Identifier version 3</dd>
	  <dt>UUIDv4</dt> <dd>Universally Unique Identifier version 4</dd>
	  <dt>UUIDv5</dt> <dd>Universally Unique Identifier version 5</dd>
	  <dt>UUIDv6</dt> <dd>Universally Unique Identifier version 6</dd>
	  <dt>UUIDv7</dt> <dd>Universally Unique Identifier version 7</dd>
	  <dt>UUIDv8</dt> <dd>Universally Unique Identifier version 8</dd>
        </dl>
      </section>
      </section>
    <section anchor="changelog" removeInRFC="true">
        <name>Changelog</name>
        <t>draft-14</t>
        <ul spacing="compact">
          <li>
            <t>AD Review #2: IANA Subtype Modifications #170</t>
          </li>
          <li>
            <t>AD Review #2: Specify Values for Variant/Subtype Column #171</t>
          </li>
          <li>
            <t>AD Review #2: Grammar change at the end of 5.1 #172</t>
          </li>
          <li>
            <t>SHA and Integer Verbiage clarifications #174</t>
          </li>
          <li>
            <t>Disclaimer in nil/max that these do not fall into IETF variants #175</t>
          </li>
          <li>
            <t>Fix v1/v6 final anchor="format">
      <name>UUID Format</name>
      <t>The UUID in test vector #176</t>
          </li>
        </ul>
        <t>draft-13</t>
        <ul spacing="compact">
          <li>
            <t>Request IANA Registry #144</t>
          </li>
          <li>
            <t>Describe allocation logic of Namespace ID #161</t>
          </li>
          <li>
            <t>Move citation of Namesapce ID up to first instance in v3/v5 #167</t>
          </li>
          <li>
            <t>Further normalize Namespace verbiage #166</t>
          </li>
          <li>
            <t>Fix Timestamp of Time-Based UUIDv8 Example #164</t>
          </li>
          <li>
            <t>Change RFC8937 and RFC4086 to Informative References #163</t>
          </li>
          <li>
            <t>Discuss why v3/v5 are bad for Database Usage #155</t>
          </li>
        </ul>
        <t>draft-12</t>
        <ul spacing="compact">
          <li>
            <t>Typos #148 #156</t>
          </li>
          <li>
            <t>SECDIR Review #141</t>
          </li>
          <li>
            <t>SECDIR Review 2 #142</t>
          </li>
          <li>
            <t>OPSDIR Review #145</t>
          </li>
          <li>
            <t>INDIR Review 2 #140</t>
          </li>
          <li>
            <t>IESG Grammar #146</t>
          </li>
          <li>
            <t>Revise 16-bit MAC Node Usage #149</t>
          </li>
          <li>
            <t>Add MSB3 to Variant Table #153</t>
          </li>
          <li>
            <t>Additional Update Motivations #157</t>
          </li>
          <li>
            <t>Expand v8 Time-based Example to larger timestamp #159</t>
          </li>
          <li>
            <t>Fix Randomized Node value's mcast bit in Appendix #151</t>
          </li>
          <li>
            <t>Clarify "Name-Based" format is the same as "Hash-Based" #154</t>
          </li>
          <li>
            <t>Move UUIDv8 Examples out of Test Vectors #150</t>
          </li>
          <li>
            <t>Simplify UUIDv8 Hash-based Example #147</t>
          </li>
        </ul>
        <t>draft-11</t>
        <ul spacing="compact">
          <li>
            <t>Normalize "name space" to "namespace" everywhere #137</t>
          </li>
          <li>
            <t>IANA Review: Verbiage to update RFC4122 references #134</t>
          </li>
          <li>
            <t>DNSDIR re-review: Better Define "a canonical sequence of octets" #136</t>
          </li>
          <li>
            <t>Crosspost: Typo 16 octets (128 bits) in Approximate UUID timestamp calculations #135</t>
          </li>
          <li>
            <t>INTDIR Review #139</t>
          </li>
        </ul>
        <t>draft-10</t>
        <ul spacing="compact">
          <li>
            <t>ARTART Review and Feedback #130</t>
          </li>
          <li>
            <t>Clarify Hash Space IDs listed are not size; the only options #132</t>
          </li>
          <li>
            <t>Add example to timestamp fuzzing #133</t>
          </li>
        </ul>
        <t>draft-09</t>
        <ul spacing="compact">
          <li>
            <t>Late addition of IETF reference for CSPRNG guidance #123</t>
          </li>
          <li>
            <t>DNSDIR Review: Typos! #122</t>
          </li>
          <li>
            <t>DNSDIR Review: DNS Considerations Update #121</t>
          </li>
          <li>
            <t>Error in UUIDv8 Name-based Test Vector #129</t>
          </li>
          <li>
            <t>Improve consistency of layout field definitions #128</t>
          </li>
        </ul>
        <t>draft-08</t>
        <ul spacing="compact">
          <li>
            <t>Fix typos #113</t>
          </li>
          <li>
            <t>Fix errata 6225 (again) #117 #118</t>
          </li>
          <li>
            <t>AD Review: BCP 14 - <bcp14>SHOULD</bcp14> #114</t>
          </li>
          <li>
            <t>AD Review: Add proper references to v1 and v6 #116</t>
          </li>
          <li>
            <t>AD Review: Remove <bcp14>SHOULD</bcp14> in section 4 #120</t>
          </li>
          <li>
            <t>Discuss "front-loaded rollover counter" for 32-bit epoch with Padding method #115</t>
          </li>
        </ul>
        <t>draft-07</t>
        <ul spacing="compact">
          <li>
            <t>Even more grammar tweaks! #109</t>
          </li>
          <li>
            <t>Remove unnecessary "32 bit" in UUIDv7 example #108</t>
          </li>
          <li>
            <t>Change "fixed millisecond" -&gt; "millisecond by default" relating to v7 #110</t>
          </li>
          <li>
            <t>Revert Max UUID Naming #107</t>
          </li>
          <li>
            <t>Author Changes</t>
          </li>
        </ul>
        <t>draft-06</t>
        <ul spacing="compact">
          <li>
            <t>More Grammar edits! #102</t>
          </li>
          <li>
            <t>Tweak v7 description to de-emphasize optional components #103</t>
          </li>
          <li>
            <t>Better Clarify Case in ABNF #104</t>
          </li>
          <li>
            <t>Verbiage change variant bits in 6.2 #105</t>
          </li>
        </ul>
        <t>draft-05</t>
        <ul spacing="compact">
          <li>
            <t>Changed Max UUID to Max UUID to better complement Latin Nil UUID verbiage. #95</t>
          </li>
          <li>
            <t>Align Method 3 text
      conjunction with the 12 bits limitation #96</t>
          </li>
          <li>
            <t>Make Version/version casing consistent across 5. UUID Layouts #97</t>
          </li>
          <li>
            <t>Cite MS COM GUID as little-endian #95</t>
          </li>
        </ul>
        <t>draft-04</t>
        <ul spacing="compact">
          <li>
            <t>Remove extra words #82, #88, and #93</t>
          </li>
          <li>
            <t>Punctuation and minor style fixes #84</t>
          </li>
          <li>
            <t>Change rounding mode of Method 4 Section 6.2 #90 (from #86)</t>
          </li>
          <li>
            <t>Add verbal description of v7 generation to 5.7. UUID Version 7 #91</t>
          </li>
          <li>
            <t>Remove Re-randomize Until Monotonic (Method 3) from Monotonicity and Counters #92</t>
          </li>
          <li>
            <t>Fix ambiguous text around UUIDv6 clock sequence #89</t>
          </li>
          <li>
            <t>Move endianness statement from layout to format section #85</t>
          </li>
          <li>
            <t>Further modified abstract to separate URN topic from UUID definition #83</t>
          </li>
          <li>
            <t>Provided three more UUID format examples #83</t>
          </li>
          <li>
            <t>Added text further clarifying version construct is for the variant in this doc #83</t>
          </li>
          <li>
            <t>Provided further clarification for local/global bit vs multicast bit #83</t>
          </li>
        </ul>
        <t>draft-03</t>
        <ul spacing="compact">
          <li>
            <t>Revised IANA Considerations #71</t>
          </li>
          <li>
            <t>Fix "integral numbers of octets" verbiage #67</t>
          </li>
          <li>
            <t>Transpose UUID Namespaces to match UUID Hashspaces #70</t>
          </li>
          <li>
            <t>Reference all Hash Algorithms. #69</t>
          </li>
          <li>
            <t>Normalize SHA abbreviation formats #66</t>
          </li>
          <li>
            <t>Add other Hash Abbreviations #65</t>
          </li>
          <li>
            <t>Remove URN from title #73</t>
          </li>
          <li>
            <t>Move Community Considerations to Introduction #68</t>
          </li>
          <li>
            <t>Move some Normative Reference to Informative #74</t>
          </li>
          <li>
            <t>Misc formatting changes to address IDNITS feedback</t>
          </li>
          <li>
            <t>Downgrade <bcp14>MUST NOT</bcp14> to <bcp14>SHOULD NOT</bcp14> for guessability of UUIDs #75</t>
          </li>
          <li>
            <t>Misc. text formatting, typo fixes #78</t>
          </li>
          <li>
            <t>Misc. text clarifications #79</t>
          </li>
          <li>
            <t>Misc. <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> adjustments #80</t>
          </li>
          <li>
            <t>Method 3 and 4 added to monotonic section #81</t>
          </li>
        </ul>
        <t>draft-02</t>
        <ul spacing="compact">
          <li>
            <t>Change md5_high in SHA-1 section to sha1_mid #59</t>
          </li>
          <li>
            <t>Describe Nil/Max UUID bits described in variant table #16</t>
          </li>
          <li>
            <t>Further Clarify that non-descript node IDs are the preferred method in distributed UUID Generation #49</t>
          </li>
          <li>
            <t>Appendix B, consistent naming #55</t>
          </li>
          <li>
            <t>Remove duplicate ABNF from IANA considerations #56</t>
          </li>
          <li>
            <t>Monotonic Error Checking missing newline #57</t>
          </li>
          <li>
            <t>More Security Considerations Randomness #26</t>
          </li>
          <li>
            <t>SHA-256 UUID Generation #50</t>
          </li>
          <li>
            <t>Expand multiplexed fields within v1 and v6 bit definitions #43</t>
          </li>
          <li>
            <t>Clean up text in UUIDs that Do Not Identify next sections
      determine finer structure.

<!-- [rfced] To avoid personifying the Host #61</t>
          </li>
          <li>
            <t>Revise "bit definitions", may we
     update "While discussing UUID Generator States section #47</t>
          </li>
          <li>
            <t>Expand upon why unix epoch rollover is not a problem #44</t>
          </li>
          <li>
            <t>Delete Sample Code Appendix #62</t>
          </li>
        </ul>
        <t>draft-01</t>
        <ul spacing="compact">
          <li>
            <t>Mixed Case Spelling error #18</t>
          </li>
          <li>
            <t>Add "UUIDs that Do Not Identify the Host as well" reference formats..." to security considerations #19</t>
          </li>
          <li>
            <t>Out "In terms of Place Distributed node text #20</t>
          </li>
          <li>
            <t>v6 clock_seq and node usage ambiguity #21</t>
          </li>
          <li>
            <t>Figure 2 and 3 Fix Title #22</t>
          </li>
          <li>
            <t>Move Namespace Registration Template to IANA Considerations #23</t>
          </li>
          <li>
            <t>Verify ABNF formatting against RFC5234 #24</t>
          </li>
          <li>
            <t>Bump ABNF reference to RFC 5234 #25</t>
          </li>
          <li>
            <t>Modify v8 <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> #27</t>
          </li>
          <li>
            <t>Remove "time-based" constraint from version 8 these
     UUID #29</t>
          </li>
          <li>
            <t>Further clarify v7 field description #125 #30</t>
          </li>
          <li>
            <t>Typo: Section 4.2, Version Field, "UUID from in this" #33</t>
          </li>
          <li>
            <t>Create better ABNF to represent Hex Digit #39</t>
          </li>
          <li>
            <t>Break Binary form of formats..."?

Current:
   The UUID into two lines. #40</t>
          </li>
          <li>
            <t>Move octet text from section 4 to section 5 #41</t>
          </li>
          <li>
            <t>Add forward reference to UUIDv1 and UUIDv4 in Section 2 #42</t>
          </li>
          <li>
            <t>Erroneous reference to v1 in monotonicity #45</t>
          </li>
          <li>
            <t>Add Label for "Monotonic Error Checking" paragraph to frame the topic #46</t>
          </li>
          <li>
            <t>Remove IEEE paragraph from "uuids that do not identify the host" #48</t>
          </li>
          <li>
            <t>Grammar Review #52</t>
          </li>
        </ul>
        <t>draft-00</t>
        <ul spacing="compact">
          <li>
            <t>Merge RFC4122 with draft-peabody-dispatch-new-uuid-format-04.md</t>
          </li>
          <li>
            <t>Change: Reference RFC1321 to RFC6151</t>
          </li>
          <li>
            <t>Change: Reference RFC2141 to RFC8141</t>
          </li>
          <li>
            <t>Change: Reference RFC2234 to RFC5234</t>
          </li>
          <li>
            <t>Change: Reference FIPS 180-1 to FIPS 180-4 for SHA-1</t>
          </li>
          <li>
            <t>Change: Converted UUIDv1 to match UUIDv6 section from Draft 04</t>
          </li>
          <li>
            <t>Change: Trimmed down the ABNF representation</t>
          </li>
          <li>
            <t>Change: http websites to https equivalent</t>
          </li>
          <li>
            <t>Errata: Bad Reference to RFC1750 | 3641 #4</t>
          </li>
          <li>
            <t>Errata: Change MD5 website to example.com | 3476 #6 (Also Fixes Errata: Fix uuid_create_md5_from_name() | 1352 #2)</t>
          </li>
          <li>
            <t>Errata: Typo format is 16 octets (128 bits) in code comment | 6665 #11</t>
          </li>
          <li>
            <t>Errata: Fix BAD OID acronym | 6225 #9</t>
          </li>
          <li>
            <t>Errata: Incorrect Parenthesis usage Section 4.3 | 184 #5</t>
          </li>
          <li>
            <t>Errata: Lexicographically Sorting Paragraph Fix | 1428 #3</t>
          </li>
          <li>
            <t>Errata: Fix 4.1.3 reference to size; the correct bits | 1957 #13</t>
          </li>
          <li>
            <t>Errata: Fix reference to variant in octet 8 | 4975 #7</t>
          </li>
          <li>
            <t>Errata: Further clarify 3rd/last bit of Variant for spec | 5560 #8</t>
          </li>
          <li>
            <t>Errata: Fix clock_seq_hi_and_reserved most-significant bit verbiage | 4976 #10</t>
          </li>
          <li>
            <t>Errata: Better Clarify network byte order when referencing most significant bits | 3546 #12</t>
          </li>
          <li>
            <t>Draft 05: B.2. Example of a UUIDv7 Value two "var"
   in table #120</t>
          </li>
          <li>
            <t>Draft 05: <bcp14>MUST</bcp14> verbiage conjunction with the version bits described in Reliability of 6.1 #121</t>
          </li>
          <li>
            <t>Draft 05: Further discourage centralized registry for distributed the next sections
   determine finer structure.  While discussing UUID Generation.</t>
          </li>
          <li>
            <t>New: Further Clarity of exact octet formats and bit of var/ver in this spec</t>
          </li>
          <li>
            <t>New: Block diagram, bit
   layout, test vectors for UUIDv4</t>
          </li>
          <li>
            <t>New: Block diagram, bit layout, test vectors for UUIDv3</t>
          </li>
          <li>
            <t>New: Block diagram, bit layout, test vectors for UUIDv5</t>
          </li>
          <li>
            <t>New: Add MD5 Security Considerations reference, RFC6151</t>
          </li>
          <li>
            <t>New: Add SHA-1 Security Considerations reference, RFC6194</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="format">
      <name>UUID Format</name>
      <t>The definitions start at 0 and end at 127, while octet
   definitions start at 0 and end at 15.

Perhaps:
   The UUID format is 16 octets (128 bits) in size; the variant bits
   in conjunction with the version bits described in the next sections
   determine finer structure. While discussing  In terms of these UUID formats and
   layout, bit definitions start at 0 and end at 127 127, while octet
   definitions start at 0 and end at 15.
-->

In terms of these UUID formats and layout, bit
      definitions start at 0 and end at 127, while octet definitions start at 0
      and end at 15.</t>
      <t>In the absence of explicit application or presentation protocol
      specification to the contrary, each field is encoded with the Most
Significant Byte most
      significant byte first (known as network "network byte order).</t> order").</t>
      <t>Saving UUIDs to binary format is done by sequencing all fields in
      big-endian format.
However  However, there is a known caveat that Microsoft's
      Component Object Model (COM) GUIDs leverage little-endian when saving
      GUIDs.  The discussion of this (see <xref target="MS_COM_GUID"/> target="MS_COM_GUID"/>) is outside
      the scope of this specification.</t>
      <t>UUIDs <bcp14>MAY</bcp14> be represented as binary data or integers.
      When in use with URNs or as text in applications, any given UUID should
      be represented by the "hex-and-dash" string format consisting of
      multiple groups of upper uppercase or lowercase alphanumeric hexadecimal
      characters separated by single dashes/hyphens.  When used with databases databases,
      please refer to <xref target="database_considerations"/>.</t>
      <t>The formal definition of the UUID string representation is provided by the following (ABNF) ABNF <xref target="RFC5234"/>.</t> target="RFC5234"/>:</t>
      <sourcecode type="abnf"><![CDATA[
UUID     = 4hexOctet "-"
           2hexOctet "-"
           2hexOctet "-"
           2hexOctet "-"
           6hexOctet
hexOctet = HEXDIG HEXDIG
DIGIT    = %x30-39
HEXDIG   = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
]]></sourcecode>
      <t>Note that the alphabetic characters may be all uppercase, all lowercase, or mixed case, as per <xref section="2.3" sectionFormat="comma" sectionFormat="of" target="RFC5234"/>.
An example UUID using this textual representation from the above ABNF is shown in <xref target="sampleStringUUID"/>.</t>

      <figure anchor="sampleStringUUID">
        <name>Example String UUID format</name> Format</name>
        <artwork><![CDATA[
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
]]></artwork>
      </figure>

      <t>The same UUID from <xref target="sampleStringUUID"/> is represented in Binary binary (<xref target="sampleBinaryUUID"/>), Unsigned Integer as an unsigned integer (<xref target="sampleIntegerUUID"/>) target="sampleIntegerUUID"/>), and as a URN (<xref target="sampleURNUUID"/>) defined by <xref target="RFC8141"/>.</t>

      <figure anchor="sampleBinaryUUID">
        <name>Example Binary UUID</name>
        <artwork><![CDATA[
111110000001110101001111101011100111110111101100000100011101000\
01010011101100101000000001010000011001001000111100110101111110110
]]></artwork>
      </figure>

      <figure anchor="sampleIntegerUUID">
        <name>Example Unsigned Integer UUID (shown (Shown as a decimal number)</name> Decimal Number)</name>
        <artwork><![CDATA[
329800735698586629295641978511506172918
]]></artwork>
      </figure>

      <figure anchor="sampleURNUUID">
        <name>Example URN Namespace for UUID</name>
        <artwork><![CDATA[
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
]]></artwork>
      </figure>

      <t>There are many other ways to define a UUID format; some examples are detailed below.
Please note that this is not an exhaustive list and is only provided for informational purposes.</t>

      <ul spacing="compact">
        <li>
          <t>Some spacing="normal">
        <li>Some UUID implementations, such as those found in <xref
        target="Python"/> and <xref target="Microsoft"/>, will output UUID
        with the string format, including dashes, enclosed in curly braces.</t> braces.
        </li>
        <li>
          <t><xref
        <li><xref target="X667"/> provides UUID format definitions for use of
        UUID with an OID.</t>
        </li>
        <li>
          <t>The legacy <xref OID.</li>
        <li><xref target="IBM_NCS"/> is a legacy implementation that produces a
        unique UUID format compatible with Variant 0xx of <xref target="table1"/>.</t>
        </li>
        target="table1"/>.</li>
      </ul>

      <section anchor="variant_field">
        <name>Variant Field</name>
        <t>The variant field determines the layout of the UUID.  That is, the
        interpretation of all other bits in the UUID depends on the setting of
        the bits in the variant field.  As such, it could more accurately be
        called a type "type" field; we retain the original term for compatibility.
        The variant field consists of a variable number of the most
        significant bits of octet 8 of the UUID.</t>
        <t><xref target="table1"/> lists the contents of the variant field,
        where the letter "x" indicates a "don't-care" value.</t>

        <table anchor="table1">
          <name>UUID Variants</name>
          <thead>
            <tr>
              <th align="left">Msb0</th> align="left">MSB0</th>
              <th align="left">Msb1</th> align="left">MSB1</th>
              <th align="left">Msb2</th> align="left">MSB2</th>
              <th align="left">Msb3</th> align="left">MSB3</th>
              <th align="left">Variant</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">x</td>
              <td align="left">x</td>
              <td align="left">x</td>
              <td align="left">1-7</td>
              <td align="left">Reserved, NCS align="left">Reserved. Network Computing System (NCS) backward compatibility compatibility, and
              includes Nil UUID as per <xref target="niluuid"/>.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">x</td>
              <td align="left">x</td>
              <td align="left">8-9,A-B</td>
              <td align="left">The variant specified in this document.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">x</td>
              <td align="left">C-D</td>
              <td align="left">Reserved, align="left">Reserved. Microsoft Corporation backward compatibility.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">x</td>
              <td align="left">E-F</td>
              <td align="left">Reserved for future definition and includes Max UUID as per <xref target="maxuuid"/>.</td>
            </tr>
          </tbody>
        </table>

        <t>Interoperability, in any form, with variants other than the one
defined here is not guaranteed but is not likely to be an issue in
practice.</t>
        <t>Specifically for UUIDs in this document, bits 64 and 65 of the UUID (bits 0 and 1 of octet 8) <bcp14>MUST</bcp14> be set to 1 and 0 as specified in row 2 of <xref target="table1"/>.
Accordingly, all bit and field layouts avoid the use of these bits.</t>
      </section>
      <section anchor="version_field">
        <name>Version Field</name>
        <t>The version number is in the most significant 4 bits of octet 6
(bits 48 through 51 of the UUID).</t>
        <t><xref target="table2"/> lists all of the versions for this UUID variant 10xx specified in this document.</t>

        <table anchor="table2">
          <name>UUID variant Variant 10xx versions defined Versions Defined by this specification</name> This Specification</name>
          <thead>
            <tr>
              <th align="left">Msb0</th> align="left">MSB0</th>
              <th align="left">Msb1</th> align="left">MSB1</th>
              <th align="left">Msb2</th> align="left">MSB2</th>
              <th align="left">Msb3</th> align="left">MSB3</th>
              <th align="left">Version</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">Unused</td> align="left">Unused.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">The Gregorian time-based UUID specified in this document.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">2</td>
              <td align="left">Reserved for DCE Security version, with embedded POSIX UUIDs.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">3</td>
              <td align="left">The name-based version specified in this document that uses MD5 hashing.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">4</td>
              <td align="left">The randomly or pseudo-randomly pseudorandomly generated version specified in this document.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">5</td>
              <td align="left">The name-based version specified in this document that uses SHA-1 hashing.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">6</td>
              <td align="left">Reordered Gregorian time-based UUID specified in this document.</td>
            </tr>
            <tr>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">7</td>
              <td align="left">Unix Epoch time-based UUID specified in this document.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">8</td>
              <td align="left">Reserved for custom UUID formats specified in this document.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">9</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">10</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">11</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">0</td>
              <td align="left">12</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">1</td>
              <td align="left">13</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">0</td>
              <td align="left">14</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">1</td>
              <td align="left">15</td>
              <td align="left">Reserved for future definition.</td>
            </tr>
          </tbody>
        </table>

        <t>An example version/variant layout for UUIDv4 follows the table
        where M "M" represents the version placement for the hexadecimal
        representation of 0x4 (0b0100) and the N "N" represents the variant
        placement for one of the four possible hexadecimal representation of
        variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011)</t>
        (0b1011).</t>
        <figure>
          <name>UUIDv4 Variant Examples</name>
          <artwork><![CDATA[
00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
]]></artwork>
        </figure>
        <t>It should be noted that the other remaining UUID variants found in <xref target="table1"/> leverage different sub-typing/versioning sub-typing or versioning mechanisms.
The recording and definition of the remaining UUID variant and sub-typing combinations are outside of the scope of this document.</t>
      </section>
    </section>
    <section anchor="layout">
      <name>UUID Layouts</name>
      <t>To minimize confusion about bit assignments within octets and among
      differing versions, the UUID record definition is provided as a grouping
      of fields within a bit layout consisting of four octets per row.  The
      fields are presented with the most significant one first.</t>
      <section anchor="uuidv1">
        <name>UUID Version 1</name>
        <t>UUID version 1
        <t>UUIDv1 is a time-based UUID featuring a 60 bit 60-bit timestamp
        represented by Coordinated Universal Time (UTC) as a count of 100-
nanosecond
        100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date
        of Gregorian reform to the Christian calendar).</t>
        <t>UUIDv1 also features a clock sequence field which that is used to help
        avoid duplicates that could arise when the clock is set backwards in
        time or if the node Node ID changes.</t>
        <t>The node field consists of an IEEE 802 MAC address, usually the
        host address or a randomly derived value per Sections <xref target="unguessability"/>
        target="unguessability" format="counter" /> and <xref target="unidentifiable"/>.</t>
        target="unidentifiable" format="counter"/>.</t>

        <figure>
          <name>UUIDv1 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           time_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           time_mid            |  ver  |       time_high       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|         clock_seq         |             node              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>time_low:</dt>
          <dd>
            <t>The
          <dd>The least significant 32 bits of the 60 bit 60-bit starting
          timestamp.  Occupies bits 0 through 31 (octets 0-3).</t>
          </dd> 0-3).</dd>
          <dt>time_mid:</dt>
          <dd>
            <t>The
          <dd>The middle 16 bits of the 60 bit 60-bit starting timestamp.  Occupies
          bits 32 through 47 (octets 4-5).</t>
          </dd> 4-5).</dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0001 (1).  Occupies bits 48
          through 51 of octet 6.</t> 6. </dd>
          <dt>time_high:</dt>
          <dd>
            <t>12

<!--[rfced] Please review the use of "bits...will contain...bits".
     Should this be updated as follows?  Note: similar text occurs
     more than once in the document.

Original:
      12 bits that will contain the most least significant 12 bits from the
      60 bit starting timestamp.  Occupies bits 52 through 63 (octets 6-7).</t>
          </dd>
          <dt>var:</dt>
          <dd>
            <t>The 2
      6-7).

Perhaps:
      The least significant 12 bits from the
      60 bit starting timestamp.  Occupies bits 52 through 63 (octets
      6-7).

-->

          <dt>time_high:</dt>
          <dd>The least significant 12 bits from the 60-bit starting
          timestamp.  Occupies bits 52 through 63 (octets 6-7).</dd>
          <dt>var:</dt>
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>clock_seq:</dt>
          <dd>
            <t>The
          <dd>The 14 bits containing the clock sequence.  Occupies bits 66
          through 79 (octets 8-9).</t> 8-9).  </dd>
          <dt>node:</dt>
          <dd>
            <t>48 bit
          <dd>48-bit spatially unique identifier.  Occupies bits 80 through
          127 (octets 10-15).</t>
          </dd> 10-15).</dd>
        </dl>

        <t>For systems that do not have UTC available, available but do have the local
        time, they may use that instead of UTC, UTC as long as they do so
        consistently throughout the system.  However, this is not recommended
        since generating the UTC from local time only needs a time zone time-zone
        offset.</t>
        <t>If the clock is set backwards, or if it might have been set
        backwards (e.g., while the system was powered off), and the UUID
        generator can
not cannot be sure that no UUIDs were generated with timestamps
        larger than the value to which the clock was set, then the clock
        sequence <bcp14>MUST</bcp14> be changed.  If the previous value of the
        clock sequence is known, it <bcp14>MAY</bcp14> be incremented;
        otherwise it <bcp14>SHOULD</bcp14> be set to a random or high-quality pseudo-random
        pseudorandom value.</t>
        <t>Similarly, if the node Node ID changes (e.g., because a network card has
been moved between machines), setting the clock sequence to a random
number minimizes the probability of a duplicate due to slight
differences in the clock settings of the machines.  If the value of
the clock sequence associated with the changed node Node ID were known, then
the clock sequence <bcp14>MAY</bcp14> be incremented, but that is unlikely.</t>
        <t>The clock sequence <bcp14>MUST</bcp14> be originally (i.e., once in the lifetime of
a system) initialized to a random number to minimize the correlation
across systems.  This provides maximum protection against node
identifiers Node
IDs that may move or switch from system to system rapidly.
The initial value <bcp14>MUST NOT</bcp14> be correlated to the node identifier.</t> Node ID.</t>

        <t>Notes about IEEE 802 nodes derived nodes:</t> from IEEE 802:</t>
        <ul spacing="compact">
          <li>
            <t>On spacing="normal">
          <li>On systems with multiple IEEE 802 addresses, any available one
          <bcp14>MAY</bcp14> be used.</t>
          </li>
          <li>
            <t>On used.</li>
          <li>On systems with no IEEE address, a randomly or pseudo-randomly pseudorandomly
          generated value <bcp14>MUST</bcp14> be used; see Sections <xref target="unguessability"/>
          target="unguessability" format="counter"/> and <xref target="unidentifiable"/>.</t>
          target="unidentifiable" format="counter"/>.
          </li>
          <li>
            <t>On
          <li>On systems utilizing a 64 bit 64-bit MAC address address, the least significant, right-most
          rightmost 48 bits <bcp14>MAY</bcp14> be used.</t>
          </li>
          <li>
            <t>On systems used.</li>

          <li>Systems utilizing an IEEE 802.15.4 16 bit 16-bit address
          <bcp14>SHOULD</bcp14> instead utilize their 64 bit 64-bit MAC address where
          the least significant, right-most rightmost 48 bits <bcp14>MAY</bcp14> be used. An
          alternative is to generate 32 bits of random data and postfix at the
          end of the 16 bit 16-bit MAC address to create a 48 bit value.</t>
          </li> 48-bit value.</li>
        </ul>

      </section>
      <section anchor="uuidv2">
        <name>UUID Version 2</name>
        <t>UUID

<!--[rfced] This text seems to switch between singular and plural.
     Please review our suggested text and let us know if another
     rephrase is preferred.

Original:
   UUID version 2 is known as DCE Security UUIDs [C309] and [C311].
   As such, the definition of these UUIDs is outside the scope of this
   specification.

Perhaps:
   UUID version 2 is for DCE Security UUIDs (see [C309] and [C311]).
   As such, the definition of these UUIDs is outside the scope of this
   specification.

-->

        <t>UUIDv2 is for DCE Security UUIDs (see <xref target="C309"/> and
        <xref target="C311"/>. target="C311"/>).  As such, the definition of these UUIDs is
        outside the scope of this specification.</t>
      </section>
      <section anchor="uuidv3">
        <name>UUID Version 3</name>
        <t>UUID version 3
        <t>UUIDv3 is meant for generating UUIDs from "names" names that are
        drawn from, and unique within, some "namespace" namespace as per <xref
        target="name_based_uuid_generation"/>.</t>
        <t>UUIDv3 values are created by computing an MD5 hash <xref
        target="RFC1321"/>
hash over a given namespace Namespace ID value (<xref
        target="namespaces"/>) concatenated with the desired name value after
        both have been converted to a canonical sequence of octets, as defined
        by the standards or conventions of its namespace, in network byte
        order.  This MD5 value is then used to populate all 128 bits of the
        UUID layout.  The UUID version and variant then replace the respective
        bits as defined by Sections <xref target="version_field"/> target="version_field"
        format="counter"/> and  <xref target="variant_field"/>. target="variant_field"
        format="counter"/>. An example of this bit substitution can be found
        in <xref target="uuidv3_example"/>.</t>
        <t>Information around selecting a desired name's canonical format
        within a given namespace can be found in <xref target="name_based_uuid_generation"/>,
        target="name_based_uuid_generation"/> under the heading "A note on names".</t>
        <t>Where possible possible, UUIDv5 <bcp14>SHOULD</bcp14> be used in lieu of
        UUIDv3.  For more information on MD5 security considerations considerations, see <xref
        target="RFC6151"/>.</t>
        <figure>
          <name>UUIDv3 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            md5_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          md5_high             |  ver  |       md5_mid         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        md5_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            md5_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>md5_high:</dt>
          <dd>
            <t>The
          <dd>The first 48 bits of the layout are filled with the most
          significant, left-most leftmost 48 bits from the computed MD5 value. Occupies
          bits 0 through 47 (octets 0-5).</t>
          </dd> 0-5).</dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0011 (3).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>md5_mid:</dt>
          <dd>
            <t>12
          <dd>12 more bits of the layout consisting of the least significant,
right-most
          rightmost 12 bits of 16 bits immediately following md5_high from
          the computed MD5 value.  Occupies bits 52 through 63 (octets 6-7).</t> 6-7).
          </dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>md5_low:</dt>
          <dd>
            <t>The
          <dd>The final 62 bits of the layout immediately following the var
          field to be filled with the least-significant, right-most least significant, rightmost bits of
          the final 64 bits from the computed MD5 value. Occupies bits 66
          through 127 (octets 8-15)</t>
          </dd> 8-15)</dd>
        </dl>

      </section>
      <section anchor="uuidv4">
        <name>UUID Version 4</name>
        <t>UUID version 4
        <t>UUIDv4 is meant for generating UUIDs from truly-random truly random or
pseudo-random
        pseudorandom numbers.</t>
        <t>An implementation may generate 128 bits of random data which that is used
        to fill out the UUID fields in <xref target="uuidv4fields"/>. The UUID
        version and variant then replace the respective bits as defined by
        Sections  <xref target="version_field"/>
        target="variant_field" format="counter"/> and <xref target="variant_field"/>.</t> target="version_field" format="counter"/>.</t>
        <t>Alternatively, an implementation <bcp14>MAY</bcp14> choose to
        randomly generate the exact required number of bits for random_a,
        random_b, and random_c (122 bits total), total) and then concatenate the
        version and variant in the required position.</t>
        <t>For guidelines on random data generation generation, see <xref
        target="unguessability"/>.</t>
        <figure anchor="uuidv4fields">
          <name>UUIDv4 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           random_a                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          random_a             |  ver  |       random_b        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       random_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           random_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>random_a:</dt>
          <dd>
            <t>The
          <dd>The first 48 bits of the layout that can be filled with random
          data as specified in <xref target="unguessability"/>. Occupies bits
          0 through 47 (octets 0-5).</t>
          </dd> 0-5).</dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0100 (4).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>random_b:</dt>
          <dd>
            <t>12
          <dd>12 more bits of the layout that can be filled random data as per
          <xref target="unguessability"/>. Occupies bits 52 through 63 (octets 6-7).</t>
          </dd>
          6-7).</dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>random_c:</dt>
          <dd>
            <t>The
          <dd>The final 62 bits of the layout immediately following the var
          field to be filled with random data as per <xref
          target="unguessability"/>. Occupies bits 66 through 127 (octets 8-15).</t>
          </dd>
          8-15).</dd>
        </dl>

      </section>
      <section anchor="uuidv5">
        <name>UUID Version 5</name>
        <t>UUID version 5
        <t>UUIDv5 is meant for generating UUIDs from "names" that are
        drawn from, and unique within, some "namespace" as per <xref
        target="name_based_uuid_generation"/>.</t>
        <t>UUIDv5 values are created by computing an SHA-1 hash <xref
        target="FIPS180-4"/>
hash over a given namespace Namespace ID value (<xref
        target="namespaces"/>) concatenated with the desired name value after
        both have been converted to a canonical sequence of octets, as defined
        by the standards or conventions of its namespace, in network byte
        order.  The most significant, left-most leftmost 128 bits of the SHA-1 value is
        are then used to populate all 128 bits of the UUID layout layout, and the
        remaining 32 least significant, right-most rightmost bits of SHA-1 output are
        discarded.  The UUID version and variant then replace the respective
        bits as defined by Sections <xref target="version_field"/> target="version_field"
        format="counter"/> and <xref target="variant_field"/>. target="variant_field"
        format="counter"/>. An example of this bit substitution and discarding
        excess bits can be found in <xref target="uuidv5_example"/>.</t>
        <t>Information around selecting a desired name's canonical format
        within a given namespace can be found in <xref target="name_based_uuid_generation"/>,
        target="name_based_uuid_generation"/> under the heading "A note on names".</t>
        <t>There may be scenarios, usually depending on organizational
        security policies, where SHA-1 libraries may not be available or may
        be deemed unsafe for use.  As such, it may be desirable to generate
        name-based UUIDs derived from SHA-256 or newer SHA methods. These
        name-based UUIDs <bcp14>MUST NOT</bcp14> utilize UUIDv5 and
        <bcp14>MUST</bcp14> be within the UUIDv8 space defined by <xref
        target="uuidv8"/>.  An illustrative example of UUIDv8 for SHA-256
        name-based UUIDs is provided in the appendix <xref
        target="uuidv8_example_name"/>.</t>
        <t>For more information on SHA-1 security considerations considerations, see <xref
        target="RFC6194"/>.</t>
        <figure>
          <name>UUIDv5 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           sha1_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         sha1_high             |  ver  |      sha1_mid         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       sha1_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           sha1_low                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>sha1_high:</dt>
          <dd>
            <t>The
          <dd>The first 48 bits of the layout are filled with the most
          significant, left-most leftmost 48 bits from the computed SHA-1 value.
          Occupies bits 0 through 47 (octets 0-5).</t> 0-5).  </dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0101 (5).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>sha1_mid:</dt>
          <dd>
            <t>12
          <dd>12 more bits of the layout consisting of the least significant,
right-most
          rightmost 12 bits of 16 bits immediately following sha1_high from
          the computed SHA-1 value.  Occupies bits 52 through 63 (octets 6-7).</t> 6-7).
          </dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>sha1_low:</dt>
          <dd>
            <t>The
          <dd>The final 62 bits of the layout immediately following the var
          field to be filled by skipping the 2 two most significant, left-most leftmost
          bits of the remaining SHA-1 hash and then using the next 62 most
          significant, left-most leftmost bits.  Any leftover SHA-1 bits are discarded
          and unused. Occupies bits 66 through 127 (octets 8-15).</t>
          </dd> 8-15).</dd>
        </dl>

      </section>
      <section anchor="uuidv6">
        <name>UUID Version 6</name>
        <t>UUID version 6
        <t>UUIDv6 is a field-compatible version of UUIDv1 <xref target="uuidv1"/>, (<xref
        target="uuidv1"/>), reordered for improved DB locality.  It is expected
        that UUIDv6 will primarily be used implemented in contexts where UUIDv1 is used.
        Systems that do not involve legacy UUIDv1 <bcp14>SHOULD</bcp14> use
        UUIDv7 <xref target="uuidv7"/> (<xref target="uuidv7"/>) instead.</t>
        <t>Instead of splitting the timestamp into the low, mid, and high
        sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes
        are stored from most to least significant.  That is, given a 60 bit 60-bit
        timestamp value as specified for UUIDv1 in <xref target="uuidv1"/>,
        for UUIDv6, UUIDv6 the first 48 most significant bits are stored first,
        followed by the 4 bit 4-bit version (same position), followed by the
        remaining 12 bits of the original 60 bit 60-bit timestamp.</t>
        <t>The clock sequence and node bits remain unchanged from their
        position in <xref target="uuidv1"/>.</t>
        <t>The clock sequence and node bits <bcp14>SHOULD</bcp14> be reset to
        a pseudo-random pseudorandom value for each new UUIDv6 generated; however,
        implementations <bcp14>MAY</bcp14> choose to retain the old clock
        sequence and MAC address behavior from <xref target="uuidv1"/>. For
        more information on MAC address usage within UUIDs UUIDs, see the <xref
        target="Security"/>.</t>
        <t>The format for the 16-byte, 128 bit 128-bit UUIDv6 is shown in <xref
        target="v6layout"/>.</t>
        <figure anchor="v6layout">
          <name>UUIDv6 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           time_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           time_mid            |  ver  |       time_low        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|         clock_seq         |             node              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <dl spacing="normal" newline="true">
          <dt>time_high:</dt>
          <dd>
            <t>The
          <dd>The most significant 32 bits of the 60 bit 60-bit starting timestamp.
          Occupies bits 0 through 31 (octets 0-3).</t>
          </dd> 0-3).</dd>
          <dt>time_mid:</dt>
          <dd>
            <t>The
          <dd>The middle 16 bits of the 60 bit 60-bit starting timestamp.  Occupies
          bits 32 through 47 (octets 4-5).</t>
          </dd> 4-5).</dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0110 (6).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>time_low:</dt>
          <dd>
            <t>12
          <dd>12 bits that will contain the least significant 12 bits from the 60 bit
          60-bit starting timestamp.  Occupies bits 52 through 63 (octets 6-7).</t>
          </dd>
          6-7).</dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>clock_seq:</dt>
          <dd>
            <t>The
          <dd>The 14 bits containing the clock sequence.  Occupies bits 66
          through 79 (octets 8-9).</t>
          </dd> 8-9).</dd>
          <dt>node:</dt>
          <dd>
            <t>48 bit
          <dd>48-bit spatially unique identifier.  Occupies bits 80 through
          127 (octets 10-15).</t>
          </dd> 10-15).</dd>
        </dl>

        <t>With UUIDv6, the steps for splitting the timestamp into time_high and time_mid
are <bcp14>OPTIONAL</bcp14>
since the 48 bits of time_high and time_mid will remain in the same order.
An extra step of splitting the first 48 bits of the timestamp into the most
significant
32 bits and least significant 16 bits proves useful when reusing an existing
UUIDv1 implementation.</t>
      </section>
      <section anchor="uuidv7">
        <name>UUID Version 7</name>
        <t>UUID version 7
        <t>UUIDv7 features a time-ordered value field derived from the widely
implemented and well known well-known Unix Epoch timestamp source, the number of milliseconds
since midnight 1 Jan 1970 UTC, leap seconds excluded.
Generally, UUIDv7 generally has improved entropy characteristics over UUIDv1 <xref target="uuidv1"/> (<xref target="uuidv1"/>) or UUIDv6 <xref target="uuidv6"/>.</t> (<xref target="uuidv6"/>).</t>
        <t>UUIDv7 values are created by allocating a Unix timestamp in milliseconds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 generated to provide uniqueness as per <xref target="unguessability"/>. Alternatively, implementations <bcp14>MAY</bcp14> fill the 74 bits, jointly, with a combination of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:</t>

        <ol spacing="normal" type="1"><li>
            <t>An type="1">
	  <li>An <bcp14>OPTIONAL</bcp14> sub-millisecond timestamp fraction
	  (12 bits at maximum) as per <xref target="monotonicity_counters"/>
	  (Method 3).</t>
          </li>
          <li>
            <t>An 3).</li>
          <li>An <bcp14>OPTIONAL</bcp14> carefully seeded counter as per <xref
          target="monotonicity_counters"/> (Method 1 or 2).</t>
          </li>
          <li>
            <t>Random 2).</li>
          <li>Random data for each new UUIDv7 generated for any remaining space.</t>
          </li>
          space.</li>
        </ol>

        <t>Implementations <bcp14>SHOULD</bcp14> utilize UUIDv7 instead of UUIDv1 and UUIDv6 if
possible.</t>
        <figure>
          <name>UUIDv7 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>unix_ts_ms:</dt>
          <dd>
            <t>48

<!-- [rfced] May we update "number of Unix epoch timestamp" to "number
     of the Unix epoch timestamp" for readability?

Original:
   unix_ts_ms:
      48 bit big-endian unsigned number of Unix epoch timestamp in
      milliseconds as per Section 6.1.  Occupies bits 0 through 47
      (octets 0-5).

Perhaps:
   unix_ts_ms:
      48-bit big-endian unsigned number of the Unix Epoch timestamp in
      milliseconds as per Section 6.1.  Occupies bits 0 through 47
      (octets 0-5).
-->

          <dd>48-bit big-endian unsigned number of the Unix Epoch timestamp in
          milliseconds as per <xref target="timestamp_considerations"/>.
          Occupies bits 0 through 47 (octets 0-5).</t>
          </dd> 0-5).</dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b0111 (7).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>rand_a:</dt>
          <dd>
            <t>12
          <dd>12 bits pseudo-random of pseudorandom data to provide uniqueness as per <xref
          target="unguessability"/> and/or optional constructs to guarantee
          additional monotonicity as per <xref
          target="monotonicity_counters"/>.  Occupies bits 52 through 63
          (octets 6-7).</t>
          </dd> 6-7).</dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>rand_b:</dt>
          <dd>
            <t>The
          <dd>The final 62 bits of pseudo-random pseudorandom data to provide uniqueness as
          per <xref target="unguessability"/> and/or an optional counter to
          guarantee additional monotonicity as per <xref
          target="monotonicity_counters"/>.  Occupies bits 66 through 127
          (octets 8-15).</t>
          </dd> 8-15).</dd>
        </dl>

      </section>
      <section anchor="uuidv8">
        <name>UUID Version 8</name>
        <t>UUID

<!--[rfced] Please review the use of "RFC-compatible" in the following
     text.  Compatibility with the RFC document series in what way?

Original:
   UUID version 8 provides an RFC-compatible format for experimental or
   vendor-specific use cases.

-->

        <t>UUIDv8 provides a format for experimental
        or vendor-specific use cases.  The only requirement is that the
        variant and version bits <bcp14>MUST</bcp14> be set as defined in
        Sections <xref target="variant_field"/> target="variant_field" format="counter"/> and <xref target="version_field"/>.
        target="version_field" format="counter"/>.  UUIDv8's uniqueness will be implementation-specific
        implementation specific and <bcp14>MUST NOT</bcp14> be assumed.</t>
        <t>The only explicitly defined bits are those of the version and
        variant fields, leaving 122 bits for implementation specific implementation-specific UUIDs. To
        be clear: clear, UUIDv8 is not a replacement for UUIDv4 <xref target="uuidv4"/> (<xref
        target="uuidv4"/>) where all 122 extra bits are filled with random
        data.</t>
        <t>Some example situations in which UUIDv8 usage could occur:</t>

        <ul spacing="normal">
          <li>
            <t>An
          <li>An implementation would like to embed extra information
          within the UUID other than what is defined in this document.</t>
          </li>
          <li>
            <t>An document.</li>
          <li>An implementation has other application/language application and/or language
          restrictions which that inhibit the use of one of the current UUIDs.</t>
          </li> UUIDs.</li>
        </ul>
        <t>The appendix, <xref target="ill_examples"/>,

        <t><xref target="ill_examples"/> provides two illustrative examples of
        custom UUIDv8 algorithms to address two example scenarios.</t>
        <figure>
          <name>UUIDv8 Field and Bit Layout</name>
          <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           custom_a                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          custom_a             |  ver  |       custom_b        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                       custom_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           custom_c                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <dl spacing="normal" newline="true">
          <dt>custom_a:</dt>
          <dd>
            <t>The
          <dd>The first 48 bits of the layout that can be filled as an
          implementation sees fit. Occupies bits 0 through 47 (octets 0-5).</t> 0-5).
          </dd>
          <dt>ver:</dt>
          <dd>
            <t>The 4 bit
          <dd>The 4-bit version field as defined by <xref
          target="version_field"/>, set to 0b1000 (8).  Occupies bits 48
          through 51 of octet 6.</t>
          </dd> 6.</dd>
          <dt>custom_b:</dt>
          <dd>
            <t>12
          <dd>12 more bits of the layout that can be filled as an
          implementation sees fit.  Occupies bits 52 through 63 (octets 6-7).</t> 6-7).
          </dd>
          <dt>var:</dt>
          <dd>
            <t>The 2 bit
          <dd>The 2-bit variant field as defined by <xref
          target="variant_field"/>, set to 0b10.  Occupies bits 64 and 65 of
          octet 8.</t>
          </dd> 8.</dd>
          <dt>custom_c:</dt>
          <dd>
            <t>The
          <dd>The final 62 bits of the layout immediately following the var
          field to be filled as an implementation sees fit.  Occupies bits 66
          through 127 (octets 8-15).</t>
          </dd> 8-15).</dd>
        </dl>

      </section>
      <section anchor="niluuid">
        <name>Nil UUID</name>
        <t>The nil Nil UUID is special form of UUID that is specified to have all
128 bits set to zero.</t>

        <figure>
          <name>Nil UUID Format</name>
          <artwork><![CDATA[
00000000-0000-0000-0000-000000000000
]]></artwork>
        </figure>

        <t>A Nil UUID value can be useful to communicate the absence of any
        other UUID value in situations that otherwise require or use a 128 bit 128-bit
        UUID.  A Nil UUID can express the concept "no such value here". Thus Thus,
        it is reserved for such use as needed for implementation-specific
        situations.</t>
        <t>Note that the Nil UUID value falls within the range of the Apollo
        NCS variant as per the first row of <xref target="table1"/> rather
        than the variant defined by this document.</t>
      </section>
      <section anchor="maxuuid">
        <name>Max UUID</name>
        <t>The Max UUID is a special form of UUID that is specified to have
        all 128 bits set to 1. This UUID can be thought of as the inverse of
        the Nil UUID defined in <xref target="niluuid"/>.</t>

        <figure>
          <name>Max UUID Format</name>
          <artwork><![CDATA[
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
]]></artwork>
        </figure>

        <t>A Max UUID value can be used as a sentinel value in situations
        where a 128 bit 128-bit UUID is required required, but a concept such as "end of UUID
        list" needs to be expressed, expressed and is reserved for such use as needed
        for implementation-specific situations.</t>
        <t>Note that the Max UUID value falls within the range of the "yet to be "yet-to-be defined" future UUID variant as per the last row of <xref
        target="table1"/> rather than the variant defined by this
        document.</t>
      </section>
    </section>
    <section anchor="uuid_best_practices">
      <name>UUID Best Practices</name>
      <t>The minimum requirements for generating UUIDs of each version are described in this document for each version.
      document.  Everything else is an implementation detail detail,
      and it is up to the implementer to decide what is appropriate for a
      given implementation. Various relevant factors are covered below to help
      guide an implementer through the different trade-offs among differing
      UUID implementations.</t>
      <section anchor="timestamp_considerations">
        <name>Timestamp Considerations</name>
        <t>UUID timestamp source, precision, and length was the topic were topics of great
        debate while creating UUIDv7 for this specification. Choosing the
        right timestamp for your application is a very important topic. important. This
        section will detail some of the most common points on this topic.</t> issue.</t>

        <dl spacing="normal" newline="true">
          <dt>Reliability:</dt>
          <dd>
            <t>Implementations
          <dd>Implementations acquire the current timestamp from a reliable
          source to provide values that are time-ordered time ordered and continually
          increasing.  Care must be taken to ensure that timestamp changes
          from the environment or operating system are handled in a way that
          is consistent with implementation requirements.  For example, if it
          is possible for the system clock to move backward due to either
          manual adjustment or corrections from a time synchronization
          protocol, implementations need to determine how to handle such
          cases. (See Altering, "Altering, Fuzzing, or Smearing below.)</t>
          </dd> Smearing" below.)</dd>
          <dt>Source:</dt>
          <dd>
            <t>UUID version 1
          <dd>UUIDv1 and 6 UUIDv6 both utilize a Gregorian epoch timestamp Epoch timestamp,
          while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp
          sources or a custom timestamp
epoch Epoch are required, UUIDv8
          <bcp14>MUST</bcp14> be used.</t>
          </dd> used.</dd>
          <dt>Sub-second Precision and Accuracy:</dt>
          <dd>
            <t>Many
          <dd>Many levels of precision exist for timestamps: milliseconds,
          microseconds, nanoseconds, and beyond.
Additionally  Additionally, fractional
          representations of sub-second precision may be desired to mix
          various levels of precision in a time-ordered manner.  Furthermore,
          system clocks themselves have an underlying granularity and
it granularity, which is
          frequently less than the precision offered by the operating system.
          With UUID version 1 UUIDv1 and 6, 100-nanoseconds UUIDv6, 100 nanoseconds of precision are present present,
          while UUIDv7 features a millisecond level of precision by default
          within the Unix epoch Epoch that does not exceed the granularity capable
          in most modern systems.  For other levels of precision precision, UUIDv8 is
          available.  Similar to <xref target="monotonicity_counters"/>, with
          UUIDv1 or UUIDv6, a high resolution high-resolution timestamp can be simulated by
          keeping a count of the number of UUIDs that have been generated with
          the same value of the system time, time and using it that count to construct the low
          order bits of the timestamp.  The count of the high resolution high-resolution
          timestamp will range between zero and the number of 100-nanosecond
          intervals per system time interval.</t>
          </dd> system-time interval.</dd>
          <dt>Length:</dt>
          <dd>
            <t>The
          <dd>The length of a given timestamp directly impacts how many
          timestamp ticks can be contained in a UUID before the maximum value
          for the timestamp field is reached.  Take care to ensure that the
          proper length is selected for a given timestamp.
UUID version 1  UUIDv1 and 6
          UUIDv6 utilize a 60 bit 60-bit timestamp valid until 5623 AD and AD; UUIDv7 features
          a 48
bit 48-bit timestamp valid until the year 10889 AD.</t>
          </dd> AD.</dd>
          <dt>Altering, Fuzzing, or Smearing:</dt>
          <dd>
            <t>Implementations <bcp14>MAY</bcp14>

<!-- [rfced] May we update the second sentence as follows for clarity?
     Please let us know if this alters the intended meaning or if
     there is another way to phrase this sentence.

Original:
      Implementations MAY alter the actual timestamp.  Some examples
      include security considerations around providing a real clock
      value within a UUID, to correct inaccurate clocks, to handle
      leap seconds, or instead of dividing a number of microseconds by
      1000 to obtain a millisecond value; dividing by 1024 (or some
      other value) for performance reasons.

Perhaps:
      Implementations MAY alter the actual timestamp. Some examples
      include security considerations around providing a real-clock
      value within a UUID to 1) correct inaccurate clocks, 2) handle
      leap seconds, or 3) obtain a millisecond value by dividing by
      1024 (or some other value) for performance reasons (instead of
      dividing a number of microseconds by 1000).
-->

          <dd>Implementations <bcp14>MAY</bcp14> alter the actual
          timestamp. Some examples include security considerations around
          providing a real-clock value within a UUID to 1) correct inaccurate
          clocks, 2) handle leap seconds, or 3) obtain a millisecond value by
          dividing by 1024 (or some other value) for performance reasons
          (instead of dividing a number of microseconds by 1000). This
          specification makes no requirement or guarantee about how close the
          clock value needs to be to the actual time.  If UUIDs do not need to
          be frequently generated, the UUIDv1 or UUIDv6 timestamp can simply
          be the system time multiplied by the number of 100-nanosecond
          intervals per system time interval.</t>
          </dd> system-time interval.</dd>
          <dt>Padding:</dt>
          <dd>
            <t>When
          <dd>When timestamp padding is required, implementations
          <bcp14>MUST</bcp14> pad the most significant bits (left-most) bits (leftmost)
          with data. An example for this padding data is to fill the most
          significant,
left-most leftmost bits of a Unix timestamp with zeroes to
          complete the 48
bit 48-bit timestamp in UUIDv7. An alternative approach for
          padding data is to fill the most significant, left-most leftmost bits with
          the number of 32 bit 32-bit Unix timestamp roll-overs rollovers after 2038-01-19.</t> 2038-01-19.
          </dd>
          <dt>Truncating:</dt>
          <dd>
            <t>When
          <dd>When timestamps need to be truncated, the lower, least
          significant bits <bcp14>MUST</bcp14> be used. An example would be
          truncating a 64 bit 64-bit Unix timestamp to the least significant, right-most
          rightmost 48 bits for UUIDv7.</t>
          </dd> UUIDv7.</dd>
          <dt>Error Handling:</dt>
          <dd>
            <t>If
          <dd>If a system overruns the generator by requesting too many UUIDs
          within a single system time system-time interval, the UUID service can return an error,
          error or stall the UUID generator until the system clock catches up,
          up and <bcp14>MUST NOT</bcp14> return knowingly return duplicate values
          due to a counter rollover.  Note that if the processors overrun the
          UUID generation frequently, additional node identifiers Node IDs can be
          allocated to the system, which will permit higher speed allocation
          by making multiple UUIDs potentially available for each time stamp timestamp
          value.  Similar techniques are discussed in <xref target="distributed_shared_knowledge"/>.</t>
          </dd>
          target="distributed_shared_knowledge"/>.</dd>
        </dl>

      </section>
      <section anchor="monotonicity_counters">
        <name>Monotonicity and Counters</name>
        <t>Monotonicity (each subsequent value being greater than the last) is
        the backbone of time-based sortable UUIDs. Normally, time-based UUIDs
        from this document will be monotonic due to an embedded timestamp;
        however, implementations can guarantee additional monotonicity via the
        concepts covered in this section.</t>
        <t>Take care to ensure UUIDs generated in batches are also
        monotonic. That is, if one thousand UUIDs are generated for the same
        timestamp, there should be sufficient logic for organizing the
        creation order of those one thousand UUIDs.  Batch UUID creation
        implementations <bcp14>MAY</bcp14> utilize a monotonic counter that
        increments for each UUID created during a given timestamp.</t>
        <t>For single-node UUID implementations that do not need to create
        batches of UUIDs, the embedded timestamp within UUID version 6 UUIDv6 and 7 UUIDv7
        can provide sufficient monotonicity guarantees by simply ensuring that
        timestamp increments before creating a new UUID. Distributed nodes are
        discussed in <xref target="distributed_shared_knowledge"/>.</t>
        <t>Implementations <bcp14>SHOULD</bcp14> employ the following methods
        for single-node UUID implementations that require batch UUID creation, creation
        or are otherwise concerned about monotonicity with high frequency high-frequency UUID
        generation.</t>

        <dl spacing="normal" newline="true">
          <dt>Fixed-Length
          <dt>Fixed Bit-Length Dedicated Counter Bits (Method 1):</dt>
          <dd>
            <t>Some
          <dd>Some implementations allocate a specific number of bits in the
          UUID layout to the sole purpose of tallying the total number of
          UUIDs created during a given UUID timestamp tick.
A  If present, a fixed
          bit-length counter, if present, counter <bcp14>MUST</bcp14> be positioned
          immediately after the embedded timestamp. This promotes sortability
          and allows random data generation for each counter increment.
	  With
          this method, the rand_a section (or a subset of its left-most leftmost bits)
          of UUIDv7 is used as fixed-length a fixed bit-length dedicated counter bits that are is
          incremented for every UUID generation.  The trailing random bits
          generated for each new UUID in rand_b can help produce unguessable
          UUIDs. In the event that more counter bits are required, the most
          significant
(left-most) (leftmost) bits of rand_b <bcp14>MAY</bcp14> be used as
          additional counter bits.</t>
          </dd> bits.</dd>
          <dt>Monotonic Random (Method 2):</dt>
          <dd>
            <t>With
          <dd>With this method, the random data is extended to also function
          as a counter.  This monotonic value can be thought of as a "randomly
          seeded counter" which that <bcp14>MUST</bcp14> be incremented in the
          least significant position for each UUID created on a given
          timestamp tick.  UUIDv7's rand_b section <bcp14>SHOULD</bcp14> be
          utilized with this method to handle batch UUID generation during a
          single timestamp tick.  The increment value for every UUID
          generation is a random integer of any desired length larger than
          zero. It ensures that the UUIDs retain the required level of
          unguessability provided by the underlying entropy.  The increment
          value <bcp14>MAY</bcp14> be 1 when the number of UUIDs generated in
          a particular period of time is important and guessability is not an
          issue. However, incrementing the counter by 1 <bcp14>SHOULD
          NOT</bcp14> be used by implementations that favor unguessability, as
          the resulting values are easily guessable.</t>
          </dd> guessable.</dd>
          <dt>Replace Left-Most Leftmost Random Bits with Increased Clock Precision (Method 3):</dt>
          <dd>
            <t>For
          <dd><t>For UUIDv7, which has millisecond timestamp precision, it is
          possible to use additional clock precision available on the system
          to substitute for up to 12 random bits immediately following the
          timestamp.  This can provide values that are time-ordered time ordered with
          sub-millisecond precision, using however many bits are appropriate
          in the implementation environment.  With this method, the additional
          time precision bits <bcp14>MUST</bcp14> follow the timestamp as the
          next available bit, bit in the rand_a field for UUIDv7.
</t> UUIDv7.</t>
          <t>To calculate this value, start with the portion of the timestamp
          expressed as a fraction of the clock's tick value (fraction of a
          millisecond for UUIDv7).  Compute the count of possible values that
          can be represented in the available bit space, 4096 for the UUIDv7
          rand_a field.  Using floating point or scaled integer arithmetic,
          multiply this fraction of a millisecond value by 4096 and round down
          (toward zero) to an integer result to arrive at a number between 0
          and the maximum allowed for the indicated bits bits, which sorts
          monotonically based on time. Each increasing fractional value will
          result in an increasing bit field value, value to the precision available
          with these bits.</t>
          <t>For example, let's assume a system timestamp of 1 Jan 2023
          12:34:56.1234567.  Taking the precision greater than 1ms 1 ms gives us a
          value of 0.4567, as a fraction of a millisecond.

<!--[rfced] Would you like us to update to use superscript instead of
     "to the 12th power" in the following?

Original:
If we wish to
          encode this as 12 bits, we can take the count of possible values
          that fit in those bits (4096, or 2 to the 12th power)
and power),...

-->
	  If we wish to
          encode this as 12 bits, we can take the count of possible values
          that fit in those bits (4096 or 2<sup>12</sup>), multiply
          it by our millisecond fraction value of 0.4567 0.4567, and truncate the
          result to an integer, which gives an integer value of
          1870. Expressed as hexadecimal hexadecimal, it is
0x74E, 0x74E or the binary bits
          0b011101001110.  One can then use those 12 bits as the most
          significant (left-most) (leftmost) portion of the random section of the UUID
          (e.g., the rand_a field in UUIDv7).  This works for any desired bit
          length that fits into a UUID, and applications can decide the
          appropriate length based on available clock precision, but precision; for
          UUIDv7, it is limited to 12 bits at maximum to reserve sufficient
          space for random bits.</t>
          <t>The main benefit to encoding additional timestamp precision is
          that it utilizes additional time precision already available in the
          system clock to provide values that are more likely to be unique, and thus unique; thus, it may simplify certain implementations. This technique can
          also be used in conjunction with one of the other methods, where
          this additional time precision would immediately follow the timestamp, and then
          timestamp. Then, if any bits are to be used as a clock sequence sequence,
          they would follow next.</t>
          </dd> next.</t></dd>
        </dl>

        <t>The following sub-topics cover topics issues related solely with to creating reliable
fixed-length
fixed bit-length dedicated counters:</t>

        <dl spacing="normal" newline="true">
          <dt>Fixed-Length
          <dt>Fixed Bit-Length Dedicated Counter Seeding:</dt>
          <dd>
            <t>Implementations
          <dd>Implementations utilizing the fixed-length fixed bit-length counter method
          randomly initialize the counter with each new timestamp tick.
          However, when the timestamp has not increased, the counter is
          instead incremented by the desired increment logic.  When utilizing
          a randomly seeded counter alongside Method 1, the random value
          <bcp14>MAY</bcp14> be regenerated with each counter increment
          without impacting sortability.  The downside is that Method 1 is
          prone to overflows if a counter of adequate length is not selected
          or the random data generated leaves little room for the required
          number of increments.  Implementations utilizing fixed-length fixed bit-length
          counter method <bcp14>MAY</bcp14> also choose to randomly initialize
          a portion of the counter rather than the entire counter. For
          example, a 24 bit 24-bit counter could have the 23 bits in least-significant, right-most,
          least significant, rightmost position randomly initialized. The
          remaining most significant, left-most leftmost counter bit is initialized as
          zero for the sole purpose of guarding against counter rollovers.</t> rollovers.
          </dd>
          <dt>Fixed-Length
          <dt>Fixed Bit-Length Dedicated Counter Length:</dt>
          <dd>
            <t>Select
          <dd>Select a counter bit-length that can properly handle the level
          of timestamp precision in use.  For example, millisecond precision
          generally requires a larger counter than a timestamp with nanosecond
          precision.  General guidance is that the counter
          <bcp14>SHOULD</bcp14> be at least 12 bits but no longer than 42
          bits.  Care must be taken to ensure that the counter length selected
          leaves room for sufficient entropy in the random portion of the UUID
          after the counter.  This entropy helps improve the unguessability
          characteristics of UUIDs created within the batch.</t>
          </dd> batch.</dd>
        </dl>

        <t>The following sub-topics cover rollover handling with either type of counter
method:</t>

        <dl spacing="normal" newline="true">
          <dt>Counter Rollover Guards:</dt>
          <dd>
            <t>The
          <dd>The technique from Fixed-Length "Fixed Bit-Length Dedicated Counter Seeding Seeding" above that
          describes allocating a segment of the fixed-length fixed bit-length counter as a
          rollover guard is also helpful to mitigate counter rollover issues.
          This same technique can be used with monotonic random counter
          methods by ensuring that the total length of a possible increment in
          the least significant,
right most rightmost position is less than the total
          length of the random value being incremented.  As such, the most
          significant, left-most, leftmost bits can be incremented as rollover
guarding.</t>
          </dd>
          guarding.</dd>
          <dt>Counter Rollover Handling:</dt>
          <dd>
            <t>Counter
          <dd>Counter rollovers <bcp14>MUST</bcp14> be handled by the
          application to avoid sorting issues.  The general guidance is that
          applications that care about absolute monotonicity and sortability
          should freeze the counter and wait for the timestamp to advance advance,
          which ensures monotonicity is not broken.  Alternatively,
          implementations <bcp14>MAY</bcp14> increment the timestamp ahead of
          the actual time and reinitialize the counter.</t>
          </dd> counter.</dd>
        </dl>

        <t>Implementations <bcp14>MAY</bcp14> use the following logic to
        ensure UUIDs featuring embedded counters are monotonic in nature:</t>

        <ol spacing="normal" type="1"><li>
            <t>Compare type="1">
	  <li>Compare the current timestamp against the previously stored timestamp.</t>
          </li>
          <li>
            <t>If
	  timestamp.</li>
          <li>If the current timestamp is equal to the previous timestamp,
          increment the counter according to the desired method.</t>
          </li>
          <li>
            <t>If method.</li>
          <li>If the current timestamp is greater than the previous timestamp,
          re-initialize the desired counter method to the new timestamp and
          generate new random bytes (if the bytes were frozen or being used as
          the seed for a monotonic counter).</t> counter). </li>
        </ol>

        <dl spacing="normal" newline="true">
          <dt>Monotonic Error Checking:</dt>
          <dd>
            <t>Implementations
          <dd>Implementations <bcp14>SHOULD</bcp14> check if the currently
          generated UUID is greater than the previously generated UUID. If
          this is not the case case, then any number of things could have occurred,
          such as clock rollbacks, leap second handling, and counter
          rollovers. Applications <bcp14>SHOULD</bcp14> embed sufficient logic
          to catch these scenarios and correct the problem to ensure that the
          next UUID generated is greater than the previous, or they should at least report
          an appropriate error.  To handle this scenario, the general guidance
          is that the application <bcp14>MAY</bcp14> reuse the previous timestamp
          and increment the previous counter method.</t> method. </dd>
        </dl>

      </section>
      <section anchor="generator_states">
        <name>UUID Generator States</name>
        <t>The (optional) UUID generator state only needs to be read from
        stable storage once at boot time, if it is read into a system-wide
        shared volatile store (and updated whenever the stable store is
        updated).</t>
        <t>This stable storage <bcp14>MAY</bcp14> be used to record various
        portions of the UUID generation generation, which prove useful for batch UUID
        generation purposes and monotonic error checking with UUIDv6 and
        UUIDv7.  These stored values include but are not limited to last known
        timestamp, clock sequence, counters, and random data.</t>
        <t>If an implementation does not have any stable store available, then
        it <bcp14>MAY</bcp14> proceed with UUID generation as if this was were the
        first UUID created within a batch.  This is the least desirable
        implementation because it will increase the frequency of creation of
        values such as clock sequence, counters, or random data, which
        increases the probability of duplicates. Further, frequent generation
        of random numbers also puts more stress on any entropy source and or and/or
        entropy pool being used as the basis for such random numbers.</t>
        <t>An implementation <bcp14>MAY</bcp14> also return an application
        error in the event that collision resistance is of the utmost concern.
        The semantics of this error are up to the application and
        implementation.  See <xref target="collision_resistance"/> for more
        information on weighting collision tolerance in applications.</t>
        <t>For UUIDv1 and UUIDv6, if the node Node ID can never change (e.g., the
        network interface card from which the node Node ID is derived is
        inseparable from the system), or if any change also re-initializes the
        clock sequence to a random value, then instead of keeping it in stable
        store, the current node Node ID may be returned.</t>
        <t>For UUIDv1 and UUIDv6, the state does not always need to be written
        to stable store every time a UUID is generated.  The timestamp in the
        stable store can be periodically be set to a value larger than any yet
        used in a UUID.  As long as the generated UUIDs have timestamps less
        than that value, and the clock sequence and node Node ID remain unchanged,
        only the shared volatile copy of the state needs to be updated.
        Furthermore, if the timestamp value in stable store is in the future
        by less than the typical time it takes the system to reboot, a crash
        will not cause a re-initialization of the clock sequence.</t>
        <t>If it is too expensive to access shared state each time a UUID is
        generated, then the system-wide generator can be implemented to
        allocate a block of time stamps timestamps each time it is called; a per-
process per-process
        generator can allocate from that block until it is exhausted.</t>
      </section>
      <section anchor="distributed_shared_knowledge">
        <name>Distributed UUID Generation</name>
        <t>Some implementations <bcp14>MAY</bcp14> desire to utilize the utilization of
        multi-node, clustered, applications
which that involve two or more nodes
        independently generating UUIDs that will be stored in a common
        location.  While UUIDs already feature sufficient entropy to ensure
        that the chances of collision are low, as the total number of UUID
        generating nodes increase; increases, so does the likelihood of a collision.</t>
        <t>This section will detail the two additional collision resistance
        approaches that have been observed by multi-node UUID implementations
        in distributed environments.</t>
        <t>It should be noted that, although this section details two methods
        for the sake of completeness, implementations should utilize the pseudo-random
        pseudorandom Node ID option if additional collision resistance for
        distributed UUID generation is a requirement.  Likewise, utilization
        of either method is not required for implementing UUID generation in
        distributed environments.</t>

        <dl spacing="normal" newline="true">
          <dt>Node IDs:</dt>
          <dd>
            <t>With
          <dd>With this method, a pseudo-random pseudorandom Node ID value is placed within
          the UUID layout.  This identifier helps ensure the bit-space bit space for a
          given node is unique, resulting in UUIDs that do not conflict with
          any other UUID created by another node with a different node id.
          Implementations that choose to leverage an embedded node id
          <bcp14>SHOULD</bcp14> utilize UUIDv8.  The node id <bcp14>SHOULD
          NOT</bcp14> be an IEEE 802 MAC address as per <xref
          target="Security"/>.  The location and bit length are left to
          implementations and are outside the scope of this specification.
          Furthermore, the creation and negotiation of unique node ids among
          nodes is also out of scope for this specification.</t>
          </dd> specification.</dd>
          <dt>Centralized Registry:</dt>
          <dd>
            <t>With
          <dd>With this method method, all nodes tasked with creating UUIDs consult a
          central registry and confirm the generated value is unique. As
          applications scale, the communication with the central registry
          could become a bottleneck and impact UUID generation in a negative
          way. Shared knowledge schemes with central/global registries are
          outside the scope of this specification and is are <bcp14>NOT RECOMMENDED</bcp14>.</t>
          </dd>
          RECOMMENDED</bcp14>.</dd>
        </dl>

        <t>Distributed applications generating UUIDs at a variety of hosts <bcp14>MUST</bcp14>
be willing to rely on the random number source at all hosts.</t>
      </section>
      <section anchor="name_based_uuid_generation">
        <name>Name-Based UUID Generation</name>
        <t>Although

<!--[rfced] Would this update to "historical documents" convey the
     correct meaning?

Original:
   Although some prefer to use the word "hash-based" to describe UUIDs
   featuring hashing algorithms (MD5 or SHA-1), this document retains
   the usage of the adjective "name-based" in order to maintain
   consistency with historical documents and existing implementations.

Perhaps:
   Although some prefer to use the word "hash-based" to describe UUIDs
   featuring hashing algorithms (MD5 or SHA-1), this document retains
   the usage of the term "name-based" in order to maintain consistency
   with previously published documents and existing implementations.
-->
	<t>Although some prefer to use the word "hash-based" to describe UUIDs
	featuring hashing algorithms (MD5 or SHA-1), this document retains the
	usage of the term "name-based" in order to maintain consistency with
	previously published documents and existing implementations.</t>
        <t>The requirements for name-based UUIDs are as follows:</t>

        <ul spacing="normal">
          <li>
            <t>UUIDs
          <li>UUIDs generated at different times from the same name (using
          the same canonical format) in the same namespace <bcp14>MUST</bcp14>
          be equal.</t>
          </li>
          <li>
            <t>UUIDs equal.</li>
          <li>UUIDs generated from two different names (same or differing
          canonical format) in the same namespace should be different (with
          very high probability).</t>
          </li>
          <li>
            <t>UUIDs probability).</li>
          <li>UUIDs generated from the same name (same or differing
          canonical format) in two different namespaces should be different
          (with very high probability).</t>
          </li>
          <li>
            <t>If probability).</li>
          <li>If two UUIDs that were generated from names (using the same
          canonical format) are equal, then they were generated from the same
          name in the same namespace (with very high probability).</t>
          </li> probability).</li>
        </ul>
        <dl newline="true">
          <dt>A

          <t>A note on names:</dt>
          <dd>
            <t>The names:</t>
          <t indent="3">The concept of name (and namespace) should be broadly
          construed and not limited to textual names. A canonical sequence of
          octets is one that conforms to the specification for that name
          form's canonical representation. A name can have many usual forms,
          only one of which can be canonical. An implementer of new namespaces
          for UUIDs needs to reference the specification for the canonical
          form of names in that space, space or define such a canonical form for the
          namespace if it does not exist.
	  For example, at the time of this specification, <xref target="RFC8499"/> domain name system writing,
          Domain Name System (DNS) <xref target="RFC9499"/> has
          three conveyance formats: common (www.example.com), presentation (www.example.com.)
          (www.example.com.), and wire format (3www7example3com0).

<!--[rfced] To what does "the previous version of this specification"
     refer? RFC 4122?

Original:
Looking at <xref target="X500"/> [X500] distinguished names (DNs), the previous version of
this specification allowed either text based or binary distinguished
encoding rules (DER) based names as inputs.

Perhaps:
Looking at [X500] distinguished names (DNs), [RFC4122] allowed either
text-based or binary DER-based names as inputs.
-->
	  Looking at <xref target="X500"/>
          Distinguished Names (DNs), <xref target="RFC4122" format="default"/> allowed either text-based or binary
          DER-based names as inputs.  For Uniform Resource Locators (URLs)
          <xref target="RFC1738"/> uniform resource locators (URLs), target="RFC1738"/>, one could provide a fully-qualified domain-name Fully Qualified
          Domain Name (FQDN) with or without the protocol identifier (www.example.com)
          www.example.com or (https://www.example.com). https://www.example.com.  When it comes to <xref target="X660"/> object identifiers
          Object Identifiers (OIDs) <xref target="X660"/>, one could choose dot-notation
          dot notation without the leading dot (2.999), choose to include the
          leading dot (.2.999) (.2.999), or select one of the many formats from <xref
          target="X680"/> such as OID Internationalized Resource Identifier
          (OID-IRI) (/Joint-ISO-ITU-T/Example).  While most users may default
          to the common format for DNS, FQDN format for a URL, text format for X.500
          X.500, and dot-notation dot notation without a leading dot for OID; OID, name-based
          UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary
          input which that will compute name-based UUIDs for any of the
          aforementioned example names and others not defined here.  Each name
          format within a namespace will output different UUIDs.  As such, the
          mechanisms or conventions used for allocating names and ensuring
          their uniqueness within their namespaces are beyond the scope of
          this specification.</t>
          </dd>
        </dl>

      </section>
      <section anchor="namespaces">
        <name>Namespace ID Usage and Allocation</name>

        <t>This section and table, <xref target="namespaceIDs"/>, details the namespace
        IDs for some potentially interesting namespaces such as those for DNS
        <xref target="RFC8499"/> domain name system (DNS), target="RFC9499"/>, URLs <xref target="RFC1738"/> uniform resource locators (URLs), target="RFC1738"/>, OIDs <xref target="X660"/> object identifiers (OIDs),
        target="X660"/>, and DNs <xref target="X500"/> distinguished names (DNs).</t> target="X500"/>.</t>

        <t>Further, this section also details allocation, IANA registration registration,
        and other details pertinent to Namespace IDs.
IANA may use the table <xref target="namespaceIDs"/> as-is replacing "This Document" replaced as required.</t> IDs.</t>

        <table anchor="namespaceIDs">
          <name>Namespace IDs</name>
          <thead>
            <tr>
              <th align="left">Namespace</th>
              <th align="left">Namespace ID Value</th>
              <th align="left">Name Reference</th>
              <th align="left">Namespace ID Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">DNS</td>
              <td align="left">6ba7b810-9dad-11d1-80b4-00c04fd430c8</td>
              <td align="left">
                <xref target="RFC8499"/></td> target="RFC9499"/></td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">URL</td>
              <td align="left">6ba7b811-9dad-11d1-80b4-00c04fd430c8</td>
              <td align="left">
                <xref target="RFC1738"/></td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">OID</td>
              <td align="left">6ba7b812-9dad-11d1-80b4-00c04fd430c8</td>
              <td align="left">
                <xref target="X660"/></td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">X500</td>
              <td align="left">6ba7b814-9dad-11d1-80b4-00c04fd430c8</td>
              <td align="left">
                <xref target="X500"/></td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
          </tbody>
        </table>

        <t>Items may be added to this table registry using "Specification Required" the Specification Required
        policy as per <xref target="RFC8126"/>.</t>
        <t>For designated experts, generally speaking, Namespace IDs are
        allocated as follows:</t>

        <ul spacing="compact">
          <li>
            <t>The spacing="normal">
          <li>The first namespace Namespace ID value, for DNS, was calculated from a
          time-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8" "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as
          a starting point.</t>
          </li>
          <li>
            <t>Subsequent namespace point.</li>
          <li>Subsequent Namespace ID values increment the least-significant, right-most
          least significant, rightmost bit of time_low "6ba7b810" while
          freezing the rest of the UUID to "9dad-11d1-80b4-00c04fd430c8".</t>
          </li>
          <li>
            <t>New namespace "9dad-11d1-80b4-00c04fd430c8".</li>
          <li>New Namespace ID values <bcp14>MUST</bcp14> use this same
          logic and <bcp14>MUST NOT</bcp14> use a previously used Namespace ID value.</t>
          </li>
          <li>
            <t>Thus,
          value.</li>
          <li>Thus, "6ba7b815" is the next available time_low for a new
          Namespace ID value with the full ID being "6ba7b815-9dad-11d1-80b4-00c04fd430c8".</t>
          </li>
          <li>
            <t>The
          "6ba7b815-9dad-11d1-80b4-00c04fd430c8".</li>

<li>The upper bound for time_low in this special use, namespace Namespace ID
          values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8" "ffffffff-9dad-11d1-80b4-00c04fd430c8",
          which should be sufficient space for future namespace Namespace ID values.</t>
          </li> values.</li>
        </ul>

        <t>Note that the namespace Namespace ID value
        "6ba7b813-9dad-11d1-80b4-00c04fd430c8" and its usage is are not defined by
        this document or by <xref target="RFC4122"/>, as such target="RFC4122"/>; thus, it <bcp14>SHOULD
        NOT</bcp14> be used as a Namespace ID value.</t>
        <t>New Namespace ID values <bcp14>MUST</bcp14> be documented as per
        <xref target="IANA"/> if they are to be globally available and fully
        interoperable.  Implementations <bcp14>MAY</bcp14> continue to use
        vendor-specific, application-specific, and deployment-specific
        Namespace ID values values; but know that interoperability is not guaranteed.
        These custom Namespace ID values <bcp14>MUST NOT</bcp14> use the logic above and instead are <bcp14>RECOMMENDED</bcp14> to generate
        above; instead, generating a
        UUIDv4 or UUIDv7 Namespace ID value. value is <bcp14>RECOMMENDED</bcp14>.  If collision probability (<xref
        target="collision_resistance"/>) and uniqueness (<xref
        target="global_local_uniqueness"/>) of the final name-based UUID are
        not a problem; problem, an implementation <bcp14>MAY</bcp14> also leverage
        UUIDv8 instead to create a custom, application-specific Namespace ID
        value.</t>
        <t>Implementations <bcp14>SHOULD</bcp14> provide the ability to input
        a custom namespace to account for newly registered IANA Namespace ID
        values outside of those listed in this section or custom, application specific
        application-specific Namespace ID values.</t>
      </section>
      <section anchor="collision_resistance">
        <name>Collision Resistance</name>
        <t>Implementations should weigh the consequences of UUID collisions
        within their application and when deciding between UUID versions that
        use entropy (randomness) versus the other components such as those in
        Sections <xref target="timestamp_considerations"/> target="timestamp_considerations" format="counter"/>
        and <xref target="monotonicity_counters"/>. target="monotonicity_counters" format="counter"/>.  This is
        especially true for distributed node collision resistance as defined
        by <xref target="distributed_shared_knowledge"/>.</t>
        <t>There are two example scenarios below which that help illustrate the
        varying seriousness of a collision within an application.</t>

        <dl spacing="normal" newline="true">
          <dt>Low Impact:</dt>
          <dd>
            <t>A
          <dd>A UUID collision generated a duplicate log entry entry, which results
          in incorrect statistics derived from the data. Implementations that
          are not negatively affected by collisions may continue with the
          entropy and uniqueness provided by the traditional UUID format.</t> UUIDs defined in this document.
          </dd>
          <dt>High Impact:</dt>
          <dd>
            <t>A
          <dd>A duplicate key causes an airplane to receive the wrong course course,
          which puts people's lives at risk. In this scenario scenario, there is no
          margin for error. Collisions must be avoided and avoided: failure is
          unacceptable. Applications dealing with this type of scenario must
          employ as much collision resistance as possible within the given
          application context.</t>
          </dd> context.</dd>
        </dl>

      </section>
      <section anchor="global_local_uniqueness">
        <name>Global and Local Uniqueness</name>
        <t>UUIDs created by this specification <bcp14>MAY</bcp14> be used to
        provide local uniqueness guarantees.  For example, ensuring UUIDs
        created within a local application context are unique within a
        database <bcp14>MAY</bcp14> be sufficient for some implementations
        where global uniqueness outside of the application context, in other
        applications, or around the world is not required.</t>
        <t>Although true global uniqueness is impossible to guarantee without
        a shared knowledge scheme, a shared knowledge scheme is not required
        by a UUID to provide uniqueness for practical implementation purposes.
        Implementations <bcp14>MAY</bcp14> implement use a shared knowledge scheme
        scheme, introduced in <xref target="distributed_shared_knowledge"/> target="distributed_shared_knowledge"/>,
        as they see fit to extend the uniqueness guaranteed by this
        specification.</t>
      </section>
      <section anchor="unguessability">
        <name>Unguessability</name>
        <t>Implementations <bcp14>SHOULD</bcp14> utilize a cryptographically
        secure pseudo-random pseudorandom number generator (CSPRNG) to provide values that
        are both difficult to predict ("unguessable") and have a low
        likelihood of collision ("unique").  The exception is when a suitable
        CSPRNG is unavailable in the execution environment.  Take care to
        ensure the CSPRNG state is properly reseeded upon state changes, such
        as process forks, to ensure proper CSPRNG operation.  CSPRNG ensures
        the best of Sections <xref target="collision_resistance"/> target="collision_resistance"
        format="counter"/> and <xref target="Security"/> target="Security" format="counter"/> are
        present in modern UUIDs.</t>
        <t>Further advice on generating cryptographic-quality random numbers
        can be found in <xref target="RFC4086"/>, <xref target="RFC8937"/> target="RFC8937"/>,
        and in <xref target="RANDOM"/>.</t>
      </section>
      <section anchor="unidentifiable">
        <name>UUIDs That Do Not Identify the Host</name>
        <t>This section describes how to generate a UUIDv1 or UUIDv6 value if
        an IEEE 802 address is not available, available or its use is not desired.</t>
        <t>Implementations <bcp14>MAY</bcp14>

<!--[rfced] Should this actually be a citation with a corresponding
     reference entry?  If so, please provide the correct reference
     entry information as well as if it should be listed in the
     Normative or Informative section.

Original:
   Implementations MAY leverage MAC address randomization techniques
   (IEEE 802.11bh) as an alternative to the pseudo-random logic provided
   in this section.

-->

        <t>Implementations <bcp14>MAY</bcp14> leverage MAC address
        randomization techniques <xref target="IEEE802.11bh" format="default"/> as an alternative to the
        pseudorandom logic provided in this section.</t>
        <t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a 48 bit
        48-bit cryptographic-quality random number as per <xref
        target="unguessability"/> to use it as the node Node ID.

<!--[rfced] In the following text, which meaning is correct?

Original:

After generating the 48 bit fully randomized node value,
implementations <bcp14>MUST</bcp14> MUST set the least significant bit of the first octet
of the node ID set to 1.

Perhaps A (the least significant bit is set to 1):

After generating the 48-bit fully randomized node value,
implementations MUST set the least significant bit of the first octet
of the node ID to 1.

Perhaps B (the least significant bit is set to some value for the first octet of the node ID that is set to 1):

After generating the 48-bit fully randomized node value,
implementations MUST set the least significant bit of the first octet
of the node ID set to 1.
-->
        After generating the 48-bit fully randomized node value,
        implementations <bcp14>MUST</bcp14> set the least significant bit of
        the first octet of the Node ID to 1.  This bit is the unicast/multicast
        unicast or multicast bit, which will never be set in IEEE 802 addresses
        obtained from network cards.  Hence, there can never be a conflict
        between UUIDs generated by machines with and without network cards.
        An example of generating a randomized 48 bit 48-bit node value and the
        subsequent bit modification is detailed in the <xref target="test_vectors"/> appendix.
        target="test_vectors"/>.  For more information about IEEE 802 address
        and the unicast/multicast unicast or multicast or local/global bits bits, please review <xref target="RFC7042"/>.</t>
        target="RFC9542"/>.</t>
        <t>For compatibility with earlier specifications, note that this
        document uses the unicast/multicast bit, unicast or multicast bit instead of the arguably more
        correct local/global bit because MAC addresses with the local/global
        bit set or not set are both possible in a network.  This is not the case
        with the unicast/multicast unicast or multicast bit.  One node cannot have a MAC address
        that multicasts to multiple nodes.</t>
        <t>In addition, items such as the computer's name and the name of the
        operating system, while not strictly speaking random, will help
        differentiate the results from those obtained by other systems.</t>
        <t>The exact algorithm to generate a node Node ID using these data is
        system
specific, specific because both the data available and the functions to
        obtain them are often very system specific.  A  However, a generic approach, however, approach
        is to accumulate as many sources as possible into a buffer, use a
        message digest (such as SHA-256 or SHA-512 defined by <xref
        target="FIPS180-4"/>), take an arbitrary 6 bytes from the hash value,
        and set the multicast bit as described above.</t>
      </section>
      <section anchor="sorting">
        <name>Sorting</name>
        <t>UUIDv6 and UUIDv7 are designed so that implementations that require
        sorting (e.g., database indexes) sort as opaque raw bytes, bytes without the
        need for parsing or introspection.</t>
        <t>Time ordered
        <t>Time-ordered monotonic UUIDs benefit from greater database index database-index
        locality because the new values are near each other in the index.  As
        a result result, objects are more easily clustered together for better
        performance.  The real-world differences in this approach of index
        locality vs versus random data inserts can be one order of magnitude or
        more.</t>
        <t>UUID formats created by this specification are intended to be
        lexicographically sortable while in the textual representation.</t>
        <t>UUIDs created by this specification are crafted with big-endian
        byte order (network byte order) in mind. If little-endian style is
        required, UUIDv8 is available for custom UUID formats.</t>
      </section>
      <section anchor="opacity">
        <name>Opacity</name>
        <t>As general guidance, it is recommend to avoid avoiding parsing UUID values unnecessarily,
and instead treating
        unnecessarily is recommended; instead, treat UUIDs as opaquely as possible.
        Although application-specific concerns could could, of course course, require some
        degree of introspection (e.g., to examine the Sections <xref target="variant_field"/>,
        target="variant_field" format="counter"/> or <xref target="version_field"/>
        target="version_field" format="counter"/> or perhaps the timestamp of
        a UUID), the advice here is to avoid this or other parsing unless
        absolutely necessary.  Applications typically tend to be simpler, be more
        interoperable, and perform better, better when this advice is followed.</t>
      </section>
      <section anchor="database_considerations">
        <name>DBMS and Database Considerations</name>
        <t>For many applications, such as databases, storing UUIDs as text is
        unnecessarily verbose, requiring 288 bits to represent 128 bit 128-bit UUID
        values.  Thus, where feasible, UUIDs <bcp14>SHOULD</bcp14> be stored
        within database applications as the underlying 128 bit 128-bit binary
        value.</t>
        <t>For other systems, UUIDs <bcp14>MAY</bcp14> be stored in binary
        form or as text, as appropriate.  The trade-offs to both approaches are:</t>
        are as follows:</t>

        <ul spacing="normal">
          <li>
            <t>Storing as
          <li>Storing in binary form requires less space and may result in faster
          data access.</t>
          </li>
          <li>
            <t>Storing access.</li>
          <li>Storing as text requires more space but may require less
          translation if the resulting text form is to be used after
          retrieval, which thus may make it simpler to implement.</t> implement. </li>
        </ul>

        <t>DBMS vendors are encouraged to provide functionality to generate
        and store UUID formats defined by this specification for use as
        identifiers or left parts of identifiers such as, but not limited to,
        primary keys, surrogate keys for temporal databases, foreign keys
        included in polymorphic relationships, and keys for key-value pairs in
        JSON columns and key-value databases.  Applications using a monolithic
        database may find using database-generated UUIDs (as opposed to client-generate
        client-generated UUIDs) provides the best UUID monotonicity.  In
        addition to UUIDs, additional identifiers <bcp14>MAY</bcp14> be used
        to ensure integrity and feedback.</t>
        <t>Designers of database schema are cautioned against using name-based
        UUIDs (<xref target="uuidv3"/>/<xref target="uuidv5"/>) (see Sections <xref target="uuidv3" format="counter"/> and <xref
        target="uuidv5" format="counter"/>) as primary keys in tables.  A
        common issue observed in database schema design is the assumption that
        a particular value will never change, which then later turns out to be
        an incorrect assumption.  Postal codes, license or other
        identification numbers, and numerous other such identifiers seem
        unique and unchanging at a given point time; time -- only to later turn out to have edge
        cases where they need to change.  The subsequent change of the
        identifier, used as a "name" input for name-based UUIDs, can
        invalidate a given database structure.  In such scenarios scenarios, it is
        observed that using any non-name-based UUID version would have
        resulted in the field in question being placed somewhere that would
        have been easier to adapt to such changes (primary key excluded from
        this statement).  The general advice is to avoid name-based UUID
        natural keys and instead and, instead, to utilize time-based UUID surrogate keys
        based on the aforementioned problems detailed in this section.</t>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>All

<!--[rfced] Is it necessary to include both of these paragraphs as
     they seem to convey the same information?

Original:
   All references to <xref target="RFC4122"/> [RFC4122] in the IANA registries should be replaced
   with references to this document.  References to <xref target="RFC4122"/> [RFC4122] document's
   Section 4.1.2 should be updated to refer to this document's <xref target="format"/>.</t>
      <t>The
   Section 4.

   The IANA URN namespace registration <xref target="URNNamespaces"/> [URNNamespaces] for UUID filed in <xref target="RFC4122"/>
   [RFC4122] should be updated to reference this document.

Perhaps:
   All references to [RFC4122] in IANA registries (outside of those
   created by this document) have been replaced with references to
   this document, including the IANA URN namespace registration
   [URNNamespaces] for UUID.  References to Section 4.1.2 of [RFC4122]
   have been updated to refer to Section 4 of this document.

-->
      <t>All references to <xref target="RFC4122"/> in IANA registries
      (outside of those created by this document) have been replaced with
      references to this document, including the IANA URN namespace
      registration <xref target="URNNamespaces"/> for UUID.  References to
      <xref target="RFC4122" sectionFormat="of" section="4.1.2"/> have been
      updated to refer to <xref target="format"/> of this document.</t>
      <t>Finally
      <t>Finally, IANA should track UUID Subtypes and Special Case "Namespace
      IDs Values" as specified in Sections <xref target="iana2"/> target="iana2"
      format="counter"/> and <xref target="iana3"/>.</t> target="iana3" format="counter"/> at the following location: <eref brackets="angle" target="https://www.iana.org/assignments/uuid"/>.</t>
      <t>When evaluating requests, the designated expert(s) expert should consider
      community feedback, how well-defined is the reference specification, specification is, and
      this specification's requirements.  Vendor-specific,
      application-specific, and deployment-specific values are unable to be
      registered.

<!--[rfced] Is this use of "standards" referring to RFCs that are on
     the Standards Track?  Or is this the general use of the term?

Original:
Vendor-specific, application-specific, and deployment-specific values
are unable to be registered.  Specification documents should be
published in a stable, freely available manner (ideally located with a
URL) but need not be standards.
-->
      Specification documents should be published in a stable,
      freely available manner (ideally, located with a URL) but need not be
      standards.  The designated experts expert will either approve or deny the
      registration request, request and communicate their this decision to IANA. Denials
      should include an explanation and, if applicable, suggestions as to how
      to make the request successful.</t>
      <section anchor="iana2">
        <name>IANA UUID Subtype Registry and Registration</name>
        <t>This specification defines the "UUID Subtype" Subtypes" registry for common, common
        widely used UUID standards.</t>
        <t><xref target="ianaSubtypes"/> should be used as-is for this registry with "This document" replaced as required.</t>

        <table anchor="ianaSubtypes">
          <name>IANA UUID Subtypes</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">ID</th>
              <th align="left">Subtype</th>
              <th align="left">Variant</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Gregorian Time-based</td>
              <td align="left">1</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">DCE Security</td>
              <td align="left">2</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">
                <xref target="C309"/>, <xref target="C311"/></td>
            </tr>
            <tr>
              <td align="left">MD5 Name-based</td>
              <td align="left">3</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">Random</td>
              <td align="left">4</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">SHA-1 Name-based</td>
              <td align="left">5</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">
                <xref target="RFC4122"/>, This document</td> RFC 9562</td>
            </tr>
            <tr>
              <td align="left">Reordered Gregorian Time-based</td>
              <td align="left">6</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">This document</td> align="left">RFC 9562</td>
            </tr>
            <tr>
              <td align="left">Unix Time-based</td>
              <td align="left">7</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">This document</td> align="left">RFC 9562</td>
            </tr>
            <tr>
              <td align="left">Custom</td>
              <td align="left">8</td>
              <td align="left">version</td>
              <td align="left">OSF DCE / IETF</td>
              <td align="left">This document</td> align="left">RFC 9562</td>
            </tr>
          </tbody>
        </table>

        <t>This table may be extended by the "Standards Action" policy, Standards Action as per
        <xref target="RFC8126"/>.</t>
        <t>For designated experts:</t>

        <ul spacing="compact">
          <li>
            <t>The spacing="normal">
          <li>The minimum and maximum "ID" value for the subtype "version"
          within the "OSF DCE / IETF" variant is 0 through 15. The versions, versions
          within <xref target="table1"/>, target="table1"/> described as "Reserved for future
          definition" or "unused" are omitted from this IANA registry until
          properly defined.</t> defined. </li>
          <li>
            <t>The
          <li>The "Subtype" column is free-form text however text.  However, at the time of this publication only
          publication, "version" and "family" are the only known UUID
          subtypes. The "family" subtype is part of the "Apollo NCS" variant
          space (Both (both are outside the scope of this specification). The
          Microsoft variant may have subtyping mechanisms defined however defined; however,
          they are unknown and outside of the scope of this
          specification. Similarly, the final "Reserved for future definition"
          variant may introduce new subtyping logic at a future date. Subtype
          IDs are permitted to overlap, that overlap. That is, an ID of "1" may exist in
          multiple variant spaces.</t>
          </li>
          <li>
            <t>The spaces.</li>
          <li>The "Variant" column is free-form text however text. However, it is likely that one
          of four values will be included. The included: the first three are "OSF DCE /
          IETF", "Apollo NCS", "Microsoft". The and "Microsoft", and the final variant value belongs to
          the "Reserved for future definition" variant and may introduce a new
          name at a future date.</t>
          </li> date.</li>
        </ul>

      </section>
      <section anchor="iana3">
        <name>IANA UUID Namespace ID Registry and Registration</name>
        <t>This specification defines the "UUID Namespace ID" IDs" registry for common, widely used Namespace ID values.</t>
        <t>The full details of this registration, including information for designated experts, can be found in <xref target="namespaces"/>.</t>
      </section>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>Implementations <bcp14>SHOULD NOT</bcp14> assume that UUIDs are hard
      to guess.  For example, they <bcp14>MUST NOT</bcp14> be used as security
      capabilities (identifiers whose mere possession grants access).
      Discovery of predictability in a random number source will result in a
      vulnerability.</t>
      <t>Implementations <bcp14>MUST NOT</bcp14> assume that it is easy to
      determine if a UUID has been slightly modified in order to redirect a
      reference to another object.  Humans do not have the ability to easily
      check the integrity of a UUID by simply glancing at it.</t>
      <t>MAC addresses pose inherent security risks around privacy and
      <bcp14>SHOULD NOT</bcp14> be used within a UUID.  Instead CSPRNG data
      <bcp14>SHOULD</bcp14> be selected from a source with sufficient entropy
      to ensure guaranteed uniqueness among UUID generation. See Sections
      <xref target="unguessability"/> target="unguessability" format="counter"/> and <xref target="unidentifiable"/>
      target="unidentifiable" format="counter"/> for more information.</t>
      <t>Timestamps embedded in the UUID do pose a very small attack
      surface. The timestamp in conjunction with an embedded counter does
      signal the order of creation for a given UUID and its corresponding data
      but does not define anything about the data itself or the application as
      a whole.  If UUIDs are required for use with any security operation
      within an application context in any shape or form form, then UUIDv4, <xref target="uuidv4"/> UUIDv4 (<xref
      target="uuidv4"/>) <bcp14>SHOULD</bcp14> be utilized.</t>
      <t>See <xref target="RFC6151"/> for MD5 Security Considerations security considerations and
      <xref target="RFC6194"/> for SHA-1 security considerations.</t>
    </section>
    <section anchor="Acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors gratefully acknowledge the contributions of Rich Salz,
Michael Mealling,
Ben Campbell,
Ben Ramsey,
Fabio Lima,
Gonzalo Salgueiro,
Martin Thomson,
Murray S. Kucherawy,
Rick van Rein,
Rob Wilton,
Sean Leonard,
Theodore Y. Ts'o,
Robert Kieffer,
Sergey Prokhorenko,
LiosK.</t>
      <t>As well as all of those in the IETF community and on GitHub to who contributed
to the discussions which resulted in this document.</t>
      <t>This document draws heavily on the OSF DCE specification for UUIDs.
Ted Ts'o provided helpful comments, especially on the byte ordering
section which we mostly plagiarized from a proposed wording he
supplied (all errors in that section are our responsibility,
however).</t>
      <t>We are also grateful to the careful reading and bit-twiddling of Ralf
S. Engelschall, John Larmouth, and Paul Thorpe.  Professor Larmouth
was also invaluable in achieving coordination with ISO/IEC.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

        <reference anchor="C309" target="https://pubs.opengroup.org/onlinepubs/9696999099/toc.pdf">
          <front>
            <title>DCE:
            <title>X/Open DCE: Remote Procedure Call</title>
            <author>
              <organization/>
              <organization>X/Open Company Limited</organization>
            </author>
            <date year="1994" month="August"/>
          </front>
          <seriesInfo name="ISBN" value="1-85912-041-5"/>
          <refcontent>Open Group
          <seriesInfo name="Open CAE Specification C309</refcontent> Specification" value="C309"/>
        </reference>

        <reference anchor="X667">
          <front>
            <title>Information Technology, "Procedures technology - Open Systems Interconnection -
            Procedures for the operation of OSI Registration Authorities:
            Generation and registration of Universally Unique Identifiers
            (UUIDs) and their use as ASN.1 Object Identifier components"</title> object identifier
            components</title>
            <author>
              <organization/>
              <organization>ITU-T</organization>
            </author>
            <date month="September" year="2004"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9834-8:2004"/>
          <seriesInfo name="ITU-T Rec." Recommendation" value="X.667"/>
        </reference>
        <reference anchor="RFC8141">
          <front>
            <title>Uniform Resource Names (URNs)</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="April" year="2017"/>
            <abstract>
              <t>A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8141"/>
          <seriesInfo name="DOI" value="10.17487/RFC8141"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml"/>

        <reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
          <front>
            <title>Secure Hash Standard</title> Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization> Technology
              (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS" value="PUB 180-4"/> name="FIPS PUB" value="180-4"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>

        <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
            <author>
              <organization>National Institute of Standards and Technology</organization> Technology
              (NIST)</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS" value="PUB 202"/> name="FIPS PUB" value="202"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>

        <reference anchor="C311" target="https://pubs.opengroup.org/onlinepubs/9696989899/toc.pdf">
          <front>
            <title>DCE 1.1: Authentication and Security Services</title>
            <author>
              <organization/>
              <organization>The Open Group</organization>
            </author>
            <date year="1997"/> year="1997" month="August"/>
          </front>
          <refcontent>Open
          <seriesInfo name="Open Group CAE Specification C311</refcontent>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/> Specification" value="C311"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<reference anchor="RFC1321"> anchor="IEEE802.11bh" target="https://standards.ieee.org/ieee/802.11bh/10525/">
  <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author fullname="R. Rivest" initials="R." surname="Rivest"/>
            <date month="April" year="1992"/>
            <abstract>
              <t>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information
    <title>IEEE Draft Standard for the Internet community. It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC1738">
          <front>
            <title>Uniform Resource Locators (URL)</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <author fullname="M. McCahill" initials="M." surname="McCahill"/>
            <date month="December" year="1994"/>
            <abstract>
              <t>This document specifies a Uniform Resource Locator (URL), the syntax Information technology--Telecommunications and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1738"/>
          <seriesInfo name="DOI" value="10.17487/RFC1738"/>
        </reference>
        <reference anchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many exchange between systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, Local and requests discussion metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and suggestions for improvements.</t>
            </abstract> Physical Layer (PHY) Specifications Amendment: Enhancements for Extremely High Throughput (EHT)</title>
    <author>
      <organization>IEEE</organization>
    </author>
    <date year="2023" month="March"/>
  </front>
  <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/> name="Electronic ISBN" value="978-1-5044-9520-2"/>
</reference>

<reference anchor="RFC4122"> anchor="Err1957" quote-title="false" target="https://www.rfc-editor.org/errata/eid1957">
   <front>
            <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
            <author fullname="P. Leach" initials="P." surname="Leach"/>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <author fullname="R. Salz" initials="R." surname="Salz"/>
            <date month="July" year="2005"/>
            <abstract>
              <t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t>
              <t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]</t>
            </abstract>
      <title>Erratum ID 1957</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
          <seriesInfo name="RFC" value="4122"/>
          <seriesInfo name="DOI" value="10.17487/RFC4122"/>
   <refcontent>RFC 4122</refcontent>
</reference>

<reference anchor="RFC5234"> anchor="Err3546" quote-title="false" target="https://www.rfc-editor.org/errata/eid3546">
   <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
      <title>Erratum ID 3546</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
   <refcontent>RFC 4122</refcontent>
</reference>

<reference anchor="RFC6151"> anchor="Err4976" quote-title="false" target="https://www.rfc-editor.org/errata/eid4976">
   <front>
            <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
      <title>Erratum ID 4976</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
          <seriesInfo name="RFC" value="6151"/>
          <seriesInfo name="DOI" value="10.17487/RFC6151"/>
   <refcontent>RFC 4122</refcontent>
</reference>

<reference anchor="RFC6194"> anchor="Err4975" quote-title="false"
target="https://www.rfc-editor.org/errata/eid4975">
   <front>
            <title>Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms</title>
            <author fullname="T. Polk" initials="T." surname="Polk"/>
            <author fullname="L. Chen" initials="L." surname="Chen"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
      <title>Erratum ID 4975</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
          <seriesInfo name="RFC" value="6194"/>
          <seriesInfo name="DOI" value="10.17487/RFC6194"/>
   <refcontent>RFC 4122</refcontent>
</reference>

<reference anchor="RFC7042"> anchor="Err5560" quote-title="false"
target="https://www.rfc-editor.org/errata/eid5560">
   <front>
            <title>IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Abley" initials="J." surname="Abley"/>
            <date month="October" year="2013"/>
            <abstract>
              <t>Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.</t>
            </abstract>
      <title>Erratum ID 5560</title>
      <author>
         <organization>RFC Errata</organization>
      </author>
   </front>
          <seriesInfo name="BCP" value="141"/>
          <seriesInfo name="RFC" value="7042"/>
          <seriesInfo name="DOI" value="10.17487/RFC7042"/>
   <refcontent>RFC 4122</refcontent>
</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 in a given registry prudently, guidance describing the conditions under 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 for the documentation of these guidelines

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/>

<!-- [rfced] RFC 1738 has been obsoleted by specification authors, in order RFC 4248.  We have updated
     to assure that the provided guidance for the IANA Considerations is clear and addresses cite the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes latter.  Please let us know any objections.

Original:
   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
              Resource Locators (URL)", 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="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="January" year="2019"/>
            <abstract>
              <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t>This document obsoletes 1738, DOI 10.17487/RFC1738,
              December 1994, <https://www.rfc-editor.org/info/rfc1738>.

Current:
   [RFC4248]  Hoffman, P., "The telnet URI Scheme", RFC 7719 and updates 4248, DOI
              10.17487/RFC4248, October 2005,
	      <https://www.rfc-editor.org/info/rfc4248>.
-->

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/>

<!--[rfced] RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </reference>
        <reference anchor="RFC8937">
          <front>
            <title>Randomness Improvements for Security Protocols</title>
            <author fullname="C. Cremers" initials="C." surname="Cremers"/>
            <author fullname="L. Garratt" initials="L." surname="Garratt"/>
            <author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/>
            <author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
            <author fullname="C. Wood" initials="C." surname="Wood"/>
            <date month="October" year="2020"/>
            <abstract>
              <t>Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead 7042 has been obsoleted by RFC 9542.  We have updated
     to critical and systemic security problems. This document describes a way for security protocol implementations point to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.</t>
              <t>This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8937"/>
          <seriesInfo name="DOI" value="10.17487/RFC8937"/>
        </reference> latter.  Please let us know any objections.-->

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.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.9499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8937.xml"/>

        <reference anchor="X500">
          <front>
            <title>Information technology – - Open Systems Interconnection – - The
            Directory: Overview of concepts, models and services</title>
            <author>
              <organization/>
              <organization>ITU-T</organization>
            </author>
            <date year="2019"/> year="2019" month="October"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9594-1"/>
          <seriesInfo name="ITU-T Rec." Recommendation" value="X.500"/>
        </reference>

        <reference anchor="X660">
          <front>
            <title>Information technology – - Procedures for the operation of
            object identifier registration authorities: General procedures and
            top arcs of the international object identifier tree</title>
            <author>
              <organization/>
              <organization>ITU-T</organization>
            </author>
            <date month="July" year="2011"/>
          </front>
          <seriesInfo name="ISO/IEC" value="9834-1"/>
          <seriesInfo name="ITU-T Rec." Recommendation" value="X.660"/>
        </reference>

        <reference anchor="X680">
          <front>
            <title>Information Technology - Abstract Syntax Notation One
            (ASN.1) &amp; ASN.1 encoding rules</title>
            <author>
              <organization/>
              <organization>ITU-T</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
          <seriesInfo name="ITU-T Rec." Recommendation" value="X.680"/>
        </reference>

        <reference anchor="LexicalUUID" target="https://github.com/twitter-archive/cassie">
          <front>
            <title>A Scala client for Cassandra</title>
            <title>Cassie</title>
            <author>
              <organization>Twitter</organization>
            </author>
            <date year="2012" month="November"/>
          </front>
          <seriesInfo name="commit" value="f6da4e0"/>
          <refcontent>commit f6da4e0</refcontent>
        </reference>

<!-- [rfced] Please review the title for reference [Snowflake] as the
     URL navigates to a page titled "snowflake-2010", and we were
     unable to find a URL with the title below.

Current:
   [Snowflake]
              Twitter, "Snowflake is a network service for generating
              unique ID numbers at high scale with some simple
              guarantees.", commit b3f6a3c, May 2014,
              <https://github.com/twitter-
              archive/snowflake/releases/tag/snowflake-2010>.
-->

        <reference anchor="Snowflake" target="https://github.com/twitter-archive/snowflake/releases/tag/snowflake-2010"> target="https://github.com/twitter-archive/snowflake">
          <front>
            <title>Snowflake is a network service for generating unique ID
            numbers at high scale with some simple guarantees.</title>
            <author>
              <organization>Twitter</organization>
            </author>
            <date year="2014" month="May"/>
          </front>
          <seriesInfo name="Commit" value="b3f6a3c"/>
          <refcontent>commit ec40836</refcontent>
        </reference>

        <reference anchor="Flake" target="https://github.com/boundary/flake">
          <front>
            <title>Flake: A decentralized, k-ordered id generation service in Erlang</title>
            <author>
              <organization>Boundary</organization>
            </author>
            <date year="2017" month="February"/>
          </front>
          <seriesInfo name="Commit" value="15c933a"/>
          <refcontent>commit 15c933a</refcontent>
        </reference>

        <reference anchor="ShardingID" target="https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c">
          <front>
            <title>Sharding &amp; IDs at Instagram</title>
            <author>
              <organization>Instagram Engineering</organization>
            </author>
            <date year="2012" month="December"/>
          </front>
        </reference>

        <reference anchor="KSUID" target="https://github.com/segmentio/ksuid">
          <front>
            <title>K-Sortable Globally Unique IDs</title>
            <author>
              <organization>Segment</organization>
            </author>
            <date year="2020" month="July"/>
          </front>
          <seriesInfo name="Commit" value="bf376a7"/>
          <refcontent>commit bf376a7</refcontent>
        </reference>

        <reference anchor="Elasticflake" target="https://github.com/ppearcy/elasticflake">
          <front>
            <title>Sequential UUID / Flake ID generator pulled out of elasticsearch common</title>
            <author initials="P." surname="Pearcy" fullname="Paul Pearcy">
              <organization/>
            </author>
            <date year="2015" month="January"/>
          </front>
          <seriesInfo name="Commit" value="dd71c21"/>
          <refcontent>commit dd71c21</refcontent>
        </reference>

        <reference anchor="FlakeID" target="https://github.com/T-PWK/flake-idgen">
          <front>
            <title>Flake ID Generator</title>
            <author initials="T." surname="Pawlak" fullname="Tom Pawlak">
            <author>
              <organization/>
            </author>
            <date year="2020" month="April"/>
          </front>
          <seriesInfo name="Commit" value="fcd6a2f"/>
          <refcontent>commit fcd6a2f</refcontent>
        </reference>

        <reference anchor="Sonyflake" target="https://github.com/sony/sonyflake">
          <front>
            <title>A distributed unique ID generator inspired by Twitter's Snowflake</title>
            <author>
              <organization>Sony</organization>
            </author>
            <date year="2020" month="August"/>
          </front>
          <seriesInfo name="Commit" value="848d664"/>
          <refcontent>commit 848d664</refcontent>
        </reference>

        <reference anchor="orderedUuid" target="https://itnext.io/laravel-the-mysterious-ordered-uuid-29e7500b4f8">
          <front>
            <title>Laravel: The mysterious "Ordered UUID"</title>
            <author initials="I. B." surname="Cabrera" fullname="Italo Baeza Cabrera">
              <organization/>
            </author>
            <date year="2020" month="January"/>
          </front>
        </reference>

        <reference anchor="COMBGUID" target="https://github.com/richardtallent/RT.Comb">
          <front>
            <title>Creating sequential GUIDs in C# for MSSQL or PostgreSql</title>
            <author initials="R." surname="Tallent" fullname="Richard Tallent">
            <author>
              <organization/>
            </author>
            <date year="2020" month="December"/>
          </front>
          <seriesInfo name="Commit" value="2759820"/>
          <refcontent>commit 2759820</refcontent>
        </reference>

        <reference anchor="ULID" target="https://github.com/ulid/spec">
          <front>
            <title>Universally Unique Lexicographically Sortable Identifier</title>
            <author initials="A." surname="Feerasta" fullname="Alizain Feerasta">
            <author>
              <organization/>
            </author>
            <date year="2019" month="May"/>
          </front>
          <seriesInfo name="Commit" value="d0c7170"/>
        </reference>

        <reference anchor="SID" target="https://github.com/chilts/sid">
          <front>
            <title>sid : generate sortable identifiers</title>
            <author initials="A." surname="Chilton" fullname="Andrew Chilton">
            <author>
              <organization/>
            </author>
            <date year="2019" month="June"/>
          </front>
          <seriesInfo name="Commit" value="660e947"/>
        </reference>

        <reference anchor="pushID" target="https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html">
          <front>
            <title>The 2^120 Ways to Ensure Unique Identifiers</title>
            <author>
            <author fullname="Michael Lehenbauer" surname="Lehenbauer" initials="M.">
              <organization>Google</organization>
            </author>
            <date year="2015" month="February"/>
          </front>
        </reference>

        <reference anchor="XID" target="https://github.com/rs/xid">
          <front>
            <title>Globally Unique ID Generator</title>
            <author initials="O." surname="Poitrey" fullname="Olivier Poitrey">
            <author>
              <organization/>
            </author>
            <date year="2020" month="October"/>
          </front>
          <seriesInfo name="Commit" value="efa678f"/>
          <refcontent>commit efa678f</refcontent>
        </reference>

        <reference anchor="ObjectID" target="https://docs.mongodb.com/manual/reference/method/ObjectId/">
          <front>
            <title>ObjectId - MongoDB Manual</title>
            <title>ObjectId</title>
            <author>
              <organization>MongoDB</organization>
            </author>
            <date/>
          </front>
        </reference>

        <reference anchor="CUID" target="https://github.com/ericelliott/cuid">
          <front>
            <title>Collision-resistant ids optimized for horizontal scaling and performance.</title>
            <author initials="E." surname="Elliott" fullname="Eric Elliott">
            <author>
              <organization/>
            </author>
            <date year="2020" month="October"/>
          </front>
          <seriesInfo name="Commit" value="215b27b"/>
          <refcontent>commit 215b27b</refcontent>
        </reference>

        <reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/6210/">
          <front>
            <title>IEEE Standard for Floating-Point Arithmetic.</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2019" month="July"/>
          </front>
          <seriesInfo name="Series" name="IEEE Std" value="754-2019"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
        </reference>

        <reference anchor="URNNamespaces" target="https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml"> target="https://www.iana.org/assignments/urn-namespaces/">
          <front>
            <title>Uniform Resource Names (URN) Namespaces</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date year="2022" month="November" day="18"/>
          </front>
        </reference>

        <reference anchor="Python" target="https://docs.python.org/3/library/uuid.html">
          <front>
            <title>UUID
            <title>uuid - UUID objects according to RFC</title> RFC 4122</title>
            <author>
              <organization>Python</organization>
            </author>
            <date year="2023" month="May" day="23"/>
          </front>
        </reference>

<!-- [rfced] For reference [Microsoft], the provided URL navigates to
     a page titled "1.1 Glossary", where "curly braced GUID string" is
     defined lower on the page. To better match the title provided,
     may we update to the following URL with the title "2.3.4.3 GUID -
     Curly Braced String Representation"?

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d

Original:
   [Microsoft]
              Microsoft, "curly braced GUID string", 3 April 2023,
              <https://learn.microsoft.com/en-
              us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-
              a93b-2f5c833d7d92>.
-->
        <reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-a93b-2f5c833d7d92"> target="https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d">
          <front>
            <title>curly braced
            <title>2.3.4.3 GUID string</title> - Curly Braced String Representation</title>
            <author>
              <organization>Microsoft</organization>
            </author>
            <date year="2023" month="April" day="03"/> month="April"/>
          </front>
        </reference>

        <reference anchor="MS_COM_GUID" target="https://devblogs.microsoft.com/oldnewthing/20220928-00/?p=107221">
          <front>
            <title>Why does COM express GUIDs in a mix of big-endian and little-endian? Why can’t can't it just pick a side and stick with it?</title>
            <author initials="R." surname="Chen" fullname="Raymond Chen">
              <organization/>
              <organization>Microsoft</organization>
            </author>
            <date year="2022" month="September" day="28"/> month="September"/>
          </front>
        </reference>

<!-- [rfced] Please review the URL for reference [IBM_NCS] and let us
     know if you would like to update to the newest version of this
     manual:

https://www.ibm.com/docs/en/aix/7.3?topic=u-uuid-get-command

Current:
   [IBM_NCS]  IBM, "uuid_gen Command (NCS)", March 2023,
              <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
              command-ncs>.
-->

        <reference anchor="IBM_NCS" target="https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-command-ncs">
          <front>
            <title>uuid_gen Command (NCS)</title>
            <author>
              <organization>IBM</organization>
            </author>
            <date year="2023" month="March" day="23"/> month="March"/>
          </front>
        </reference>

        <reference anchor="RANDOM" target="https://peteroupc.github.io/random.html">
          <front>
            <title>Random Number Generator Recommendations for Applications</title>
            <author initials="P." surname="Occil" fullname="Peter Occil">
              <organization/>
            </author>
            <date month="June" year="2023"/>
          </front>
        </reference>

      </references>
    </references>
    <?line 2069?>

<section anchor="test_vectors">
      <name>Test Vectors</name>
      <t>Both UUIDv1 and UUIDv6 test vectors utilize the same 60 bit 60-bit
      timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February 22,
      2022 2:22:22.000000 PM GMT-05:00</t> GMT-05:00.</t>
      <t>Both UUIDv1 and UUIDv6 utilize the same values in clock_seq, clock_seq and node. All
      node; all of which have been generated with random data.  For the
      randomized node, the least significant bit of the first octet is set to
      a value of 1 as per <xref target="unidentifiable"/>.
Thus  Thus, the starting
      value 0x9E6BDECED846 was changed to 0x9F6BDECED846.</t>
      <t>The pseudocode used for converting from a 64 bit 64-bit Unix timestamp to a 100ns
      100 ns Gregorian timestamp value has been left in the document for
      reference purposes.</t>

      <figure>
        <name>Test Vector Timestamp Pseudo-code</name>
        <sourcecode type="code"><![CDATA[ Pseudocode</name>

<!--[rfced] May we update the pseudocode in Figure 15 as follows (note there are multiple changes):

Original:

   # Gregorian to Unix Offset:
   # The number of 100-ns intervals between the
   # UUID epoch 1582-10-15 00:00:00
   # and the Unix epoch 1970-01-01 00:00:00
   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

   # Unix 64 bit Nanosecond Timestamp:
   # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
   # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

   # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
   # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

   # Work:
   # Greg_100_ns = (1645557742000000000/100)+122192928000000000
   # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

   # Final:
   # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000

Perhaps:

   # Gregorian-to-Unix Offset:
   # The number of 100 ns intervals between the
   # UUID Epoch 1582-10-15 00:00:00
   # and the Unix Epoch 1970-01-01 00:00:00
   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

   # Unix 64-bit Nanosecond Timestamp:
   # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
   # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

   # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
   # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

   # Work:
   # Greg_100_ns = (1645557742000000000/100)+122192928000000000
   # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

   # Final:
   # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
-->
        <sourcecode type="pseudocode"><![CDATA[
# Gregorian-to-Unix Offset:
# The number of 100 ns intervals between the
# UUID Epoch 1582-10-15 00:00:00
# and the Unix Epoch 1970-01-01 00:00:00
# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

# Unix 64-bit Nanosecond Timestamp:
# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

# Work:
# Greg_100_ns = (1645557742000000000/100)+122192928000000000
# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

# Final:
# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
]]></sourcecode>
      </figure>
      <section anchor="uuidv1_example">
        <name>Example of a UUIDv1 Value</name>

        <figure>
          <name>UUIDv1 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field      bits value
-------------------------------------------
time_low   32   0xC232AB00
time_mid   16   0x9414
ver         4   0x1
time_high  12   0x1EC
var         2   0b10
clock_seq  14   0b11, 0x3C8
node       48   0x9F6BDECED846
-------------------------------------------
total      128
-------------------------------------------
final: C232AB00-9414-11EC-B3C8-9F6BDECED846
]]></artwork>
        </figure>

<!--[rfced] We see "Ver Var" in the title of Figure 19 and "Ver/Var"
     in the title of Figure 20.  Should these be made uniform?-->

      </section>
      <section anchor="uuidv3_example">
        <name>Example of a UUIDv3 Value</name>
        <t>The MD5 computation from is detailed in <xref target="v3md5"/>
        using the DNS Namespace ID value and the Name "www.example.com".
while the
        The field mapping and all values are illustrated in <xref
        target="v3fields"/>.
Finally  Finally, to further illustrate the bit swapping
        for version and variant variant, see <xref target="v3vervar"/>.</t>

        <figure anchor="v3md5">
          <name>UUIDv3 Example MD5</name>
          <artwork><![CDATA[
Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:             www.example.com
------------------------------------------------------
MD5:              5df418813aed051548a72f4a814cf09e
]]></artwork>
        </figure>

        <figure anchor="v3fields">
          <name>UUIDv3 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field     bits value
-------------------------------------------
md5_high  48   0x5df418813aed
ver        4   0x3
md5_mid   12   0x515
var        2   0b10
md5_low   62   0b00, 0x8a72f4a814cf09e
-------------------------------------------
total     128
-------------------------------------------
final: 5df41881-3aed-3515-88a7-2f4a814cf09e
]]></artwork>
        </figure>

        <figure anchor="v3vervar">
          <name>UUIDv3 Example Ver Var bit swaps</name> Ver/Var Bit Swaps</name>
          <artwork><![CDATA[
MD5 hex and dash:      5df41881-3aed-0515-48a7-2f4a814cf09e
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 5df41881-3aed-3515-88a7-2f4a814cf09e
]]></artwork>
        </figure>

      </section>
      <section anchor="uuidv4_example">
        <name>Example of a UUIDv4 Value</name>
        <t>This UUIDv4 example was created by generating 16 bytes of random
        data resulting in the hexadecimal value of
        919108F752D133205BACF847DB4148A8. This is then used to fill out the
        fields as shown in <xref target="v4fields"/>.</t>
        <t>Finally
        <t>Finally, to further illustrate the bit swapping for version and variant
        variant, see <xref target="v4vervar"/>.</t>

        <figure anchor="v4fields">
          <name>UUIDv4 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field     bits value
-------------------------------------------
random_a  48   0x919108f752d1
ver        4   0x4
random_b  12   0x320
var        2   0b10
random_c  62   0b01, 0xbacf847db4148a8
-------------------------------------------
total     128
-------------------------------------------
final: 919108f7-52d1-4320-9bac-f847db4148a8
]]></artwork>
        </figure>

        <figure anchor="v4vervar">
          <name>UUIDv4 Example Ver/Var bit swaps</name> Bit Swaps</name>
          <artwork><![CDATA[
Random hex:            919108f752d133205bacf847db4148a8
Random hex and dash:   919108f7-52d1-3320-5bac-f847db4148a8
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 919108f7-52d1-4320-9bac-f847db4148a8
]]></artwork>
        </figure>

      </section>
      <section anchor="uuidv5_example">
        <name>Example of a UUIDv5 Value</name>
        <t>The SHA-1 computation from form is detailed in <xref target="v5sha1"/> target="v5sha1"/>,
        using the DNS Namespace ID value and the Name "www.example.com".
while the  The
        field mapping and all values are illustrated in <xref
        target="v5fields"/>.
Finally  Finally, to further illustrate the bit swapping
        for version and variant and the unused/discarded part of the SHA-1 value
        value, see <xref target="v5vervar"/>.</t>

        <figure anchor="v5sha1">
          <name>UUIDv5 Example SHA-1</name>
          <artwork><![CDATA[
Namespace (DNS):  6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:             www.example.com
----------------------------------------------------------
SHA-1:            2ed6657de927468b55e12665a8aea6a22dee3e35
]]></artwork>
        </figure>

        <figure anchor="v5fields">
          <name>UUIDv5 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field      bits value
-------------------------------------------
sha1_high  48   0x2ed6657de927
ver         4   0x5
sha1_mid   12   0x68b
var         2   0b10
sha1_low   62   0b01, 0x5e12665a8aea6a2
-------------------------------------------
total      128
-------------------------------------------
final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
]]></artwork>
        </figure>

<!--[rfced] Please review Figure 24 for line breaking of "-2dee3e35"
     and let us know if any updates are necessary.-->

        <figure anchor="v5vervar">
          <name>UUIDv5 Example Ver/Var bit swaps Bit Swaps and discarded Discarded SHA-1 segment</name> Segment</name>
          <artwork><![CDATA[
SHA-1 hex and dash:    2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final:                 2ed6657d-e927-568b-95e1-2665a8aea6a2
Discarded:                                                 -2dee3e35
]]></artwork>
        </figure>

      </section>
      <section anchor="uuidv6_example">
        <name>Example of a UUIDv6 Value</name>
        <figure>
          <name>UUIDv6 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field       bits value
-------------------------------------------
time_high   32   0x1EC9414C
time_mid    16   0x232A
ver          4   0x6
time_high   12   0xB00
var          2   0b10
clock_seq   14   0b11, 0x3C8
node        48   0x9F6BDECED846
-------------------------------------------
total       128
-------------------------------------------
final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846
]]></artwork>
        </figure>
      </section>
      <section anchor="uuidv7_example">
        <name>Example of a UUIDv7 Value</name>
        <t>This example UUIDv7 test vector utilizes a well-known Unix epoch Epoch
        timestamp with millisecond precision to fill the first 48 bits.</t>
        <t>rand_a and rand_b are filled with random data.</t>
        <t>The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00
        GMT-05:00, represented as 0x017F22E279B0 or 1645557742000</t> 1645557742000.</t>
        <figure>
          <name>UUIDv7 Example Test Vector</name>
          <artwork><![CDATA[
-------------------------------------------
field       bits value
-------------------------------------------
unix_ts_ms  48   0x017F22E279B0
ver          4   0x7
rand_a      12   0xCC3
var          2   0b10
rand_b      62   0b01, 0x8C4DC0C0C07398F
-------------------------------------------
total       128
-------------------------------------------
final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="ill_examples">
      <name>Illustrative Examples</name>
      <t>The following sections contain illustrative examples which that serve to
      show how one may use UUIDv8 <xref target="uuidv8"/> (<xref target="uuidv8"/>) for custom and/or
      experimental application based application-based logic.  The examples below have not been
      through the same rigorous testing, prototyping, and feedback loop that
      other algorithms in this document have undergone.  The authors encouraged implementors
      encourage implementers to create your their own UUIDv8 algorithm rather than
      use the items defined in this section.</t>
      <section anchor="uuidv8_example">
        <name>Example of a UUIDv8 Value (time-based)</name> (Time-Based)</name>
        <t>This example UUIDv8 test vector utilizes a well-known 64 bit 64-bit Unix epoch
        Epoch timestamp with
10ns 10 ns precision, truncated to the least-significant, right-most,
        least significant, rightmost bits to fill the first 60 bits of
        custom_a and custom_b custom_b, while setting the version bits between these two
        segments to the version value of 8.</t>
        <t>The variant bits are set set; and the final segment, custom_c, is filled
        with random data.</t>
        <t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00
        GMT-05:00, represented as 0x2489E9AD2EE2E00 or 164555774200000000 (10ns-steps).</t>
        (10 ns-steps).</t>
        <figure>
          <name>UUIDv8 Example Time-based Time-Based Illustrative Example</name>
          <artwork><![CDATA[
-------------------------------------------
field     bits value
-------------------------------------------
custom_a  48   0x2489E9AD2EE2
ver        4   0x8
custom_b  12   0xE00
var        2   0b10
custom_c  62   0b00, 0xEC932D5F69181C0
-------------------------------------------
total     128
-------------------------------------------
final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0
]]></artwork>
        </figure>
      </section>
      <section anchor="uuidv8_example_name">
        <name>Example of a UUIDv8 Value (name-based)</name> (Name-Based)</name>
        <t>As per <xref target="uuidv5"/> target="uuidv5"/>, name-based UUIDs that desire want to use
        modern hashing algorithms <bcp14>MUST</bcp14> be created within the
        UUIDv8 space.

<!--[rfced] The structure of this list is difficult to parse.  We
     assume the citations apply to both algorithms listed before
     them.

Original:
These MAY leverage newer hashing algorithms, such as SHA-256 or
SHA-512 defined by [FIPS180-4], SHA-3 or SHAKE defined by [FIPS202],
or even algorithms that have not been defined yet.

Perhaps A:
These MAY leverage newer hashing algorithms such as SHA-256
or SHA-512 (as defined by [FIPS180-4]), SHA-3 or SHAKE (as defined by
[FIPS202]), or even algorithms that have not been defined yet.

Perhaps B:
These MAY leverage newer hashing algorithms, such as:
-SHA-256 or SHA-512 (defined by [FIPS180-4]),
-SHA-3 or SHAKE (defined by [FIPS202]), or
-algorithms that have not yet been defined.

-->
        These <bcp14>MAY</bcp14> leverage newer hashing algorithms such as
        SHA-256 or SHA-512 (as defined by <xref target="FIPS180-4"/>, target="FIPS180-4"/>), SHA-3
        or SHAKE (as defined by <xref target="FIPS202"/>, target="FIPS202"/>), or even algorithms
        that have not been defined yet.</t>

<!--[rfced] May we update this text for accuracy?

Original:
   A SHA-256 version of Appendix A.4 is detailed in Figure 28 as an
   illustrative example detailing how this can be achieved.

Perhaps:
   A SHA-256 version of the SHA-1 computation in Appendix A.4 is
   detailed in Figure 28 as an illustrative example detailing how this
   can be achieved.
-->

        <t>A SHA-256 version of the SHA-1 computation in <xref target="uuidv5_example"/> is detailed in
        <xref target="v8sha256"/> as an illustrative example detailing how
        this can be achieved.  The creation of the name-based UUIDv8 value in
        this section follows the same logic defined in <xref target="uuidv5"/>
        with the difference being SHA-256 in place of SHA-1.</t>
        <t>The field mapping and all values are illustrated in <xref
        target="v8fieldssha256"/>.
Finally  Finally, to further illustrate the bit
        swapping for version and variant and the unused/discarded part of the
        SHA-256 value value, see <xref target="v8vervar"/>.  An important note for
        secure hashing algorithms that produce outputs of an arbitrary size,
        such as those found in SHAKE, is that the output hash
        <bcp14>MUST</bcp14> be 128 bits or larger.</t>
        <figure anchor="v8sha256">
          <name>UUIDv8 Example SHA256</name>
          <artwork><![CDATA[
Namespace (DNS):       6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name:                  www.example.com
----------------------------------------------------------------
SHA-256:
5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8
]]></artwork>
        </figure>
        <figure anchor="v8fieldssha256">
          <name>UUIDv8 Example Name-Based SHA-256 Illustrative Example</name>
          <artwork><![CDATA[
-------------------------------------------
field     bits value
-------------------------------------------
custom_a  48   0x5c146b143c52
ver        4   0x8
custom_b  12   0xafd
var        2   0b10
custom_c  62   0b00, 0x38a375d0df1fbf6
-------------------------------------------
total     128
-------------------------------------------
final: 5c146b14-3c52-8afd-938a-375d0df1fbf6
]]></artwork>
        </figure>

        <figure anchor="v8vervar">
          <name>UUIDv8 Example Ver/Var bit swaps Bit Swaps and discarded Discarded SHA-256 segment</name> Segment</name>
          <artwork><![CDATA[
A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D:                                     -fe12a66b645f72f6158759387e51f3c8
]]></artwork>
        </figure>
        <t>Examining <xref target="v8vervar"/>:</t>

        <ul spacing="compact">
          <li>
            <t>Line spacing="normal">
          <li>Line A details the full SHA-256 as a hexadecimal value with the
          dashes inserted.</t>
          </li>
          <li>
            <t>Line inserted.</li>
          <li>Line B details the version and variant hexadecimal positions positions,
          which must be overwritten.</t>
          </li>
          <li>
            <t>Line overwritten.</li>
          <li>Line C details the final value after the ver/var ver and var have been overwritten.</t>
          </li>
          <li>
            <t>Line
          overwritten.</li>
          <li>Line D details the discarded, discarded leftover values from the original
          SHA-256 computation.</t>
          </li> computation.</li>
        </ul>
      </section>
    </section>
    <section anchor="Acknowledgements" toc="default" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors gratefully acknowledge the contributions of <contact
      fullname="Rich Salz"/>, <contact fullname="Michael Mealling"/>, <contact
      fullname="Ben Campbell"/>, <contact fullname="Ben Ramsey"/>, <contact
      fullname="Fabio Lima"/>, <contact fullname="Gonzalo Salgueiro"/>,
      <contact fullname="Martin Thomson"/>, <contact fullname="Murray
      S. Kucherawy"/>, <contact fullname="Rick van Rein"/>, <contact
      fullname="Rob Wilton"/>, <contact fullname="Sean Leonard"/>, <contact
      fullname="Theodore Y. Ts'o"/>, <contact fullname="Robert Kieffer"/>,
      <contact fullname="Sergey Prokhorenko"/>, and <contact
      fullname="LiosK"/>.</t>
      <t>As well as all of those in the IETF community and on GitHub to who
      contributed to the discussions that resulted in this document.</t>

 <!--[rfced] Will the reader easily know to which section "the byte
      ordering section" refers?  Or would a pointer to the section's
      title be preferable?

Original:
   This document draws heavily on the OSF DCE specification for UUIDs.
   Ted Ts'o provided helpful comments, especially on the byte ordering
   section which we mostly plagiarized from a proposed wording he
   supplied (all errors in that section are our responsibility,
   however).

-->

      <t>This document draws heavily on the OSF DCE specification (Appendix A of <xref target="C309" format="default"/>) for UUIDs.
      <contact fullname="Ted Ts'o"/> provided helpful comments.</t>
      <t>We are also grateful to the careful reading and bit-twiddling of
      <contact fullname="Ralf S. Engelschall"/>, <contact fullname="John
      Larmouth"/>, and <contact fullname="Paul Thorpe"/>.  <contact
      fullname="Professor Larmouth"/> was also invaluable in achieving
      coordination with ISO/IEC.</t>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+y96XIbWZYm+J9mfAdv0qZFVgMgAIJrdlYWRUkRrAwtLVKZ
WTY9I3MADtJTgDvK3cElFBrrd5hf82+eZR6ln2TOd5Z7rzsAioqMyKzqLEWY
RALudzn33LMv7XZ7c+P2NNrf3BjnoyyeJafRuIgnVTtNqkl7sUjHRXLbLiaj
Qa/fH6ZluzfY3BjF1WlUVuPNjXxY5tOkSsrT6BmeeEZf5lmZZOUCH1XFIqGP
ysVwlpZlmmfVw5xmuHh59WpzY56ebm5ENE6Rjmi8Zw9J+QwfVPmo/ts4mVc3
9NE+f1A+zIpkUgaPlHlRBR9F21E8GqXjJKvi6fQhGuVFkYyqNLt2n0en7d3N
jSqtprSaD1l6mxQlP0s//+siiS5e0EPpJKWPo50PHy5e0NPxcEigoMfpV/qt
SOLT6Oz91ebG3fVppIDa3Ph0J78QPOOKBu93+wRben5R3eQFbbgdCZR///Bj
UkTvO9GL+DYtsY1kFqfT0+jTwxif/NMoLUd5Z5TP8F1e0CTn+CS6fCirZFb6
kZ4X8Tj6rhO9S+JhPn4IhhrSN/80l487ae4G+pCNpvlijCHSjMD2rhP9kMSj
GzwgY4af6GDzP0+P/mlx10nGi2AgBl1aPUT5JPpjXN4QlKs8w46zvJjFFX3P
p3y+3z3hH+hE4+I6oQO/qap5ebq3N18My04+T7LrIl/MOzTwXp5N0yzBF3sn
h/TfyUn35GSPUKEzH090FDm8rRfnL0+j98ksr5LoXZGPaHlFEp3TaW7JgwVh
01saPfoOw0fnZy+jy3kyotMlNCaU5KXJo2VSpEmZZpNclxpFF5fP35xGvfbx
wUmv3+4Oeu0D+UqO92xxvSirqHdyMsDHfzo8PDp9ZKy3excvzwlNT473B+3j
0363O3jmvr360L6inYw6p9GfOjRQbZ//6B6jERmwtPKrZHST5dP8+qEVbbnN
lxE9EVU3ib1CsC3kBTqkt5cXNMl1StdOPjtjzEyrFJf4uySzZ+NsbAMU4fM0
xqobM27cmHIXI2AZaWHjLMokisvo7PJNpxe9Hf6ZbmXwIl3U2TzP6NdyK4Qx
oITf3786P+4Neqf2Az57dfHusnfcbQ/W4FZ2O2X0ymj9nev8dg8/MF7hzb03
F5dXHfzU4UGWsOsyGQGbvifEji4r2k9cKFDcfcYvbbkNbxhA8ZTOqKQBFoSR
BCx7r2R4+CNbgUb9bu9gLfZgmXQxPzyPeK22eyIwf+neaYjle3X5/Vl73y2e
Jk6K2aLiHbafx2UyFqhgTy/vq4SeGk6T9tsFzVBFrxbZCE/aQf4toUW7EwLU
6/18AnRM/60nQFGv0zvliwRcHrn7I/gD6niZFLfpKCmfTpN6vXDLRGCOQFRT
u/1KVukq9Pb7cifwg312tH98aj/oZ4Pu8eGp/WCfEcs+tR/0s4P+/uDUftDP
DnsHMgd+cJ+dDE7tB/3sqDuQ8fCDu7P9w1P7wT4bnJyc2g/22cn+0an9wMT0
oNt9EjE9OBm0e2voKI3xdTpaOTSL/uf/+L/lZJTN0nNVUpBMkyWM0fzA1U0S
vUghVOTFA53kLU43uQP+0pMjElfKVjTLx8lU0LjU069Ttd6Jsoyn7RIsY90u
aYxv3uUyv6gzilzoc+rpc40NxMtsYxrN/ZhM/PN5FBejEsNh/BSwzOzeL09A
UlzSgFFPYHT8JBgdH/cJRsRW+2sBdfwEQHmqQ7TqbIgt0zovH0ievI/e5EIE
o7dZEu0wK9uN/rPytCQb5WMImsVi2jxuuZw/JPd0x6fgkGuo0XVa3SyGEPz2
qru0Ioi1CYY3dOP3RjEJ0UltA2fRJQ0XR6NpCrkWJ3lOTxH0i3g97b2SgRuw
7reN6KyAMq1nltIyJ4fjeJAwFC+z/G4yjT8l376T0l7dK5JpQuyk3Kvia/9x
m5az5qTcrFFKWBZlSXWXF5/sjjEErlWKoYNYmEAfZYvZENJJXEU36fWNDVcS
+JKIlndDesQsicp0NqcPrhdxERO6JmXnW8E4aHfX86VzBeNwf3IY74+Yiz8N
hMN8Ac74sMebr8HmmQxByDBORoQGdBXTH5NxK/rUzotxUhCzTscOKoS7Bqw0
i14W0zi7frZ+k8913sYuj9rCVx/dZe9gdLK/z4h4eUNcnU5kLd6TJkIoUMSz
NjFiYr40anbNOy/11XY6Ltsxqabuyd5ochAf9ZKD+GBUF9z0FbqZJIrizC/s
pfU7dY9EL/0Klu8Ib/v3l0+6wWVyPQN5y/c+lawVBmv8ffuSFFeITdF303xY
1z/L9cu8lDEb1KXb7h59Hesm+0eHMT/3chqT2DV64v2dkxZZjB72kuCthqRM
66aNEl0HbYv2BK1x8RTv6F7OF9Mp4WJOEiJxBB2rxMg3TF+gOK7Ytaqk8WIK
HZeW0TiTg3Z3Pd2yrY/HR72R0GBe2VNO76r97o+/l/tGuEf7qG3ZbfA72+Aj
q7/KZ7SDO3pl+dwGX138ZDQ+jPsseF7m2cMTD62kR/mv5eMiSgFWng5J7B4H
RNKfFV2yeQrKMXwwOves9MT3EfSkCZf3ePzVPR4PjseHhwwLJVof6MasIxZV
ltxXHbpXU6LTt8m0TfJFewaZrUjzRWl0jy1Y7f5JckSC4HAwOa7TzR/k5VOW
6Pzb0dZbJZvA5a3VxFHO9aKKp3n0PE5+jInxDovE2G64eca687evn3/3JKJR
pCOQL1iv6Ertvb/qEIyGtZWfF4nwt9LfOwxegqSfbzMXfH15+d9+IFhG7/Ky
ui6Sy3+dPrKR9zJpdCWzLm2i93Vq/6x/dHBy3O8yvD788JStLqbpeK8k1ae2
uxX2BZabciLO8xvIT/SFI57egvDI9s6II8YEm1dE1YnsNA6pd/IUnj3ujo56
RyL6PGVzJOpMq3KvbND9Z/RBdGpXLWHzJW/ES8LlYyh3RrIdKRvnGN0oZriR
w69uhNSF5GTAbGC+KG/W7mVCBGBIwlnnOs+vp8mQRGLeGGjuXre/hzvX7xFy
3MUPZbvK27D7Fklb6MnHw+POTTWb1jaPi9b/P+md6I/0DmkIxGvxzgo70noS
8x0vZ5kLMIr+6UlXrNy7bxzLMg9+EmF/O01vobu8y1NSX5Ypn4mxjxxHMokP
j46ZuotRbO0Oxvmo7BCbvM7Hso9ZnC3iKQnREyJXpHnuzRJa43hPxxnv1bZo
n9LiX2OQF8+j1zzAelDrc+G2JvG0TKLt6E9/+lM0uklGzNHOn0TZCAajZDpN
86raGzXlofOcvoGToE36I3EnEr/pSpDyOK/SGeRZpmpQOn/MYdpn0Z2t+qRq
kubKChzBYLXALqf1khZAog+v4OccVb93MOwfMS2+ePny5dHBOsNjaXasTpok
CduU8MMevbF32O916weDsZzpi7f5apozgW8TXhEczkjTvqGzTUePqCMYZZkc
rJcKL/mj04jW1DZzxIf3b94QpMp5PKKvVu/t7u6uk8ZZzLuCSnqdQSAt9xZF
1s7c241fO/dLxIBuGg6NtPMyXxSkj/DU0Q4tYjfyy3hkx2dvzhrHCCW23WM+
/+6B3sgeu0pzfoL3sb83TYcF9CuIDMuEi6VaMVmU8CPlol8QAXv/6nz9CmUN
jTXuE7dpwy8URa/TUZGX+aRas0xSjousM7On5BZl7UW5B4MlOGe5d5dm4/yu
/Dgv8iof5dNyb1a2x9XDfC8+PEzGybDXPujH3fZgfDhoxyf7w3Z/cjA63t8f
H41P+rVdjhYFUUCCw4iuGwQKds+ZFrSSQNjSlvdIirDs8fIjCT8fHxF+xskt
mEvZ2Gg+HWfJXQWn0h6OtnvSP253u3u/m/+21z3q93u1tf/x5iEa54Q/NFmU
3M+JipReKIqjWXoPtWOYXhOfGhMCM+GYkmg7TfST3/Egozj7n//j/yHiU0V/
hqF5no4+0fvEthMx51X4gE0GafW7x2Sq+IGI9ZhYddJEgX67e9LuM5pePH/9
8c355WOXbThjeABn6fT34vR+76jT+12V09J+uxAhl+SJNpQoWmE7G5U10OCB
j/QA0zFsYYcm3H3kXj1/vXyc+4qy78/evHj7ep0tPSEZOl/MRx0l+ySiFzRj
Plu+Ulvv+YvoDVtmPLeFtY7WCZ8COxGYIJ7N51O1jq/xKqiaiAVEb0ejdNrc
Agzo7XY7itWkh9+vbtIyKmu293EyIeW/ZIsle7KIID3qInaeLiESK6maEjVH
Djs6dEyiD/HTPPpEmlUG75hg7M6yOOLnIx5wJnPR4nv9Y8JpIkrTXHlhWrKl
NRsnMMF6U9bmhghmGS5GjIuGrdNiZP3pjFaly7ojcYJQIb1OM17EAg4fukXs
VTybE6fOozdqeSOcmi9YGRGbuVyrGMcgb6hBnW71HW13c+MVW5QAa9Iod95e
vtqNXgTaqB/vZXabFjkzl2jnxfnL3ZZBOoMrxNOe6I9CAqM5zQvgw2q38nDp
A9Ls6DSJzRaEe1gePDj1p/hu814/pSJcaPyCWbJp0dEOnZg/tivbJ7t0cESh
SZnnIlI+hajILnPgtQ62PP8NaaXRMJFtEquZ59AUcAJ0nhV2RaRgAbh0oqvw
18gFZJhXp2NYP0vHYwjNmxvbcGoU+XghHo3P28/j0Sf4vrLxl/9V70RBenIK
v0SWR2oi3dyoOTTYd1Ea4iTsrIavWxhISRyF5PtZQrMTOtzGJe0e+D0ybKW7
Q6898AdFWhKksXs6vFCxozcm0D8Lgj20HlA2IsgP5nqBRm/xHeVidIPNL2M5
NhQH9DCyRzHj6/zHdDqNoz8mQ2Lk9DjNylSBkImnGsHc3iL0GsHeTYwy18vN
32Ykf5vwGkGvW3eT4oqWOa9Yh7MXSEqnNcTEMkFfYWGOIb8nGUEtpi3RVGUK
VVcWREyVZpA3wuGGRKImxH2xHUCOAMVuuCypOnI4aXC3bkCraHmzBBoDv04D
wxFHp0DUD2xbPFy0UbraHKRCp5NHbOrna2MeOjp1nIEcekJUQIgYQWqYZgFt
IMQto8+fNRLhyxeYWXI8TcMnhkKyLJIznA8q4GpyiJl5r7z0//kzokhoSAEL
CGaNYvGsuNlfvhDKPc/huEgqEBNCmfCESk9G6DqRkJ6MZVLg3QLXiD2CYk5B
3NZsTu/R6dD63+QsdQkBD+lLeZMvpmOAGHFeiO9iHpMTKSgAaEfPnB+ftyH0
Q+xpglHbhKhVehsrCZq5X5gEwbmm1HEGs02RxKVJAuERpTq+v9VQFC3cCp53
ekLvPi80Hs9SxEEk7PGcRTvxlJ5cXBO5v8sjQSpCJcLKaUJ7iq8T1j/hsCSK
DjXtuNun6cY1c01LDh9wou+qXTqYMziniOAsplUrcL1sbjA1ZSGM5EwBJNCw
AmWhZeczpvT4npkudhxHtzGpahxlRZdoUeDKlkJwhOYFvp14ep2ztkjTlCNi
qjQI42K5mBMfod3Rvui84QSjh6e53mdwGGZJvS7xCqjIGSgdIdcoFx5IYBkR
VkAwiGZM12g1WQKqSXpTKypzOYxKyCDwhGDIe+StgECRJFLGwncMEzzRp8nj
aJLe07MlSMmO0XFi/Hc3KdE4Pk2gQjwkcJUzWr9irp4vnwNtSx3Ntwomem9K
N48QpiqT6YTkm+mUCRcBhLCpRccCiy9+ZNDfSCgbr4iexGN0yCUJp3or6BLH
QyGk4jEknHOwlDHg1sQAxFjgVJrpm3JUU976JXH3JOB6aohXgwaMIIRiLQHo
DN6G5B72E1xE5aibG3XlWZHCBhqmU1wCSIFmboTL9E6wBqQMzph4NStk7LiT
SydrFOKa+8vJdNBLS/R4QgoTbZVZ2SgvK7ns29GHOQTx4NLj89fgOExplFiN
buLs2omaLJMSfD2QmnLpCHbwZEyTvKYrWWR1tshDYr+CG/KwXK0qBaUw0Avn
JLY9Y0dnwK+b1y8apxO2tUE9RHyIigDT5F5FAQtvUD7eYhFuumBrAQm4oA+k
dM7SShZliBR9Sh4ImSYpcUeWiFrhdZPB6LbJN8w+g4g7rBJXrWqPwSmy8J7J
JQNBRcwq1itXSbbOILqOmTjP8/liGhvVrC2sYyIA79lJzrQzXEfaGp1F6FGi
u7eQCz1bPheWjUVmUVlkC4RPRgOX2YrKERFnJkd0A4R6DB/8pVM6G0H/2NzA
ZW7ZISYTAkZVo/mjnI01bGv37pKMGBqsgSEcRSmiq+zCCkCjsUNYRURgiukU
iVZkKolMEBvCZE8AqkSdl+xxTu5jq0a8brDO23i6gIULJCWAnyKPu6GyHblT
uhlcVNCEUhhZHF3nOTifJ30txje+6U7l6LUPjJY275LxaAJ0IGO0SJUbERyS
ogIjFvpKnCUt2GcBpxFBgCDJvtxT4NrmRq8TvSE5EtfXRSDU12ESKz69HUQ7
nlfRJJ8/w2BxO/jyZVcQdE6b9ghJUnByD+Ue9Bb0jW2ijJ+QAU0kICon0DUq
gaFpXpA2ZpS0fSDRaAq5kM4KAc+6wZTtNYLiNJkqMwsnS8A9mhQmrZr1GTyO
zoqtGrY+w3ihyyIQ4Byz5JoPKbRcA3nZvphn6g+PnKpQOnFAVkab3XneRsSU
UAPwdbq7JAKT7qVIOCa2E4vNmM8EK+h1u+0sznJl698R4c/xWpTMc9q+Kfp8
Lr3V59LDueBsScibzVkIW2Tef4/lgEqmI9oqAFQksMWBZMaj0QJMiC0KbLp3
gqLG56gIxvjBg0HMVlM7Cby6EdZfIewCunvE/HmwhqjHiAdsFi7CN3+UtEQl
EaWn4pj4YcJLATrTa3oebPDjUKDhQ5W0hw9t/BuJrJHSJba1vCOKG48eeNs+
GEnjPtOyBALijUTIpu379dk5CaNjNlKaYSUSwZJoEYlOqnvalYl6jEQvVV0L
Xk/qRCdmlYPUKVzbclFMYOChfTEyJm6JHIs3MfO6qMi3CdFFYBF84HwR8F2o
a8VDUCO+vMqdCA0hUc+YhMAdBYJI+Fq06NZWQmvpGzfaOCE6MiV9PTobj1Ph
lVMSHk2IoF3dsiFjEt2mRbWgFbmZWGiG74d+K8BZoxoYA+tWyoo+tH9CAWcA
G9uZsdxhQYmmBJqlg9dnyq4hvqOH9OttPoU2Rjx2zIeWTyal09YIwKI2Ol0X
YiYP9iDSBMmTNSklkyvtBGlGQjbPaMQk2wbYQVxbamm7CVc3TsdM1MBMCNEW
pO0SZlR3UAIrJkB8Qdhf04yVizW3JYqU3oEu4hm+CA9O/CX5rxV5vQnCqUjv
4NVOPuLVvVjw/vlcaaREgqHAZeRmtMTocEdMuCFBOGofworYG9sWi+va53RH
iOQWKs2UWFYl0j0dlIp2OQFwxhG6GjoBLk+Q4fg9ZlSYbdzy7niVoRvCoOYw
xDX5SK1wN7BxTIX6sHiBe9Q4NNI0bkX5jOYxUke6/yV6SIiC8WrZpURflTCP
2aLBtkh/v6kYRCZ+OtvMH28gMxKJBWHi95u2GtYgaPUQ5/FE7zAUY5vrY7kg
pmv5YD5X4jKsOxEK5XC8ElUiHeS6umlBO6PzeCCqQIKCxLYqCQeM9ywgtiUw
ZoYRIQms5RmIPh9+InxiRGRBCCI/sOfzQ1pQ+tRbTFDPxlOnuc3AX9vBZPDV
1EIfmQ/Q8yqrfD5lIzh98Nstpu6jauuL3isEsdClIh5y1glCR/i7IJJXHnHR
oPy1i5Ra9eUr/4UPr5TXXJikfB2ELfL3HHcoX7k4QP4ijOeT7991XLicn9Qt
tuPC0WReCxPTsTmIi78JgrF0SfSuC3XiRyy0Sb5/3/FBRDJ2AEQXtcLfSPSJ
fGlBHfzFn+zTtx0fWcHfWISEfO3CE2Qdbg0vO97Lv7lxlnE4m0bwC90vl8ip
s1gr0/aiD3E9oiPh7a4bxdQ2wT6XUqxM8bxyerZ+JExKp+Yp+Pq+WhTgF606
k1EzRcy3jhVYYuqgHDcIgwzGi01wwrbgD/Sy9Qpts0YHTo0bpiWsCnGWgF4l
Bd2UuKSPSXuHTYodA8FFJ4GZCI23Msrup0nMM8BfkanlYh3DekGy5wKilQjb
dc2ApSQVP4NJzbjEwlFJe/qURFu45h9v0o90ch91gC3TDU3rH4LpaXjMmMUM
Njxnpp8w2Vd7CFNSdj0Q7b1NWWff0rVgxi1RklKlJCPvnuSH9luqzwgp4p8P
vJyIEZfkjSEMJmYuLw3azBWJUU3bJKyRMEgHlEEuMxmoyJAvx6pwPoTxWvQ2
Ikll5UJiEA4AWrvuGNQkA5xwqBxglhNim0sUKQzu8CJw0LKtVpX9a+aRdHhz
URvLurzacvY1Z6yEHU2S7UR9ghQnUBQcEdR+HJZloE7osYrtltfXgLsxSMyx
B/PJPa015e81hBlK7nW2NCdbPiuA5JYTgFT0S6fTBRvQEj43swao5knQmCvX
r3FmNYVfwcGoKSeftyv/2xe1nr0PxbYfYhLsAOPP26E493Gqn38xFxZJJjCR
0HXZev3h8mqrJf9Gb97yz+9f/rcPF+9fvsDPl9+f/fCD+2FDn7j8/u2HH174
n/ybRPJfv3zzQl6mT6PaRxtbr8/+ZUvOb+vtu6uLt2/Oftha9iZAbJQryoIu
yTACrI2a2vn8/N3/9//2BkQg/xNRyH6vd0IUUn457h2RWkgXN1Gjaw5Xk/wK
wXQj5sh19jWR3D2K5ymdb8lKYHkD7yJM452NjX/43wGZ/+M0+q/D0bw3+Ef9
ABuufWgwq33IMFv+ZOllAeKKj1ZM46BZ+7wB6fp6z/6l9rvBPfjwv/4OaY1R
u3f8u3/cUNQ647z2VG/Q523YwLKHWemwyMuNce1RNli7uIDgWE9VrILpJKt+
u9UbQKAS3WJ1un0QwSsP3va++mj0B1OM3Uv9p7/Udy/tP/2lfffS4OkvDdxL
B09/6cC9dPj0lw7dS0dPf+nIvXT89JeORXT+8P6NvrMijI8Fr+dvXuGJswWL
qoQrCDVYlO038aKIXrH/YnPj/PLd+zff4bnz4mFe1aO8hSm8K5PFOG+vCRhi
V8LZOUZ4nYzTODpjI190nsNONOWvL5/z1yTTRJdE1pkCEwV6nrKE+OL560t8
/8KUutekAF2Lb/hSbe/i/8NTtYzll1NiAwUrPpwMzb/mGQQxSyMienORiRXu
4uqDjBBmQl4lU/YNLzJTaAmk6iF5cSDbKktQ/BfpNTgPowfRGHwV5qifGTvV
79u9tU9EPTG5zHTksYwM/99hl51uNka/P1g/Sn/lKOy9o6Ho1fpQB4c/e6iD
w9pQB73+zx2KXq0Ntb9+oH195vcvH3kmUlkji37/8vz87PdequFLcsWIee6c
EGN/yaIrkjjYPSO0cakmgtLoc3aLkUBA9HlkP38BkSXeT1pBmhWTERNsKd7S
Gzyi2bajsxd0VzljebsvQbTR5WLIouJrUte9aL/N6Q7NFy7VmvUHsa5DuPqD
mJ73bJjzfLqYZXi/t/z+d/CGElOWnUSxBXqwzfOg08NrfbxGgOc7hdtyLeRn
mOJAGxoIPT/A8y9IkZnGBFJm+Fk63ZvF984nXSamGkwgC3AsFSrROLs5xjnA
OK/S++i2t3d7SNpGZuIguJyX+vDsYQDw/UcBDvEN7zKotfrGAw0xkGWrsBN6
4+l8STYleLgwaFhdtnuHDM/X0EdHaeWStfmpeC5PLeYQqiZpQTNyrmQmqZ63
+3u3BxjjiDcpemfEdVrYGeqnujVA08OHBpErZ1OhCfGL1oEQ5hG9vI/ZXE6v
8K4EZy2hn89Riw9gdRe+kAEBRNUznMDhvp3kooRu+aDLhrQxjMUe5aj0h1IW
eXAQHEX/0aO4epjnmGdwjPd4c5cvz19cvHcYyqVFmp/28Tkj5dt3l/WnGWUu
3jQf5otz8fLyO4fv9OGhYMMt3AG9wzb0W2hGb2Dlss0MTvjKjMcRMa19AEtv
V3TFdkla9r4+ofbzZec6dnjAx/zyfg7Q0wFdeW3XzgpuARhTi8D2Ri+e2JEL
v+XcC14i+9OeldFsBNMlVk9odUYidjamp7e5OASdPN/OB9ILYkOSLYnUUcMm
Cd9bIKL2Hb04cGhdR6fSskWvcH/+oBoXvcDgvYRSh6n0JR60vkWC51GAHL1H
keONuwtb8LRLdOwWwLTlohS34GkvHu44pma7t89Q1ouN0z/1ZIreW8jJqGXH
WyKwh325/W8Yn4qkXej7z9kqTWQB/thoK4Z7J+c4LefF4gINoyqpSkBvn9Hq
HL5rQu7qlJFcj6bI71OEFAkR88dMo40WU4cs+4rFVzXc3j8JQNd9nKe8v6L/
7VWg3KskGQ/hhKJxuiFeSDkdpWkw5ZSs9ak7lgtRQIsT3Z0X17cbkXjEDezH
ix9/hHpCD+779XZPHl3vDxwKolcI4GRW4M5HKimwYMohhExDt3v9/eDI7LyZ
pPwnfNtf8S39CkE0NJfodaUX+L68LApOuDUs5msjWBxgPR7ni3kxg3FKAvDY
zjZiX5baycR56M1UgF//OADL8aNgwa2vlET29u0TsQlGh/3+QbQTI1xkF98f
4a/jGoM/hbYekbIO7s2qLT0yaDyCk5yzWyu8EHSmtz3GHGK89NZh4633LOrY
sKkzwEUDbLEbso2tCUngVXuax4iBL6DA3nKBqQXk7i0+3P0+k19xe7O4+A7o
QHgkOXRYQsBWukePwI1PEXE3bBy6Vnpf3SXxJ0aM7onQfd7AIvOuvq19FkW3
3OkfORSnt44DProlcXEcmSe++62o/Y/RVvABh8gkk3gxpQGLZCpePYCVD6qr
vCcpiOmQXMQEgXBNrk6X6ZgUA9M5y2D3h1/Z/Wts3Bgd6WCV7JsvxBXggEWI
VUdMcgh9StrJbH4Ti1yuUZZBFTAMwCioBNHox7kEgUTQLvEMo5eXDQVe9P1h
B4y4Gx7iwVe2ca7xZw4+tMzwZ3EYasQXa4c/AMrRm3TqzNi8jE60fcIk9QyR
t6S/MUoRN0/uK+/rVkVELPQizG2fMN6/RrSfqtt7FgIw4lCrKDCwaxbHgYTO
02JAAwhwJ3ya5ymEgktOiOJkrris5zvJIh10HtMaAgRGJHyshsXt436L/joW
69v2CZ/XO5T/WvgwZ1gzi6isHqYJh3fitVBGZJs33zwIGUTLFFwDaFw8Ch/l
STfaYe/A9vHhrnEEAJywJkQthA4chT4/OriDzpHCyBk+aMBesKv3xIBN3CEN
raITfZ0TQwLnjXbsAHfFP+G+gX0cWzwX0gLQ941qxrNher2AT4VPXU37YtVB
1BHiM4yfbx+fOAlIzobjGIjBVYJnPK3S+Cp3YTIKn+3jg1Cmn7EWx54rrV4E
bzgcxCwJvH8j9nTvawn9GtvHcohi74ZLDEFGTNn4UZ06MQFNn6fDwMPY6USX
IWraA07WobBEjaPuk3cbqAIWGhKXVlEf0+wkGIGjwPauOTeEZdLbUrzATkjl
sRyWP6aqefF8LDJdg3Nviz6L092Cyfq6kEhCriwUyGRegRJl6wrxmIjccVRX
c1txMARNjcdk0Ui/2D5Sgm0SCZTWuumhJCpzeFIXXFlnDuy0LqZ9WzQ53Blx
qchYNZPu9uFBcCOAJxLqiXw9WtC+Q9FzsVYR8jcAxKpdkFy0fXjsXuL6Sm+W
1b6mPrgt2jzckkEsgRL2mjP14sWbi6vLaKKSJosA+V12jcicyOz3eMGb2SXo
ZQH+q8HRLslnW7R/zNtRRHazt1gqMup1dNx4sGmQODrxD8jce7yceIyMUnHj
bB/zATvWADIywNbEbzlzxMdf8l6Axo+puQFtnY0PPnKoP10utgi64UASbuLe
x1lKhFt0PmeJIH625/geTAd6QyvVQA9DamN8WTMxsrYRY4nesOB2icPBoSNA
T4WsRtwrzxcUId1WZdhUzOetkPtlKrwchFg7XkhcUCLyASMwX+WGz3JblH9P
40UMP0dFA+ZFyPjjQM07dppsiz7Ngo6r69jA/vfOdxlt9w/VhAWr5/LGRIFV
7ZzJFWLIQejEwa2Oai8Rg5DVxPrBvihVCfFxmHyAhypGqk/yRY5ydWZOfOAT
+B4W8O3DXmCICNdGELisOBPEYd0gtCMs5kiBunlAdNS9Cs9OvuaoO2J0LnJp
2wxcyG+JLkWwPQdSeKPBYT9A6sfUc7lRABELgJdzVJKgA0r43LZVESHytvUU
EMQlJ4FsBSof80g92Cay9BgP34ot4t0UumuYs8qIziewLZqIcfiPxOElNBRP
LNjEI3IBZtnuKzu5hl25zw/uq7GNSa5olEw9vXWuVr73ikToKbvx89UcS1RW
knqwfbkSnqayLkfQ0HKf9DQf2PMFqdX8bA069FSkjwmlhJjxANtSQF8hMRvl
3e4fBTdzy8dbbKkgEKcm2piAcCzouC267qu6JAG5zhRcL++R9ncQbYuNAbr4
qRMbBx2STk3ge4UXW4IdMqfKG1v0stwlCdZXIZ/3Xwtf/j65hwcGEsU+L+95
Ac3meZpBl2MfmEXtSqbuXR6BdoBPiz2QT5KFBGUwWIbXYwUD+RfakdghgdE0
9B1ipGunoXEpLtJkwCReXydxWcyVoGoS2FN7mV5Exmcoxm6LJRPz/RAPE47j
i7bW0cetCNIku+pYHi1gL+OcHZYst83UySfPiXP+ed71FmLJLT1Q7PJpeEtv
6JbSyQz4WptmaZapg5BoPG6Yep0U194Ax6qXvKeF0dvEf+aQwNpE6aWUglwQ
0oc6s7FnpaeBxKLldvVSHJrhc9Vz/d7AnjtW0/Lq53Cx5DmpvLvqOZQ15vrP
PKT7bcBnpQ4//x6RAmj7ZqPv1YVNIlGGbHwgLwCVqFub+apIZ0hrGCNUAqei
REFvhCZy+edRBoLo6rBMK5HUuC5EhCiV21hCAhkl4yo+jZ7H47oQyAWLD7rR
f/8p2j8kqG0PwsdVoHn94sBm4KQNUUNQH4PfGxwdEk+Jds4QxfWKxTUbAHSV
K2FIVM5HiEbY+UfYdnd28Xpv/4BuTn83nNeMqSNQcEnhrfDs4eEhvCm98FlM
8fzsRfQWyrYEUvCjMJxtn4RPXmTalyB6FyMO9wY1j5RBePK1z4s6Jop7EL68
uhoaCPo7d8mwFLw86B8TuWouctDp0eA1kqDp6rwmtkrg7ZMD2I6WXq/TEq++
CWk7xquDkyPa81HtzQY13y/Ge1NT0ohymp+DY87nyQjDHBwcdknybS7AMVcL
/wNCchjcjOhGuwxc/KwSmj4mC4N9sVtDxbqFyZIkOOVD8kgQU+S2LbYKdinX
5mGY7R8MML7YguVOHdAMnX7HOSU40VXtfexFZVaxRYCUICmVstWo6cZgvuq2
Qg++T6ZpoMYcsu9UZAr/lkF9jPYRC05pDnKlraqzJCc8Iot3WM+EIbYm98vM
dAsJa+T0Y40WhRkmLvZurQ6IRqW7YZ6zBWSccnhzPZK8Fl7nwisHP//V/Z//
6oF7lV1yRH3WSf/uUrRCpuBeFe3rqS+fDCQ0kE/hlZhcPm8LZ3KhWaE9BmUv
DtUAEWROs6GcDvo3NUsL4yrTtOzPWqvfWyVVFNvc4KdqoXj4GpU3ffDrOJFw
RVj2EJTqEtY6kSQmjMUmbzn7zh4hmRwC+aZuU1ZxgZIQUVcyqTNOrOv1jzRE
VxDtCW9I9O2FLDweluY7S+6hJNKsYRYJKtQGfC2yelqNugqeVuISIfGdEwdF
LkWhEOQ8aKixVuQoK+R6B1FHoCvioN9xRU6Wic6uJInHt77gAWzQXtyUYx8j
IXv4EKQ2sK1IFUk6taDklbxF436f3yWaiKJ1KrTcyii+TWJNaXWlR56VXJaH
7fIWpYKM62m0c/729a4WaHElE+pGZiadpeziOy0AAew1zLCY/BS5fkGxMMTB
s/+3tMoSRMDmiXt4OZJWYPT67F8k6ltPU+JvFWxI24nY3cYxJVjLH7G+lNOM
g+oeSNUqnVYdZiHB1v0QXXOiNaO0FMWg+1KfdCiC7NZNct9GVa5xXN5saUE1
Oz61ZmitAbMDbG5wKwo2KS7m8JOxnfMuKUacEjWdkyyk+cs0ejwmQMzgO7Fs
3NJZe3kZnKFNAKcFJOXezcOcdux2zjGcIhe7/Oo5F2UXogSc+/zZvvtY14w1
J1PiRGGDDC3JViTA15FriI4437lZeBVcPtx0B8LmruRFQCTWuf4v+kN3OZvI
eXMpw99GA4LDWyYLW+0tq3DIf/q/6DeH9s3mhnvmt9H3L//04uI7/Wdzg/66
uJJ1/W/3+902tEV9BJ/J13vR1tkW/n7Of5/z3y/475f896st2Sw2/SavEhfJ
JAgwRDnI8MhRtUSiiARpgCst/tWhTotrd7ARRb+VwHQH45bXIDv7DPCzzLkk
GdySwMoXEJcDCZqNQ3XlASRvhlWG1OKtOZuy5PEuGSUkgcqd7ObG5Lg3Hkzi
pH1EaN3u9cbddnx0eEB6XtwdnfSSw+Hk0J4lrW+7OZiYq3/7zIQt+SZkPs8c
A+VwFG8QWLUySSv2txoB6UJKduxx+V0e321FH7JSqu1Y3Jp7UD/QJ6UaDygv
LO3uIfrFHmim5EuxoQBWPfzp8h/8gP+68lmPP7Bf5C95zj3b7f73zQ33Dn8v
H+tz+jx/bK/xszK4vrN8FB4czaNQwOErOQN5db9/ctztHu0fHJ4cHxwfHvZP
+icHpACeHB0f9HoH3cPeUf8E9r3mTAE8m1MtHQI/tCNIKAmcSjTFfbMbLmhR
ZKfQFE9/Hi7qCS4tiU7Zb10KRMEwLgXAWKS+06LIcvCqJCjW/kYcKM7vhlcl
WxkYktAdJ8R4J4Q7C8hFWjrDLK7yTbwo2c2CuBurF8gBN44Sc7qMz/pGYxer
OfQV++xlbvepkZrTCmqUSVrxItPUaimRShcNayEBwGQO1J64S4l65dJUypWs
EVEgZKOtyNdYESbXghg2tcpmQVnTkvUYV2RL91zWROlQsLScXzPs8QIIkKTh
80igItPkGhUAPn/WUp4gGvVsI83nBtppWnE4ny+9JcObHty954qlnz+zQmg3
f3vbPcAmTVILVKz/yCKfI24m7JvFVAV1CcRTV3LAorl0EEuULSlH4HJyXJgp
eIkgqikQjr+PkzlnP+byWZlUkmStE4TP19YlpbKAHC0kjEnZKHY2+2IRLFnB
zgFJjtOH5d3fRHeQUbgwCYeNaTGTCDuVUhkGWtaRtThSHS4qgZWilPN3OAiX
VSl1/FZr++bxjY5rgORL4g6NL1rpVAb2/enTtZWgLktSaN3AqRgktu5hEBiz
PwvIs0Wy/rOqPaK7vyXRmDzZT9HrctiN+J+e/NOXf/bpH8OWn14ERvNf4M9P
mJj+YGL6c0//3PPn9k+vfSQPvlfjTCui2xHBVcvm7NrhaE1AXGPaqguocQJK
lk4XnIPccRP3Ijd/feLj9knrrP08+ik87lpFh0YRzW/csU6Mf7q1ic/bL5o7
9uUbz7WQJ6d9roTB2oWsmLhXm/hl+1V9YiZckwWXYQpE8hqQnYfXAXkW3xuQ
3cTga4LLxtAkjkaj5oWbXfhCFbyTFitNmaipWt3DxdlrSifpMBrtyTUORdQx
dRT8yhfu4Fxm/RSJuNMHK/SYSS41V+yxHFVRm007hHnUlzBrnn1LbvLhgEFz
eFBTWnb4OzEp9ILbviumuCHTOaxE3DBdTisM0azIEQ3epOFnVj4chU9AU2H/
wABCkaYaxRXf5qlkpCsDkiQGrMkxgtC3BUYgvztGcOXNOUbRUkeHl2jaoEHV
SLQRCAyOEQXE5T4OeiGEdkNa13e0jvnEJDQmWbBPqpzWLmUPPO6Rm/kE6qbb
+yn6Zclbg7qt/Ed/+pCxDv0L/Xl04p6bGD/heH0Fp2Y6+7cSvNUT95o7Buxr
VAb1Pp1ZU89br3xCKMcBLe/eXl78Sct/ftvEfsf7uuPMx0cbbq/fqkjBCxg1
YLvVxPPOyol7a854oBNLfCBC04toLhmJ7iOrr/iUNXUen9jv+OAv3LGYnMM9
r5546YwP+YytdNsvgWKPTux3fMTXKb2PXnJoyV+K0tES61x3j4+bWD0iNcmi
I81m/U3TPzqx3/FJc+Ilpv1k8eTRiZtn3Ov+dSd2O+71fu2J19zj3hLl+nUn
9jve/ytNvHTGg7/uxH7HB7/GxE4S7dck0Zos4eSNwHa27C0QoTUwbd5aqL2O
Zdk0zveodmnR43gRmxuSA/bamwfLUORBM4KRBm9roHNoq28YTUlc6t4Pop3u
EKa2Xal0hnfeLA2vS6wPHxTlneSLoPzc43OGsDvd3OjeH2MJMPbttmhBJ/pb
j387k9968t1z/a236w1nZjxs818D/HVsv9qflU+dPOmpsyc99Xz5qXv90+a/
XuOvN/ar/QnseAF20cmb/mwpiarxhMXQYW8be/u8KDhFgtrlzvbs1J/A9uVt
BOY684XZysWwXT3MUUZNMUqSkxAHnZYz86IVifUi4sKbS96X1auQRjZuhrDC
vdbiVrebjlL3vNXE8+167snnbbk7YobKI64Oicj0UZ5NFlJ5latIstLju0dZ
xKt6sNk2jlZnCpEgiUDsUzKr7D7cduhSYjsvu9LUwVYPro1rVa1qnji+Q7oU
zlNj6yq7uWQIwMg7BZxZckmnyjP19LpC2GESSo/ApTVV1Zvlyn2KT7YpAE0S
VFaWao1Sp8EnQqKKd837uL7mQLTz4ep8V+DDWXFS+L3bRolpVxyWDYC3Maph
cg3ubveU/+90uy2Q+LejKodK2Ts47kc7XEcq5qIYmxteZCwSDoxUp/n5DVcK
juFnRkX2WJ3cFsyIqC3ZI9u7Glkyoh+7UvBWZPkmmc5FW97ccOHfGlooBkUp
wMqOaLbD8bBgCqTlmilG9GIuyAD7t+C9RrBb8oFzdgaFWmsGxCxyTQK4Iolm
KrRorQu2RFhoo8th4ALjTo2wVg9s21OjzCIL8xWcoXyRWWlKEJGaW0isUo0/
vRWf9Vd8ts/v9+i7fdJ8DkgXOCLp+ORbPtvc+C/tv/A/FTPW/OHCb8SOvyIw
/MKr4FmRLhHOEuHKRk6c15J01ze/7CqIbPuV+MjyYBXBH0bOXxkWK/4sT/ur
nMhKLt1TExiuxvO0Um4knJoeveXI+d8+68onhj6nKLoiHpy4Qbf3+84Yhiur
tJbDjNj/bUSXqzK/HY2IxSRlpPZCM5bt96IdZSLd9r5QOkMiN7c0ZkLw1s+d
kNZqMw6O3IyD9oHMSPjpJhtYOCQzGSFgcVl3NNeNiF9aZuQk0ZQkwWint7ti
DUsmQjUh+j3jUvA6LOuV6TN7+LSo82oOao+7sIJvAc2BB83hvgPNYftIQRN7
0PQFNDXn0BJoao62EDS97orZa1ZltR3zvO4Gu9l7anxVUFgh4DoDXDXFodvg
0Ynb4HH7RDaIO8lzDI4FaHA2SEu3ZnnjFYMfe1RG8J2N3uu2e4pbr1xzinoo
P1diJhmD2HKcTsGgpBsBfc1fsY8LiZuCHK7HCbea04qKGQ0bSyH0q3MOVZF2
XqU8PEaBZ3j4LB+MuSuvlpNkIbXyykjT1Gi3Vs0dXlhDJnQMEgknqIbNIiZt
QBJvsVQpJM+uchQXNfEs+pEdGKgCnoiUdzF5RMrQEByUqPb9mWpPbG7sJJ3r
TkuDHf1GuB7sHLE8KDc1mfh+eLUuQDBexRnOvmIXxaJILDcvbKPiLZYivfqC
/lYT5gajiMo5lULeInr5zWFBtHY+vmwFwrKfRNy3kllPZ6HQmSPvFHkpMng+
WfU6AY+jEuEbRo23f5FakdonJBn/xnfdgvdY05C8X8Ykqwi+YBCg9r8uuGVE
3X4buFIvSVmh/cMzs1oEjPRwhsko5mLgQa+QYixVgvlMkfkydsXXrYj9bst8
46v2GyyZzk8cNqZAWZOafBiEfMdBvuNYzkhqhZMkrJokwg7S+uHw/I7V2NL8
2diRaA+7+hpJZ8tHaVxTe6xvj8GKEUxPruJ2jatwY+k4hUbI7Uc9f3H1OaF7
BW5xPyLfw2Qn7SR0NrlWvGIqk04SubgTlHyXm4Sw6BSEkEPgQ0RRoFeB4uoS
I6aa72K9M4XuWYMpF0oyi+/T2WLG8cMaTGd5doBP2F9IiSboHidKgZoSUEea
I6XXHocqPxXxPB0zRK64NwnvQY/LZd0N/XJ91edGy7KOBRWWqo07tcU0ELxQ
WinPdfE+b7NaqxoXwOqHC4r+wh3s2AErxooB0OM6q4bLchnIaVHxU30wHiI6
/m8Ib5JvUqZqy5GGUap3ixAVtp6oVsmQrajATWyzRDPQjpSPbDmYw6uRnd5B
Z6DCoZvO1cARDmndrGgVabFqeWKo/PYFRmdZ2EuNi3gFrcQCGVlvD0dXc/Fp
GnKCGhi14n74UbdSg57vzWVyiifITZNJ30wm/abJpO/YBWSEmldS2N7nz+f7
3RN35uf7PfXHWwASmzCaFrTS2oR9YzB6c+H7tvD95sL3ffvKRksOmVjyJbkC
2RYoqXYaGRfxnUTbihygEp0Yt1oSLRjWLfOhNPTZRzYqfbTO0BrPrVYEyZmx
9kmYywpZDx98x1OgKXyqHJqKdMgvtDE4G7lQPSxvHCKfhRUM5WLuyBqk0gUC
XbldJ02Q1dkK95kCLUKYLr9KxHeCwKgh+l56+WnkMh2Zlj9WMK3VEOolmNC6
VUJ2wliZWELpLSC4W2xLyvE3EzWsPRqgITuUcneZM1FJb7VKorNde9ow1kTM
kJ0gscfQgwsAWAEGSUNj27+ad6Wxwa3G2H1FmVPUb+gxfNETn5zGGM3qwmIo
pW6l/BB3GQrM14LOH/VNRZ6w77HWvClR4FZ7zIRn+qwMjkqDIZ1ttok9y9M/
hsetaOtMwmBzHWRLu6WAFDrviKR4BYKjVbSepsnCgj5v9zui6UjXy2B/udyA
dWUDhOVoMtjfl4XOFx75te1BwSpWztm00OGh0Ij3a1joVsDir26t/NutYqWF
bv+bLHR2ks4+ItlygzrhVNcNdzROER4ME8ZaXww6FE3q0g6ed3YlYWzJ2JPx
zlrLXmBn6/4adrZeL9rZ/2Y7m6K2WdmYXK2AV93VtVp2xcyBdNjzop4ZKrky
QCrd/HzSlh3c1yD778ZUp7cmQEREmB/2VwF2NUjUaa/r5LhVhg5jrEdXPoP2
OvE8nE2XMPg5KBzYC0OT3jEsequk1oFJrYOm1Dp4itRaFYvpQzswwtTtLlo6
raPRGI2sCajFTtkIhaZQ2zBv4OaGyVoTTRrxspVPhbXWovIJJJ+muCWRF7+U
vCWjLQtcvGGvWXEg8NL+oYqNbnJtT7qk5opmxZn3ru+lbwYlNnOAXF78GLd0
iI9D0Rf0txGyxc0kj/5u3qyYhXJ5LbYlhFFaay3Iul/qtKBXXG4N/f049YQb
jfvDqzVmW6We/z2JTHZOvz6DDlaxctKmyGR48wuv4hGRyeHmXxMWf8NVOJEp
Hf/2WUiinjWCkb5FiLKzfZIQJdESqmMFrKlm2Vnqi7p0X/9WElOv2412Bt8s
MRlmf01kWgGdBmBWx2o04fFvVMgxRP91pZyfBbHHBJaVdrYDk1gOmhLLwb9J
O9vBU+xsEsn/+TNKfnHFr59va/tfwNT2uG7XNK8J7P4yu5xztPpwyv3+Vyzq
NpTMr1nMjFBpCV8hewD+zVr7pI07L5SrbN5zSy2JUVhtCDz4d2UIvGJDoNbM
cP01faCeJDRLv2tCves4S3+0dHhn75vnKCME55a4WOSop+mwoNESKcmhbvjA
81XQ4AnK6i2yMp4klmMeeiLSypbGYLLm9E70DzKChHaZ245pmFWdpXGz5C7h
0oBacbdkjadcMYLzH5o7SakTEME8aXomdjluj6VFSh0JGRmOrXiIa4yZ3iYh
1un7VrgQy11aUhjLq9PGVjjW5jGk4yp+innrbLWuAPLXrLUng78v1YMLQf+V
rbWr52yoHq5C9S+8ikdUD57yb26t/eutYqW19uCbFA13lH8Tc23A3x+NxvzV
NZBetHPwzRqIYfjf0mjrzu/nAPjfqEpjF+hXU2lQV+1TOp/bk/1HMTic1MuQ
PkEXAzurm9XY0mKLh18fmiFzlj3wx6wSyNAiJYYyp6owEt/xF6pah6ZqHX4x
dcbdn0NJYGHYtYMKN/a9iQA94+Q9HHbhko61ZzdaXY3RoFViMFEkg3OvUGjx
HrKw5V1pSWOOJ54X6YzQaPoQenS5+Mp9ZdEwOrmmkdCglyvCWNPsNp/eugo/
+o56ixcaGXJ7ZFtARSENylEJ2IWwlnMURbRj9c3LpFA4R8PetRALLjom80Xf
Yb5APKDM3nIdZKwfBoefmPJVhp3RoDbJ8ZdVXph0OON6lOj91yQgrI9oCSCR
upezjFSRqpmCXJpkL1AHcJ6bG+6rw5b6LpQxrK6o49dKr+LRlt5Hr0HWyfQO
l3Azk/Pu8uPusm1u9Op335ULam5xXcChL+TPw8jIdJcs+tEoZ1q4BdXhsW7g
+rg+GAHJXBrHuiJelcHOtUdJyDescDFwv4luLOi5UYur6VcICighnWl5aWGs
1jC5iW9TJPRKwTy3tWhtgETwttS3Vi1CZHxI3Zj782eL1mrWlPT5s2iZSSjd
Mk3dNl2vLnh7qBmIMs7fjRDfTD369UTGn5UUFQiz/5EU9UuvouY/sAtQ9x0c
fnuKVE2kXyLY/5EitVIN6HWjncOflyJl4urjGVLLyWr/kSL1bzhF6o9cUjoQ
gUgmnJfa5OAxodCRc9YL9E5sbkBEevvu6uLtm7MfLG+J5aJA2V75qmCSSi2K
Syw9mWGdzcLo7YgVLgutK3X6FZKsyJcBfqLCq4p3KPq+jL56r1nYZ3l8spha
xwXRhbh0qai/Llm8LtYor2+qKEemohwtqyhHYao5Z9qb8qHylRbODCyr2N8d
ohkeNjfc/KpUoZ+Uxp83ShgJgMp8UYwk1S2I0wgauJZ2nHRYGWeI9aJ/pp33
To66kgNHsJtH+jBM8qjjB1VD1RAR/oC6pFI67SlCt4d8/uBrRQOQo1JcR0tK
WOQkdvvwMHRXHa1xV1nzerbt8/5D1Khtc30BumOPJtCyDfO8wnwkNKClm/cP
aOzJKi+KvBB6IC02piE9HwUZJPANielZyQB3dXvEa9mI5lklc3NgEpbrdvHn
PEXeoq4uDstw+GouzkqzGEpMQMuVn5LeJA4zV+tUpmDi3rXYi2B1FV0DbFKC
ar2gnO8lODbOBeqhXmvm6A+XEAlbEAddubkYIzQ0406c6MSpUbtBxclg2o/a
oLkkJPQdVwn1+o1ZUf+USMQUPQ8S2DT0xacP2wOW9zH2Po39PnBMP44W+BZ5
TB4jWWwSbb9x5GYmCN0pR7W01kYHL1JkJpsbFpv+96W8oJ/gx6r8OCt/bVH5
p69Muir4KYyP+ivEi/OUw3Xf/jqw+BuuYqUH4uib1BV/kqEoFzQ+WVg9eM95
P/gWlutZVcxOByEq7qlVTTD+dn4HxIof/azIJw0NMwJdtzExNfxGNqhW7D0U
JPMN3bXlc/k03hNCfA0Z//ejxcgdWu+D+EVBTmgeQF044hNB/s3w/mZfwbEJ
4sfLgvixT56mPbx/dR46DAIbICz+RcosdgoGfkuXOy/alnvJIeDc2MSKo3Gx
BhUOuVReqkq1unZcKTRbiaTABsWdgY2GGWJdrGOGhdjU76eJ5MfPyvAQWQFD
yntNUnDr96EWmsYdl+ViloydOZS3Y72rOEZFUdZM59JcoV56uSYLmwBJwiD3
Y+qhw6y4VtXhEgagu4Vp4d4rrrk9opdxmzSCw3X91UAlV5JQI1Yt5J5gJZ4X
CbXqq65pa4e9f2WooJRlCFpfkIRbLVTGSjNNANDFiIFZin7laCBwKlLUP0TL
6QV3/BRqDHAjSZQq1jUFFmxzUYe9DoL65XdaqyBAkeUKeesWACVNxgraS+1N
Y7rh2AXppVWRqguId4nFpNlNyt6KG1cXPKj9SDvm4oEftM+W4I0FzbToMAjI
FjJTgrC5m4cWhKuCdZhOBdVwCcqx60AfdmPHAO6ILKDq7ymKRoD0Vw7gXzlp
U4bVh/6KAfw64984gP+vt4qVMuzxN8mwdpI/N1w/LlfkEJGCLGEzafW3is1H
Ndlo5/ibJVRD2p8Rm78WFAyHfzfSo6HvrxbD8q1weorU51q3fN62ni1aM9O+
sHIZGuvreitZ4R8fWFBpuTASGeC+15ug0PwxKfKAvdQrAdf/8pWAm/fUrfZV
0BruzG9CLMGKXWqZRr2SfDZbZFJ3icNSfW9R380rGIC7sDqphTfqK1epgBpp
q6m45t6G6csvZ8SG8LkrOoNg/mReRVtZLh22ZDrIWVuI9F2UCCXmFnZBMW5+
kqcquZSZD7dZKZb6lbuyQV6KbkBqQkdVhhJTwV27FVXP5kBM7gLkpG/RPbyD
AT1Tah1TaIiq1jDGXm2W+K6XJd72/W0+b1tjG5OI3FccpPTt2OhyBTY3rAVM
R8pAuWMasji+gBkfWCHnlSJ5QqQ2BzjdBhpu1focedR+pX/aK/6yP8uo7fZY
R233cRO1tV4y6gfTeqYrMVcl+BqGCnqpAR4FvGKHltb0bUsLAElGRVpWW1pC
T7r4KEYnGvz0a6JrY/ePo+vWg5zt0EW4b1kh+3oxbY/D3M/8l0JhmeU5+lK/
095GparRH4f06UfreFQ6xOaqZYtZqPSWq7OdWOdqdHcO24g4Q7hydlrSS/rx
AaC6jpJpKW2Dl9iH9CSUg6wkMXtuPgjvMiukzeEIZg5TokhNKfJ5AR4mhnYJ
Qgs8beLp44rsKB1YJNPkltlwLF272ScFt1bC7XgRcmL1oTkJubZcPg9hZpwB
5SqvkwI0Ttoo6CglyK2Wniui3nDuGL25clbERnPvz9trTYfOFrLsJ6Q7MUql
mY74TbNr0ozvlJJU+ZxwnbDsGj44AuWQwIaeBKgZyX45W+7tkW++VC9TFZ0j
Csw50djlGHhwkDz+gELoYZdsJpjAA0AhLyrOU8JalP5p0KLYOhQXkCLnWgGy
kwr8Ey0S4P/SpoFcXAzjrJaOg173LA41vS3xSJhoqAWH3ijSXmGimEp7P4Ex
Tci2RjW3qWPTJf7VXMI4AkQepJnkB3HZwhjAYznpnDt5LkrO9aniTwn3CU8y
X33TL8YiN53fLslu0yLnOvgYi62ndlm18h+Gp9fGU7mqMVqFOhbla6CK9aSO
nxwVHpADXu8rNqexss6VLkVKcHWRLOJOZ5cYCxRFRJVC17xuvGBhEhtNmb7N
YkAnisd/JkgwFeEsPzqNIJLV6qaWD9mI7p/lVbl+6xzG3vSfgu4LybB+8zd6
uRkowiPE9BftXCaJ+GMJgK3o1eJHVNVrKWgvZ0nMV1l6pu6KeQnowHjVqMLP
grnkQJojLw4aIjXdB3L95NZhPn2nNJ94Iyagg4qbak5q3H+tDK+Gl6DIf6ST
AiOM7bbMMhOWPBTD2WLYVt/sO6MnvKkzbq85ksv0OubQ8Vui6myVdk9y0IVg
g6sPe1rzkCBoGfUw9Tesz7cQKIV0DZMH+kVi1J0JGmqK+oiXWpPwKkq/dL+g
MCtOEki4VOc9c1TwhFW74AtTu82EqJnG87xaFDgAaJetGr4znZ2VyRRBKSL4
wY9EA0wfgD/XJCsspnGhzSsZa/kWTQoORoKFdiqCunJ9v6KceY0LUm5ed16Y
CxxqomOLWzUEUK7vNmhNIfiIwYwRWMBL6LRnkNXHGLJxOV5Mq5r103nMGPAS
KJ+I/RcJoonkyIaAGcVzJrjwq4Hwz3KCn6t56UiR3IFVZ+etzC6Dkt/SQr3S
nX6N30LjKtTP7iPR2WciMfYEi3wqGa8BgRaZuCRJamrxLZ+SZC7BLdYwQ2AQ
xvKIYMVw8QnTzTrLFnXli+xGIamVcticpMGcOa1E31QnmuUKaOhHYAfgcTxh
YXuB6+2Bt9bvVwLDWPK1esVQrl3Sc9AMN2rgXtAkBCJwsAn3DdOhH1h6CQru
szDDFYwl08CvZpyCXUxZwIjhNgSl5ybZ/hkSej+5RGQNCDTOyFdmiLYjIg1o
0AnW7uPm67FrYh1hvYMk3kRI1RVxcQ41WeLkfJVxZ20fLPdMJRulJrmGR2LX
cIm7eMayKtkiRboOPREdHPb3o7MXPl6kFr82OMb469/Goh+I89H5HR+f0Di+
BlGNS4YscqWghUgmLgorho9RtdDS6Ip4l7Uu5dps1iXdYpGNvFvNDRcpTK4Y
HcNUhQ45MheQhI235EawVCEuEesVrYS7FQgGYcgcby4IwBmnbsYwIM+zM1x8
Nl/SePmQI3BrMVGyut/4gfj5/iDagdoKQAhh48d2GTUIa9i5BGsRBEjoDyo5
h7I5Ye0npqwN6S3iekrOocu1m3E/uNl5EA8rYAuVbFXB5MAMMxkpL4xyadaT
yVqwp3pW5uiYb78UEtU6+cSwJWS4B7GD1MiblYlOPQP04K+TFzneJ1GYd/Bu
K87+8aZGUebyVWioWBGhB9GJnlwZSad3q4x2XN7drnzARJ39lGFZBadw2dTs
2pf6yS4McCmpD7MspwwuhVPylCDQSam2SJqysijgZTKguTa3R0sFnVnjho7P
mPktS22u0/E2f5IS9NtcfJFPp22o6HTxub5Iv7t/3O722r0T8VcWi0ziSFec
ZBniZiVPGkIi66toLYcXu6OrycbhYd1ZG7fKze3LfNeXrwLnyjD8leW0nSP8
iHf3sijog+9Bmhx9xQkrVgMutAbR8H07h6EEMSSS/lvlubBDvrSBgzpGn67r
abLyjgRN02BaS6WQhlAX4iEZh1hjdUwkabN68o3OEp6ZhKIyU/W4ItZZRot5
qx7IoOMjMpp7XgctC1Tj1s4FsTAHCVwBngAcTKG8DS+17hE56pHA5qMwW1os
u6oc+RKZz8e/NOrhO1lCw5h94XzZZss74CXDFEpoxSIVaNIcWGkR0CI+E/3m
ephWEd8d1jyHoi4ZBr4oiLO2iWrsMy3rwm4yuuFwEp/UuyhLC02hX6siHSJn
+2N5Qw+MPwLo02R8bZUxYBWvRf7QQZ2rvAwz+Uo5Gi/W3trhlaJcjIBXuc0w
EbUIMeGBrRMm0V2tvMO2g6EFLPjmdiUsSVaQmRjiG7DIKSKj/UNiKHNmk9BW
aYE1bv0OpTLfg9pdYp8a2TQtChp8PWDqNo1D90vpjY5mRlUzmJC0FYKkbMXr
BvTeUC8QG2a5E56bExKC5uWmEu8B10JpkqBgQz1K2fQMSS3ifTMJQIKt61tZ
LiYTFLBBx9P8msDGrUSl2I3Lr2FbIhfBGasSoGFGS8ug3T7HJtQJYi+uioX3
Mq8/MxezRnsFJEeh/ZpRzo+bwPqkjRAbCoQrASPUsM1XfZXdNgpTvY2xaCcC
Owxsl/cm9HMZmcJs1iD5HTA5YmxS6+LmRgDsGjI5dGNxU6UmRhM5grjOyw0q
MHCzjuOMvbGLWe9ELzwtkFYeSwRjc+NJFGNNVHtCH+cPjQwFLTEkTpuvAF8L
rJnvc7iMN8yIuBep85TyfSug6YnkG8Jxc4NlENZyle5ryn7AEdYYl1+l98m4
LTpq9CIZp8IClDIidqP0qQO7zLZZzWkilHEP8ynCHdUoySqmFKcLWgyDMpuc
SOB8UcwtjA800OWHoTjrkrVBbwMGbFyIhlsBKrOY4Eisu5eowbbqr3rzmLqo
6ajl5CXLZQfWBDEGIr3pXpbvRcd1xZlxmxmh8NK4iJu7Sjvl1dVgOUTBLr2R
BYf63jrGpFawrmXuOwTrmxNih3VxZlSVVZirC667LhGD7bXWVTQuBUgGoLHD
CVuNT9CMi1oTI/GbEEjYSbKMf2KZqQri/DitMCWpTsFrWSjAGw3IB1FhlxbB
drwYMfxdVLBnoRfCfZNbIThFUl963Xy8TudZUne0+jItI2gUw45jzyrDeTo1
4cEybewu9eUurT9LQw0u91FxrzZm69wnloR1KS7n2tiquMiY5/lKzdFd98nH
0Zarq1zPJdryEp9dhPCQ1+biusoPK5kW+yCyFUYvdzsFF5+VBmZD5aBFhbBO
Z090YAusHkxOHZEJJGJHI1RVWLGCq5tgq2GpiVUILf5APSroGtcJY78GwliR
P71GQWc5Cd+JLiqViEonwJdhSQpDUVGN1U5dj4H3NeLUmBDY6DX1ce2+FIl7
vjdwk77WRLSYlOSCAAXrtmYppPnYZFnAwjtFQeRqy7RAacCsRGV215XQrcrJ
XHaDHhC2Gtnha1g4X7nhw2pxZhLfspoWTt2y8BMCM/QRuLSjMI8TjkyYeIyG
dMTjKoUnfwAJeA3ioLf3uVP4L8QJClbJVifvYvL5e3zDXzk1WDUpDn5enTkY
+L3rXklVvjkSJKA2PHPg/ghajNUsT7kvcJkYg5HQhF6/RobXR9LV7etpWRfw
osc9yAyxZsJksFm292MU1U5EyXfEOoyO0MvRiLwI3MiPsMgAdIy0gdPHWUlk
10teBUMjrkrl4UzvtSIfPwMGLAb1hvEjQgLBKJ6OpOQqr4wh1pJKBd6IhDsU
5MDWvZ8WLCT02+WZIkodqECkE6TMyt+G39dst4YCssBdOtFzKXjmbyB7oswl
Hp6t8pKw33qamSOnBphIi9kOuieHTi9T630IK6H97PGZTHOR5zk6gq0xaJY+
NvKKbubVDR1pOmqZfUHDhx7drCrpD7IW7gDAhvcxMtZ3qpxd+qDKu6o523xC
NfjDomCzYeUs5mxdU59R1zmMrAVirLWYbONpZmKUlfMTYgDhMODYbBsRw4D6
qTrRS7BSH3QR+I793rTAAa82zWQL7gUchqCl4pzI3BIAskw8DBfLxMsxjbCJ
aVI9KzVJx9vw/G2BNZsT+Pvd/j4RmdP9wenBYafX3x8cHB6Zj8loi19EzYLS
m5UsLEAwReSNdUvtdjAIU/ZYyvatOXpp63mHHZU3YoEY5WO9fvS2Zv+18Iha
BBG/8oRbMEm1+UOuQIp2gFqst/VNpen1CY7ctHbXatw5nEWK5kOECKOQJLqd
NPYq2KVG34CdaRSPR1hjMQK2AJHdgL3joy6hVEhJbuhYEY82I7qocWtR1L0/
Grzk/bDtKs3iQimyJF6i7Dz+IRi/zUTErLS8tIJFocsLLFeK2TUZu0H4lCuZ
DBjUpWbhXDrRLpFdZ+/f9dIwymiXLn3dxDLcCRXN7ERLKeRhnjZW1Xz4VymW
3sxC96qbOmPSwdzd9fepwaal1auqSiYZCLufprNUDbDLpQOkYhkHh4bWKylD
rMMFvNz4DtMk2NhImpuIS52vAcvCdYbYEEJUKxTjcxUE9Kxlo/GU7u84NO6m
NUHEWcyDTM+m4MD6mrS/VW+HpBFaa5aF1JZmY1E6Ea9qUrDU3AxOlPN3lmM+
Pdaf6rUR/2zaFBM+bmkduUp5Etwl1h2rdS30Yy0UxKkSiFLCb02uiAKrpKt7
mYrS4NMZ81DDrBf6UW77oBPpyJBMgupxQemMNgcXqqU20l+sSS7sLlMpe+HN
aRYsiMzEx0wBrkvutxmVLkndXOdj961gJS4+mN5UA1X5nPbqGxqbHGJP8q6c
MWGFwuf0EKcE+YcgpkslTJX0W7WxofGoPz3UjlURMzLjtS62MotwynQyaKu7
Rg8nXM2za+66aga4mnnA6XEiidCpNQJuVtuQ+DtJm0GQCSOJt1A5fRGyEc9t
JMDVDxHbVsZICpSasDkLGOwmAyceE7rGom/4WBEA1MWLKHNZYQhjvTkGD0MZ
JqIjRU5PKJELleNAafX2YXHtr0Wsx5BKQjyIRLgqkZ6s1lANCnGdYzn3XSPg
HcqtN0FxtUgR5lWWiqO++FttAMnh5TAqvE8ClJlPH22U1hIXm9pgVix5LC2/
fAGXR1zboT9yKMwp7BtOV4PDpJy7pWG9hWFfOIy0/17l3hQO9RVSEQRPXTLa
BEgWWHGdaiLBSVwGCtYgQxdnP1nB5gBY6UHQEHJXKqtBpSnFQcimat0J3DiZ
yKaN0IUgesyNyBN/J6NyrD4HyITp+jasN4TFldrfTEyASJHlEQhGopeEljDo
+xLJTwjTDqZSuLqrKreR74LexFAGsTJbgSZMDzXuB5vPnOl82Wppg8DA60p4
qVWrZk1aKua1wiEQhG6yQfApnNEQU3AHjwgVlQDv6kF6Xuu6NzeEYqzhgIa/
723M73AjShcF6IUS9uk+jWGq104TV0SyDmuPlcm1BEpN1jNPthy4nfI9ZUMm
0Tw2wBDwNdGPRNH0miPLGhdXjHilPzkO6qyLWSa8MAS9PVoxo050eSPDJcef
8/uEEZNOG/PsbJ092teEF0LnCxOXjeDk5jRLPFbc+wGbF29S2Dz9EVraqvWO
CYUFOgwDKgY0qtlZiUG10JnzJjF1pnpLlVBBJExggXJzm6cScyBRYcFBmht9
BREK1SCjtYXF4MVDjqtNGi5JUXhD35c63ydFkvyY1KgN1xCMU1/uOBDVUGXh
NlaxV7RbM5vXfMkqXAyLnEibnM/X69J5LKrPGt9onORy3KCYj5JAEqhTs2W/
MTv9NUTRkx+JOmiGRUhYK9vv1a+4uWHCtqpHdpfQJIpjYLXQR6/DZrx4bSaQ
8mIzudwiaQBCpxRIrwcR6IAXkzVjgV7/K4e/5rXxQuWmBtxQAohHo1zEA33b
pGWhB09dwFK4zapFFEl7WT+w+RrCn66mriuwM8M1H6KvTMdGhXm2RWhglpSc
v4OCSDT9xwRhI0o5TI9jUSlxkdJL8R+7a5z03osoUXTnN8no0zoNSqWEEZ6x
oDGFXxjL6hJYFYwclZA1kaP+uJ5HWtpt47Fjwe2MNVizjUp3LVJfQnGW69Kw
19XSY0WzBRVDeBSSaIKoZceIW5qD1hQgo7OQMLn4DCR1eumEhrSrxoF6atp0
dVp0bI6p1u3nxGFmq8QjKNmatRh4xx5BRYnkMGmtSCATwS4XWo449hBlm5wP
U+KodIEtuT5PIc5MalA4NllzHyRbp0713FP121ArZfWdi4K8JDTjVFwXGPmx
5I9cHu6OVeLabUZQ8oNSyikMz4bNSMSgUiLhQJFQBijnMvxE0/O8kmCuIGGv
EM2bDXZiXmqjPG0kwTzRbT4lkOhgtCje+GI+Fu2YsJX9THwh/aQMVH1oV0VG
nER9WaH7n21yoGYuC0ul3norvTC+Q3iYSLdaVgHkIAgDCnzMqlMJknp6wSgj
V9zJqRqM7nMkpBJY6VpgqKXN8hKG2pAI9zgwPHIat9TyDcho3QLVcgagsJ+y
r1mFwN7l7GjLl9KEsoc65J3NkPEdqc8VQ5rjXU2SbIInLoXCwcyr9FVKKdTC
5VyQsKkCV0rCvNzoe801Vj1MRjHuU6qhlmYNkrks2IrpnQ8XnBis62RuFfjy
IoSe2e9tllLuPiiSSVFI3rAoYqKAmsPXcgG/IXh8w3BtNy62jfmCXU7ccITr
aeRCu00D0xRhnCz0Yf10nufTFfxsGJdp6YsVPKm9ubOy+ADskIoJdqdhFI8I
nTkUcrZuJMj6NTKoN21RaYI1R8ppHbwymZE0rmoiI4qMDsz32fnh7Jy+3yyw
fckd8twCPvoFfPnCm1/V/+MugfYBgPmVV/mUTocXXtt06WI3l2rjtoyLc0Sh
1tgQ+iX51KE7xPqGcvD7RJpGFmgpA/oqyBUOlfr+iWLQTEiAVNOv5WgLdd2V
FCKxU+u8eoaBhKW1WcTO71qpMJEONaqWWr19QpIlGYpjTSgDjVBxbmooAtrK
NR1WMEhTfteAT6l8lXgaFE/v4odaTsVdkVaVGEVqdIljf4T7WIZdGsTGaLph
LeVkiauI6kf3mINm1MvrGtyIjhkGCAHEKMBhTorY1cMpIc1A2a8lSiQWDC1G
Q58zEuq5cWWwZ17ozmlFMx7aY7PFT0v4Nm+NOezmhmOxI5AHvYQC55C9Kz/t
NPKNU03dbLZXcqfvObKCVOuPDBu5xTTEw5zbp0okUsXWrTL0OzGXhhQBa+uo
QPNgJubABCHv8eZGiMe1OuRLbRaYwYkUgowU1ObMSkQH4DhH3C1WpRCBhs9u
cAhk8pzl8IRuMpFjvNhkhoOg6D7M0kHE7ZBXaLFYevZ+VlkqsA7NkWLEbrWZ
qfBS6xO5UfX6Q/zi0SX9JdX+YzcEtSpxQmIYcx0KjIDi5+1HY61djctV+rko
ahz6pFHz7EHn2GoIJVgE6xN1R60xUWlhhuqMSqGl5wUwSprc1nQiXyDGdx8Z
OumJr6EW77BsF9r+H13Zg9K5PzU3dZWFdJXJ9QbsoBQRwvEJ8CdujOaKniyH
QIcLt32J3PAbdENjYsciDryp6U2ej3mS2E8TyLgripfwvHd5PcB1BQu2XDpz
4/oM8HyoxYyQFuROTjWo5oEThANMCWO6hDleVEH+BvoaS/+7FvL6brSYTbAT
2YQU5wzD8/miIcyD4S0JhKhRuyIlRqcz3GNtqVa2+I1SS1F5mDt+BVZYwbh5
W5aCSn3WK+38Bzo+5AC0dCGOOFnpEbFeqEruPGO1QlGugE841VfgvWyH0O2W
a0KXm73aDDquATlHVY5D47wFdEgygDcp+/w09Qe4W8PxNm0X9eC7ZOfiq7Ro
gVrAp+u5Fua9kKA4IaKhwXeN4nVhf49MPhfUjaxjha+apBl1K92OIri6lnNw
RLESGaZn6fuNtgkuPOTYGWgbD1qt5Cy6ePnyZXTc7ddazrna1rX2cjKSy9fj
IiU+FobJTjJhyWQpxQMBMUhKIfVBI2A42ZnYv++mXi+zxD61kOszwTM9ieWN
5DonnmsorY2HdKNahUqIm4ajsMwJuzPqpPDUa0o8sREddFd9lu+Ta2D7w0rk
5cp2QkOruPxk+matmpRUG0LYFVFQGRg+dx7U7N3AqbSYNYQzdwFkex24Dmo2
dQ5ztPgCq6+Y+hrM8k1jTrWskYaas2gxzOEqz2D2Ux0mHlXL9odIWBkBXjKh
SRDuRJcirzi2TCu6obPXYGedee96SnroVDJneQ2pRlEHKPEYPliNOyDu+5fn
b1+/fvnmxUupxxCKEDXYLJdvq1hopslFHb4hrU/8H0gMYw6mtuUCoS15zSmp
HNRU3IoPnkdwVTzRi/2568VeF2XQav0jx3h95Fp0HrBfuKSE8CGufzAvkokU
ezN73B3sRFvoeStpnVtS1knceUsOADzHfj1fcnrn9YuDSNvG93ZbUT0VVHIH
hOVLNXBzYIz/DJ5IZ73lG81vAQ0ksRHOPnqTY6hcQa2RBgXRFCQAsXxtMwkp
sK5UK2vCXfkYDZ/IuNTlnp1IpTpFJJjoH5aSD0CwfYE6aAu+fBh7HjFstOM7
B/OHJMtKPK1W0d8N0s/cW8JFzHPGDo3O6kXIjCRJBFQfA2gXVmbqVihv3dSN
eXklTp7x4+4w2DnjhDP6AuPP7qOrq8Pjqeta3hMWV/4Fq4OPgEYNRemknqSL
5Sr4vnpsnKSBk/F6ElPbVWPWQbAS6sEG2N+9cg/Lks8ZC5ygJTyS8+NbuU+6
aQJ25mk22W4AwiGJyOPpg9Uz0rp6DeMr2jTDq8YjEJsI4OG0dKuUzBZMyUSO
RZghiLmeV3W6KywylgNm0D4rg7HrJcgwb6aHIbI8p2MsyoUeS6nGAE1mF23L
KhLZoJ1a2X9RWuA+8yjmchBKby9gmplYY79Vm2jiiIFezQSxyzsA7nONUbXC
1t8TK5jDCnErBCW9iLYtRwTF3k+8msGhzcD7V+fHg5OTL19oOLahMCzVErHz
4s3lLocWVjdFwvhzmzyYZkAIX56akrlzd3fX0ak79NluKwpPaen7zq740aEw
a+eQnX165kif2adnuhIX/UOes9+AHvn8+U8H3S4WK9R8kZY3ydhu54s35W6r
7iUKupivYvCa9mBBM0iX0ZDowqLI6zO5YORiMeUpX77f1VdkEbDxZzBZu/Ng
GPeO9o9p2SQqMRaguhezdJZsUR1j58P7H7B6YKlIShZyHEfcQq0NqiL1jeWk
2nKFX/23F292NRi4cNGS6hnkOo2herJ0THhp56aq5uXp3l7zSx8AygF/M6lj
Q4dweIhDyIfg1LXqHDtv6YLsBrtQZWKcV6RMW0OPYJHTJJZiNoTHO/3OyckJ
AcFrIOb+WXq0I89y1o2E2gXdNZgCKIZaA+w/HR5jzebjoHVGF5mGXEABVqlb
z+UiABk92r54f7Eb7ez9MzJ92heXb9sXVx/aV3svBVgGKBhX2KpPMlQhkd9W
nU8Jnd6WoFcOXbFWhEMMP4wjQoeWIGTw8Z86hP18b1bCM66BCC/Q0n/TFGSW
NCUfI6iaGl8LYmWkaRW4AozQSji1y60kYC2JSJa3YKIc6h6wQs9Z6VbHR28K
HDa4d0LErMIyYtYZnJxI5DhAXHnHmCeEvBraOtbnub4mVi9HPSWwXqXlrJRy
p9mtLE1zyXnxPkLNrzII9ULP+FqjILMNpEXIKyAGSDHNrykZoRwve6IT+lCK
0j2OznytGhHnZYIvDTsYR+aLO/LzZ/cYQQG1FZ1pqcZD7LhE+g9q3bAvRksY
BVviiyO5MhzZ/BTW0fpG4vd1ytLSPk5fYwPiYDFvY83Sxiq5wcTXAmpFF2dv
zkxV9AqgWFPs+XmCWDSW7fPamYHe8wC49KZCiWegeSJEftocEgADE6C8xWf5
QvWVLWvQJBF3aiDjDf0UTPlTHWX+wEr7iq4p/BgRNpNUforqL/pvXJuVn0CU
3PuHw/hoeNzrtk/G8bjd64177ePucNDudkfdwWQ82O+OjumxEB/4Pf5g0Ov3
gYNXNd3PpqFjb07Te8o0ilBPnQa0vjFN/6vTKCbae0+YBjjZmGbw9WkEkZ88
DQn72yE6uf4YIS6KFnCByq3meYzHY6uVBUcQI6ZoM1uXNZnovSLcFhGFaToK
ms7hfHt9azL8iiVWxJCyRsMt35Cd6LkJ0TnOmmzVL4ro0a58V0Ojpv3hSXrt
t1vcXG5UbdFu2kGjnZCGmZPQcVIEVrjU5XFYxzpgVOpx3XoKam+FLResTztn
/HawrEtfXGt5XWUjZPPRjAg2bFpTcDBgt7wtLVfNsai+lXJZ1aJ26Gy3HtsH
L/dNqNME62SrgpAtC5GWOLRahTjpehIE3DFo3iyN15EDQ0CZbeJgy0JYGknp
brsi90DpWh7QmxUhC0dcN5Zx10Z/9AQ7hj+LOTB5yNnUViub53bVwLTByAL+
ixVwamETWxP9swUxwv32OBJp/vSqil7eO6A+4xUTr+iQsfyUA8f+42uRlg+l
mt3SuvzV7HARSV3DGmGKVRwghF1R8YKvykqkoC2sPF4fD26zyjBCd8BWiUSK
C/4hSDgUA2+tPB+2Jh2nWYzhet1SJ2NVnLP2CUjM7NnoU1lz1IafQgBPUFcL
4/mGJqs2hrg12Knl3IJF1WqNuNJiYxcGpwXl1wLL7iPTFbmqw/xWIGCRKgBV
YLnmJqMWHCzO/duBqwx7tPrMLkI/bxjatbMuwkg0+0BKpiflqD6C6E8/+q/w
sMv/yNSUFOoqFvIXW5zrb1bE6rkALeevsmLkCgdfLs4K9a8+2nVYuyZo2TR0
VnUUKqyzzqW5jpygv6cScMGp+mxgTu44LwsCJxceYflx1YGbw4JBBQkcrXms
uFEg2kKrWd5e9BiCmv5x7s74vXf/ft5eecKrQKKUjYPIVNPNzAjokp48JtVV
p82NZkgbZ7hy7rp0gJDCFWHtPjXW4gpYuMKOeE2AWLvcGK9cCMsRGR7iRJ6x
fd+sAAJNLsq5vmm0qhzre+5agGai7AORR8Vi2XvOfsLVMQmuMd3mBhPbJxT8
u5IWT0WyuqGntM2wIj4oQ+aahgrG3pJqz5llCYcCA2rNgAuncteC/9YYnX+g
2S5YYGN781njxEMfSVBZlkgXn9+DrlQc4WweJdnJ1w5HbJJm0FkIoDOiS1Xn
lb5sox/mP5T09ngykUTB4UOIkhCVHUtwEodhV4OoWTErTQdjda+IXTgFb14M
Fwyv73EvauDxMPiUPEhgFxfBiNOC1D9JWKbdJ6nmFd4VOcdmLtCXTMOyF5U2
4c5p78+Qf8yVNCoSK8tPWlouCM7HOIVyfNptcZ1q+TOO6fc0gAe17EtOwlIH
wIT47EIDz1HMPZmzJtFIbRgnsU9IxAI4k0UzEt1aeHwtT4kaU9wYZs3lcIl0
gpCWGSOxFCHtwPFZaQGma98x4+HF/wDmgzrRdoSft9exJev2VIaRFSsMyI3g
emMIPF6ALJsbvnZoR1QnZ6V3xqX6fM7YJWOt2KPUn9UQBPc47gL4py0tkDOd
tadpAOQ6EbRGAVWA4zW+k6xaBNeTWuqNjOgkjlpmSVudydOloB/rbKDhUCCZ
y2vQWm16/rU26d7uaUGezYiAlvtuKVhgKQJp+OD0KFcpLFgHV16XNm6oPFOX
QCzxYY2c6Z5+bDkgMygT+aQi0Rpox0UYIiuUwoUXxaHu1+1Fy9U47K/Kh3ri
8uftRgv7tXKQrxE8Kh7mVX5dxPMbFzc8AsGoh1pZ2pUP5tw5v3z3/s13u4/V
WuHmTrDyoq5fJU8i+biKdraCuppbxPvjTHO4Yu7B4kMKo1rYIt4DoLZ2NTAa
zXHmFtnGMkiMesCp2EtkjUr8mkVjknva6Yrybqu7k7jBJOZWilRILQB4zbiw
xmKOABh5QFuR+VQ0i4edoF5QKxhbG57o8NqwiI9ZPwrLOA7ViLA2WUBEHx+S
VWtaxL2CuE2QVZV2NlekwaJ0vef77NMP0UMcWoRojaQP6xDMtIOvAjTP7vEh
NE+xQp3sH+na5PuzNy/evvaV04WSciXuFzlq0ps7R9j09zC2ALvNvIxjbFrU
Xd669S9rKk5hSw2NmJpYcNvmBqLbLLLN6kn6lCHEOrL+HWjfpaOIqyiI02zC
kDkBnIVYBjXndyzCrtPrDW92tX1w2FDCEmFr11LUSFelc1WJ9CdkKYs3LmzE
Ij0WHj39zQ0NdXJaf4P4fDEdPa1cdUMJ2KR1nXGdhgDR8LXOKtYAA5VJ4Wo2
XNlbhFMdblbVjDULnTNFShPovJ7w4hrNKkppRRKlyyMadI+ji/GT1GQMXGuS
KQPGnfAFs5MkmianDm1qqG2UJDRFc2iQOVMSHftekrZE1PPJN0NOG3BRpKFK
FQbncEeEEckSFk0nXnphtDoVDcNzcbKUKR6oo+IPIA4hrifhAe/qDwatCfAE
URMvW3GyD7wuhorwpFTopnqbcBdRkIA54uLTexWqltKaJOffxZu6WFPPJhvH
QYOwwKXBg1ILYT7lHDqYPZM7IUFH3UE/MISzpbpKlXNqOaNimkrPCc9siVJn
gREPkrGzsy00gW4dkgTpRyyMFcTZh4TakilgKcHN1buUwIBwJEEbmKXnuQJ3
IRTLmG5Qx4JNtIwFgeJbS652Q6/cB72FCnyiCseZz7CsUTaGj3uPow5cgw6O
exVCmbkAdtSkg7fDK/aJeakL0ovYM+m6pMUWEINmp42Ofi21tXPpJxLAuMGZ
eTIUqVtyVaFUW8tZ9p7Wqh26uD8uMmQ3dmhh276xnoQf0jVCuSCLnmxwHCMt
Lv6sTFy9bRmJBAVnn7Qj57MzBblhJBVbeqbtPh215kwr6WKaT5BgxrFz6tO1
GbjVOa8OVkdNp2i5Zh2cMCS2roU05mP9jnNotWVmqNJpVvRwATi2Is1vmoH2
XyOW7xoyyo4dLIJJ+weHFld60OuHluvPn19dvLvsHXfbgy9fEAsE4Qusz8Uy
HMLAUoVRmYhcDXLNHPmvoa1YaLQHM9FimFpN3LjU+iSft7VSiVMfawnO0tiB
PWZcyU4twqusFtZsQcfb3NCUSafcISPoPil3+QmsLZ/HUAOL+E4qO7QCmp1o
qft5XDD6cLYqKRs4TsfYrzhKzLpuutRtYQ9WjZFhZtUD6osRQsK1VAz9xNlz
F9avztDYjlO95BZYfWSMAHYi6SQctS4hAKWvsqi1r10aFSHtdcKjcEJ6UmFR
Qde2jsX1xtO2qJ92VUcWfpeWvrMW12QLNxLd1roeoBBBCRenCagcb6StVgi7
SUqoEKmkbKjjGkZbHNLjlgRpTuAr5w8hf9yno7oypd13rH20gs/iMBuBkU81
YnAz7gK1rjSPYJhet8FWsc+HSndJSGiShv+Qg3JnKYrXXky0+p29WlYP06Te
yk3M8gTJstFRSU3lIby8XvoW/mBWSHP56QtjSrPERMuVWkCQFWvCVkHIMF/s
x4KOiyxLoEHFRcpdp0K/SVVPpHD3a/oQUq4OF+0R48UqbwJLW0jutqoiUo+r
KJPggs9AE64RXMkIGFxLd+srse6mWaJCkDal/8hVZEUrUqO4fRRJA8ObeF66
GFBX61gUmN2WZNWqomaGQQczRhTX8dUguMg4m9WqKHFtDIEiajHWrICa5wpj
uB6GtGolekdkXkW1wEcn1FcvsN7nFjA9sasqK00tYCBI6Hz++pLffmE0aamx
u1GrVX3dWXQEe6qZsJwsYa/iIyQXhHjBhri0gU3sexjmJed14aDxSv9YO82x
WddU6F5fZOMAM5luLVz51gnoHoNHJvVl9TTVU01/jhzXk0tjkyldqwWbUuNb
vZfL9/dV4cSmNFOiSy3VVyWguTA4SI1rXypGCTCs4kk7n0wkxRoySZCCGbuK
UP8QXSp049JmcEULGevEdcW1ReKHoH74JC6NIWlGsyvKVBuUD8sNKSUleEg4
aWVIuZaSsU3Ev5zGliqp2RguUc8HZ+q1ce5vVkaLBPlG3M/P6hhoLWA0DAWp
0qugBYadHOCWzkgtHmlt/pCBepBQVLM1mxAXm/vRi40QZirWDmqMqOnpX45b
ZxmsrIXfQTFKJhVLEdJeJvxWr0pLKzuGWQKIA09nOMxPyQPfqqLIr7nUKj6Q
OIwE3TiQs+OvGkJHSVTitywMmJFvnk8f6OzAFKUuMBD9Jp2XSsTdqPRDW9TN
eUzaOt7958u3b2D/W8w0Q9A/46Zu0jGRuaX+1RR3beTvGs6TgGk9oO3zttOn
jQPvMA+BjVi80VNY5N1jcs927UwD2xwfXOh57NTUHoylXc+CVN7wZBoeCjUS
cqF1afPLbh2SEVHRSlLbREQt+JDdTtlKHYusEC80oNdqtMnul6KBdz5/RtrZ
7f6XL3v64wGHB5Q1nGAxBhyAQW8h0lztz6dkhxRO1yKytJlWuLy/2G7FYhy0
gAnbDoSlSPzdJB4zlZpYC/BrbfUl6arODxnMQSt9l6P5ZoQa/QR+wheCbeI5
ph2CXiu1bgqTo1+I7xE9UHLLsTThdUpI21LPjrgdeb2aBGE5xNJ2Aqz9N1ru
Ig82YXtg7ZodDSMu0WNFwZMH30qPgWElaLxJRuumqMHBL7AVxPlwjt6Wxjys
SptrsbycZtzjWrRZWb4/Tm6YvmCZmXCboeHd2CLUOTxQpz+DAgXccsmDCGNG
LOfjzpdyE6rtDUmu/r40a+XKSRzXJ3G3EMsMTgg89wNxnQBwZElEjMfxvJKO
NfBeipE+2gmwGy4FIV2+HSab9EHrdxXmJsp6CceJYc3NcRFFepQvTiizurT/
eqijp7fyiu/WsRyfryE2TbtbwwS8LXEqSxIWh2nBQjz1eVGaL+JCxwz+Yag1
snJ9XJyLfWZNpD5QLS6tg8ZH66axh56RvKQG/UGn1+kHE1l1NUvjWpqA3v38
WXimj7iQlX94/yYI66mFjH/+TF+6OJtS6y0J/zWQhitdvyDNK6tvGSWoMxaq
eSH6Nk0++iSTXC6G8LQLblxqOOM5rtlWPQqXA8bLLY7lEwHAFke6Rdx3vh/8
tq8A4FQgCDWLWCvv8/3RnptL0cA7pUspNKnbEsarB8d02HAU3SXTadskk9S6
YBkYGmlrYsBqii7PnKppVSH+8JfF8wWGi0UWq/t5aAeeiL+mHj3tk479wc4X
w6kkKEjvZ03UQDRvLXaRVJAM+UYp4ifoG4uQ1goOH97/sCvyVZJIKibL5LR4
NcZfrTqDUrieZrix4H0rmbZJ9qBQDtBXT9RKWFpyf6IpLmOrK06AAAJ2ohdJ
lqLlu27X8rVQMOIeYSwupItrKCn8ef/l4vpaiK9oUrl52mbW1UYXA+IKoX6y
mJrCJ7cwwHdXL4EX/r52I7cFoc3BVz8vxjhBt61wwC1fuGAiBv4ZMA/Fjizu
WchrcABIisFcdgfr11tYZju1ui5sqtAp+Ii3avH+X00DWZHs4ZM+aGU/Odj8
RJedLQb++2bWR/gyJviOlpbjnejK85NwgqhHfxmn/Sl6e/kqenH+MtqLLl5e
vXo8kUEyTOhhcyuv3EHU/9oE5/vdE7F+/P/VXVlvG8kRfheg/zCgH2wnHHlO
cihgHySS2jg+1rCcXeRJGIlDiTCv5ZCyvcbmt6euvmaGNHVshDBeIaJ6erqr
q6ur6/iqH4ehTqKQGSD4wPu8Yez6BfHDZiBF9ravgZc87AWEm7B9DvCC9IEz
KJTBt3G54QWd3S+oJahUuOhf88nXZgZSM+g+7AV9thvuWIPsIS/AZBt7Q6tk
m5r4kYybTya3RtJudDFUCRFsnSt54Z2QXqLSbNp3SLL5caLMbDLnum5kK+GC
TK3Xg5ZVJVTcryQgWkKhlg121HKJ1fLE7IincwAtVmT4DFOu06Gictuqi+/f
iRAhZyCK5wRFWetjIbq8lfJAcnjCBMGkis18Q6gf5IiaIdahrUDb6uM3wXrT
8TOiROikj5aW6HzxJwMinL0+2W7IiqMKOTZlzNPpfaVQMqF/QyzKIRrns8n0
G4+UgWhF7WbGYOroVori2DFWUpS7VetkiSZN733/3NBZECBOF4J0tCdszUt+
5bvJ1WpRLsZr3R+yJF1ieBBcCFxnxOr8W6GFzrXYzHlalAzpBgTuymv1zicw
5XyFYSImvv+Hi28PVofEkRvJjFrSHdaUGs89oLlRn3cqyQz4QVhHav9M82Vb
3G50EycwtLHXClv0PsJRII+G8jU7S1EalpLzdA+WUqXSPhcGgmKMlfREuVS4
fcrCdWQlujHoAs6kuhfbDsfAb3q1W6oDpLYavqoLQRWaVOzP3kuhDK5mOXKN
jVFfhZqGVsk23a2mxfuqaXave+hq2zIfPqmUMpXgq5jZ1orbsjpcVsNEl4y3
pEDWI9iszG2JUjPKT+0iraPtdqSeYPaPFLQkfjYIRTdYI4XCZNkO7gQb06bW
6UOilZKToFTDucqXHHOF9/IXtlXqC4UyzNAsgi4w6J7C+jG6FB0NpKNjIOVg
UlKJGoIBkBBNne80N9i6LrgVbgSENdVFQb3bzXSuM6WaI+PUTGxSCOhnXn5j
wKo1SoE5h+cxRyKgCRpyDg/KKaZfUhDNSN+ANcwUDp3tfvaNfKEg9g4P2EeN
MVcbuLyVCqpPF8OykoKU95rqHLDPW5tgtU8OtQRyC3zzruHudCUGvwnf/N0I
niVnrtww5IFePgz8L1Xk9XI1uc2veLM1JOqpYHoB7EXrG9uSJFKUHCqWv0mV
V5KkWr1wVC65Ch5KISBibjYxyE5INcPlVSDfjjxGr67F/7E5ohK12QxnrSMa
FLiswi60cBxxsYiGucS4zBBbLV+v0ZQCo0Y0apKlNuhvQwlGtKCbF6iqBITN
Q5KBgUl1oICGE7TRIDnVjYodYKAAWpvL5WI+Uj4FvPZjpFhhp2qi/XPNmGuX
Ck2FY4LWsFJjVa/OyaxCiy1s46kk9hmpYeNwwhqpMC6K2VGspWOJm9OCdF7C
hCGhy5t8WVAeAJ+KNzLR2wSvbOQNSGD9DH+JBZPvuMwEoA13wjSUZcYr3Tax
ydxB7XuJtOcLlJFszhMihk+udFQ9222+P6t+pWtF5Jv1DTrjrtFnw3GluWmr
st44an8iRRU+on/hPJ/+0YYNDP8/L6beO7TvYGL84cEpEKUPnAVn81R+/ZjP
ygIjEs6A9xfe28ksh19+Xsz/yOG8h65gX0xWC+yPstGBRxezEk4p+GKzWsFB
fX7kvdmApFnlX7Cfj1xlGzP7Jtjq4+LS+20yXdMj5wX84W2xmMOx0aZpLka4
m/4NvF8+X3BzONa8N5OCArTwkdU1HCMfVovPQI5i/hlbvZ0syjccIlySMY+Y
bTo1OYvK9IsXL2MFJK1y7v08Wf9jc4mCEtjTUBEFhqq6A6fKppTcQStVzLJS
O3ZS92Y3Alpg7eD8dmJAFpVSVXeAqnj2T9A7ksEERauSYxxjgqe9lfUn/Zr4
GAre0mDFHOXLEEHQejnNryegY/1hRCpeYshH+EVKDqH4KTe4yeDLF0hPytWy
4MMUqgldEKgG+BL5nMUmLIwoooyI8lsh6AvlQnOxhiaCv+CvK8EQEqxVfw16
FBeYQ3bOp2PggCNvOL8upiXwM/Ct98/FDTBRvpqBHLph2+GHHLoCzlwtMU4G
eGUMwhwoq1odHnzJBR6VfEMblUuBwcfFLZchICIYkeO9Pv/l1ethX1zkvu97
aEDmjfwJLYW/cmQwbGInUBhb0DWqBrfvYTtP2jnQyYSB0AkoVEIfAMde8DUc
9ntJmPSjODo5DYLDgxdhnHWSLA3SJAr489L7BIfXKIe7z1lxudqgMyiK2lhg
PPKi4wj/HXFT78M77+d3n/wgPcbOtg60NjaNMMGQ7xdl8bt4wDFa9Aihgwze
nXFeVaquusVQzpwipzpcvn23eHhyGDnlAqjCuhXa757hCNWEIS88N4WxwU8G
X3vDzulg2B8OsqTD8B6M8Y/9w1/PzF+1Rs9pDVQ9XSM7EdwT9yybrcOFTMlI
5ZZw88IgADFjrGIV2H/YVaJCMvywiDYtbfB9RmO0ksMOD/4DH/IZI89aL1jw
OH4Zj4F0x8TQGD6pEdRhRD6hjoN2cYsGdxXAT3EpUvioWC6u0CSTRX4Y+GHq
BcEx/cMWKuqX3iMte93AD0L457TEYV1gs4sFDcf7CQgdhJdROBpFwOxhgnwL
cwyjKOxFvSgL1If3Ir1CyPveFBHVGtmxbvT+/HiPrVLZI/zsRSe5gBdcAFVw
fGFn0ImjoB8PkkG/L+PrJGmadrt6XzoDfN9Q3hQXwqwKEd200sTXRIIG/P4X
7ohewR9e/r1KR373b4vV5+OGHhoGy900UbmBBA1iyK8/+vJvoSICeRIbRlIT
cUTKWufMy2SIFLOoJYLNWnsfOMcIeZ6tpM+eeUOTNKLTqRjB6vsz0gzDC7mz
/qk2Dcn7fT9YChw9/PShqDvZt3fqQ8PDeF4cwY/gqxH69LfZBF8RduhvSDGK
/NMW5IS+D6UxgbdiCVyPKQxtc9OWvr4MoWctzaFxwt+GbXgk7mdcEEL1nvFr
LQF41/lRlQb6hFF2ZwIj93iKIj5O3w9hXv4pjNR3h1XlFFlyxQYW4+xgkdhl
kdhiETJ4wu2AUz5Ej0MpX0ki+v79Np6NUgSj00i+iHXWgDikxCW52loVZEyE
FOIQbBNNMoO7kNKbUFGzvMcGeUGPgp5ha5Dy6IPoGUv2ZAWqgfJyvkj/eLgo
jwa+S9so6cZ0G9+ijFqJnYkJb6ZHsHzH3l6gbvzcseMUqdDhTjzjsA+sltuz
l47GSZhlYZwXoyAN0yTLu9E4yeG4uRoHvcLiosnop+e0kM8dhoo100Dvzx8u
Oe4tOGBkst1lk9pzc2QEi4iYHxFxwhICKOBICCMgsClLpQ5/GQQoH2rkutOQ
jSy4tyhQk/Rxln4ME/AzGJS/cxF5H2xbx5pg4Kdxq98UXzlwIy9vjl0O4gEg
D/lJfQC/SgnfX4G2v8BSYCkt4PKv8vHpxzv88V79qj6yVyuMW3vznlPnjbpt
6jhMHKLa++UOyZi4kjFxJCOIQGmkUjVJiTYpIVbaJhxlUinWFOMjm5IJexZd
F8ifYzTILJ9qHf/woBf2wiA766bRIIxBG0tPT/pnWdIdnMLpkJ1kR55VzHCu
olKRgxjH1YhTigkpb9DxxBIzsSTmY8vMpEFm3nEHPFhmMLUvcnOwEy3HQMtR
2CAzEv3IpZYZQPEtMkOaXhmZQToFXJ/HsDyjS1ye/K77/hFkhpqkj7P0E5iA
34NB+e6o3I2TNMmM5EcyQ8I1gG+d7WtTmTi2RhLzoCNv3JHjo35aH/lfIWzu
RbMmYZPYwuaVI2w8Jt0WeZO68iataGJsd91DF0vLmzx8emUsfXxlzGSYo4x7
hcbLfIX2Q9vrz3TiGYokSv8ftDfewTR6p/+oGHU6aXdU9KJu0sku07QII/gm
z/Ii7+RRNCqKuIjTKnMSG7ismWquo9c8gjJ3f8mMo3PVOXuiTVe+VB5yFDog
yLYrHzV2VToSzxX6PcH1Ts3Ux6n6KczB78GofHdYleVsks/pj+Qzb4aaVucO
ALnKT6sD8A1j/RXydj8aDNQWr3fwo4+/dWM0Se10h9Qm0mlZo/xf1xTOvl19
7LjivPOItpcHGl941ynrizJLOdYXZX5BO4S7F2Uzdty+ZDeSEcfejc0WmN0m
mMe1wdx/lyrC+EgEv4PmmH2NMJ3t+3ILt3Rdbuk63ELqvbpnSHPLxaK8GOSH
xoh/iZgzJmljaWfn+gzrozVZaenKYDwPjDHDNnZUdkGRVrXeQUHGcx8faPZ6
SJ6q8fKX+7lvHLO0SeqViBo0mXfPomgYdXundXM0U/ipdtcGrcfr8mJWaia2
R9u4kbqassKt9G2/H2/dSEJ9+jgHW9ZPBv0A/9eNe9nZU+wZNV0f5+t3YRp+
D4blu+Nq3DPdHYZL77XSFhFmS9qhQxK4T+2UUvRkTmNnDFYBYkHPN4JmTexe
1GMKRByj9ijpDBMm8D+MK1R1JwT6WCIsMgmFEIAFWI9XFA+Gtb0pkMqFluQw
bYqvPNK4NPxuhpMlPyLnnpDvaSWVbMUnuZpcLyixcc0FRNpchIjjNtkxrNJ+
4C2LJfuwBT/SVA6sOvT5tZTDfg1zPXLDMay8aJ1Fjd8b1Odv6BlXoblAHAOz
AxS+UXXMFWYJIwnpXKSmFLgmuZiJXHxhMvBeKiGZVS0yjojM9hCRtrOyWVKG
6LLUIrKNeJrzK5VRpv2326oPtEmWULRFRbKyD5yCWZiLRLTKL5cCmFQWaw29
pm5E9JzlqCwZq1g0Eh2JqpprX3GmhbK6T1FPKMXRHanxiyjIVXprqwFdEUj/
Tml/Z0lfc9Q3SPsoyXrD3skgGg6j4Tb/o/cCl8kv18VSitQ8jbVJr6S+0lij
b7A2ZfoRY20aBtusTWolKhZq0FLiaJCedXphFvaD/721SU3Sx1n6GUwAfvR7
vjuqRpmfGZlv8lmaZP0OPVtLCJPUW5cQF/hHRriRaAnJm6/n13N5aFN0HqNz
GY+zoRqrqrBQARhW4ZAwOLIx6PoDDurkvPiCta3rvd4DlqtNLWJp+mZYbwib
D5vhQUX4zuZ1pmC7PoPU098Kjvs60WOxav8pKmox/GeDNSqDazg8x+C6efMZ
LM9QaBYVdZhoPCgOXFIVHEygp0KHdFcP6C2ooRUMfymGY85UznawjiOLJTTW
noG2kkx2RQQEzMAsQhwG3QdN2PvdDWUZ3+wVnZ7AXEbrahvMMstgxiU8ESOL
ypyvOdFJEIgbmJe4aSk5DVxFjo45BzCuhLO4XSkYoCP7iYE5Okqq0BGanNpr
ArXD6Cn56rpYHdlqf92wx5ryPa179HlEE58SnkL348OD9CpMOpdhEl+lUZKP
R704y+NuOgpG43B8Oe6MizDKO51LOPbG3WjcCdOsm0KjbpGG4/iqZpWWHfd8
i6SFF+Nfn9CRWzsmbQrseUwCne52TFaI+gSOXJmkj7P0M5iAjyvtu6OqLKUt
GrYtqFWsXG3m7Uco939SHU7SOBz/x6x3uq8ZsL8vBQb7mfr2GFuFlk1mv+xO
Zj8krWP4GxKCHMFUWkJzVyYpJru9xTyDE6eCJGVLqVdQQkHdFWyOJZCGFKOK
yImSk0l9njp9Nh0Jdq/LRTlZW5HfqjTFQiy862Juuu67w5VEOPIiETKXvPAV
bkkTFtvY1cDpSlO4TVGf+IQ6LjWYKBwt1/RGRSHLCwb9/hepcOh1yK0BAA== [rfced] Terminology: Please review the following terminology
     questions/comments and let us know how you'd like to proceed.

a) Please review the following similar terms and let us know if/how
any of them can be made consistent throughout.

bit-length counter
a counter bit-length (other uses of bit length as a noun are not hyphenated)
fixed bit-length counter
fixed-length counter method
fixed-length dedicated counters

b) We have updated to use "dot notation" (no hyphen) to match use in
past RFCs.  Please let us know any objections.

c) For the following terms, may we update to use the form on the right
to make these terms appear consistent throughout the text?

   namespace ID value > Namespace ID value
   namespace IDs > Namespace IDs
   node ID and node identifier > Node ID

d) For instances of "Name "www.example.com"", is it intentional to
capitalize "Name"?  We ask because this is the only instance where
"Name" is capitalized.

e) Please review the use of the following terms with regard to
capitalization:

Gregorian epoch
Epoch time-based
Unix Epoch timestamp vs. Unix epoch timestamp
custom timestamp epoch
Gregorian epoch

Please consider epoch vs. Epoch and let us know if/how you'd like to
update for consistency.  Please note that the pseudocode may be
impacted by this choice.

f) Please let us know if the slashes in the following terms can be
updated to "and", "or", or "and/or" for clarity.

   application/language
   format/components
   formatting/encoding
   sub-typing/versioning mechanisms
   unicast/multicast

-->

<!-- [rfced] Sourcecode / Artwork

a) We see type="code" was used for the sourcecode element in Appendix
A.  We have updated to use "pseudocode".  If this is incorrect, please
let us know.

See https://www.rfc-editor.org/materials/sourcecode-types.txt for the
list of available types if necessary.  If the current list does not
contain an applicable type, feel free to suggest additions for
consideration. (Note that it is also acceptable to leave the "type"
attribute not set.)

b) In addition, please review each artwork element. Specifically,
should any artwork element be tagged as sourcecode or another element?
-->

<!--[rfced] Please review the following expansions we have added for
     abbreviations used throughout the document.  Please let us know
     if you would like to add any of these abbreviations to the
     abbreviations list in Section 3.2.

NCS - Network Control Signaling
-->

<!--[rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.

In addition, please consider whether "tradition" should be updated for
clarity.  While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.

Current:
   Low Impact:
      A UUID collision generated a duplicate log entry, which results in
      incorrect statistics derived from the data.  Implementations that
      are not negatively affected by collisions may continue with the
      entropy and uniqueness provided by the traditional UUID format.
-->

</rfc>