diff --git a/draft-peabody-dispatch-new-uuid-format-03.html b/draft-peabody-dispatch-new-uuid-format-03.html
index f5745f8..2718f9b 100644
--- a/draft-peabody-dispatch-new-uuid-format-03.html
+++ b/draft-peabody-dispatch-new-uuid-format-03.html
@@ -9,40 +9,38 @@
 <meta content="Kyzer R. Davis" name="author">
 <meta content="
        
-            This document presents new time-based UUID formats which are suited for use as a database key.
+ This document presents three new Universally Unique Identifier (UUID) formats.
        
        
-            A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
+ A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
  This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. 
  In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces.
  None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way.
  This document is a proposal to update   with three new UUID versions that address these concerns, each with different trade-offs.
        
     " name="description">
-<meta content="xml2rfc 3.12.0" name="generator">
+<meta content="xml2rfc 3.12.2" name="generator">
 <meta content="uuid" name="keyword">
 <meta content="draft-peabody-dispatch-new-uuid-format-02" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.12.0
-    Python 3.8.10
+  xml2rfc 3.12.2
+    Python 3.6.9
     appdirs 1.4.4
-    ConfigArgParse 1.5.3
-    google-i18n-address 2.5.0
+    ConfigArgParse 1.2.3
+    google-i18n-address 2.4.0
     html5lib 1.1
     intervaltree 3.1.0
-    Jinja2 3.0.3
+    Jinja2 2.11.2
     kitchen 1.2.6
-    lxml 4.7.1
-    pycairo 1.19.1
-    pycountry 22.1.10
-    pyflakes 2.4.0
-    PyYAML 6.0
-    requests 2.27.1
-    setuptools 45.2.0
-    six 1.14.0
-    WeasyPrint 52.5
+    lxml 4.5.2
+    pycountry 20.7.3
+    pyflakes 2.2.0
+    PyYAML 5.3.1
+    requests 2.24.0
+    setuptools 40.6.2
+    six 1.15.0
 -->
-<link href="/usr/src/app/tmp/e885ece9-f182-413b-bf55-2e17ee8ae5f6/draft-peabody-dispatch-new-uuid-format-02.xml" rel="alternate" type="application/rfc+xml">
+<link href="/tmp/YNEckxmTUO.dir/draft-peabody-dispatch-new-uuid-format-03.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
 <style type="text/css">/*
 
@@ -1201,7 +1199,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Peabody &amp; Davis</td>
-<td class="center">Expires 5 August 2022</td>
+<td class="center">Expires 1 September 2022</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1217,12 +1215,12 @@
 <a href="https://www.rfc-editor.org/rfc/rfc4122" class="eref">4122</a> (if approved)</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2022-02-01" class="published">1 February 2022</time>
+<time datetime="2022-02-28" class="published">28 February 2022</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2022-08-05">5 August 2022</time></dd>
+<dd class="expires"><time datetime="2022-09-01">1 September 2022</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1238,9 +1236,9 @@ <h1 id="title">New UUID Formats</h1>
 <section id="section-abstract">
       <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
 <p id="section-abstract-1">
-            This document presents new time-based UUID formats which are suited for use as a database key.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
+ This document presents three new Universally Unique Identifier (UUID) formats.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
 <p id="section-abstract-2">
-            A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
+ A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
  This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. 
  In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces.
  None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way.
@@ -1265,7 +1263,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 5 August 2022.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 1 September 2022.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1298,13 +1296,21 @@ <h2 id="name-copyright-notice">
             <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-background" class="xref">Background</a></p>
+            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
+                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
+                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a></p>
+</li>
+            </ul>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
             <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-summary-of-changes" class="xref">Summary of Changes</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
-                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-changelog" class="xref">changelog</a></p>
+                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-changelog" class="xref">changelog</a></p>
 </li>
             </ul>
 </li>
@@ -1312,311 +1318,378 @@ <h2 id="name-copyright-notice">
             <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-format" class="xref">Format</a></p>
 <ul class="compact toc ulBare ulEmpty">
 <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
-                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-versions" class="xref">Versions</a></p>
+                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-variant-and-version-fields" class="xref">Variant and Version Fields</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
-                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-variant" class="xref">Variant</a></p>
+                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-uuid-version-6" class="xref">UUID Version 6</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
-                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-uuidv6-layout-and-bit-order" class="xref">UUIDv6 Layout and Bit Order</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.1">
-                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-uuidv6-basic-creation-algor" class="xref">UUIDv6 Basic Creation Algorithm</a></p>
-</li>
-                </ul>
+                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-uuid-version-7" class="xref">UUID Version 7</a></p>
 </li>
               <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
-                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-uuidv7-layout-and-bit-order" class="xref">UUIDv7 Layout and Bit Order</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.1">
-                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-uuidv7-timestamp-usage" class="xref">UUIDv7 Timestamp Usage</a></p>
+                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-uuid-version-8" class="xref">UUID Version 8</a></p>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.2">
-                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="xref">4.4.2</a>.  <a href="#name-uuidv7-clock-sequence-usage" class="xref">UUIDv7 Clock Sequence Usage</a></p>
+            </ul>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.3">
-                    <p id="section-toc.1-1.4.2.4.2.3.1"><a href="#section-4.4.3" class="xref">4.4.3</a>.  <a href="#name-uuidv7-node-usage" class="xref">UUIDv7 Node Usage</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-uuid-best-practices" class="xref">UUID Best Practices</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-timestamp-granularity" class="xref">Timestamp Granularity</a></p>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.4">
-                    <p id="section-toc.1-1.4.2.4.2.4.1"><a href="#section-4.4.4" class="xref">4.4.4</a>.  <a href="#name-uuidv7-encoding-and-decodin" class="xref">UUIDv7 Encoding and Decoding</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-monotonicity-and-counters" class="xref">Monotonicity and Counters</a></p>
 </li>
-                </ul>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
+                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-distributed-uuid-generation" class="xref">Distributed UUID Generation</a></p>
 </li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
-                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-uuidv8-layout-and-bit-order" class="xref">UUIDv8 Layout and Bit Order</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.1">
-                    <p id="section-toc.1-1.4.2.5.2.1.1"><a href="#section-4.5.1" class="xref">4.5.1</a>.  <a href="#name-uuidv8-timestamp-usage" class="xref">UUIDv8 Timestamp Usage</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
+                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-collision-resistance" class="xref">Collision Resistance</a></p>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.2">
-                    <p id="section-toc.1-1.4.2.5.2.2.1"><a href="#section-4.5.2" class="xref">4.5.2</a>.  <a href="#name-uuidv8-clock-sequence-usage" class="xref">UUIDv8 Clock Sequence Usage</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
+                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-global-and-local-uniqueness" class="xref">Global and Local Uniqueness</a></p>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.3">
-                    <p id="section-toc.1-1.4.2.5.2.3.1"><a href="#section-4.5.3" class="xref">4.5.3</a>.  <a href="#name-uuidv8-node-usage" class="xref">UUIDv8 Node Usage</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
+                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-unguessability" class="xref">Unguessability</a></p>
 </li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.4">
-                    <p id="section-toc.1-1.4.2.5.2.4.1"><a href="#section-4.5.4" class="xref">4.5.4</a>.  <a href="#name-uuidv8-basic-creation-algor" class="xref">UUIDv8 Basic Creation Algorithm</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
+                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-sorting" class="xref">Sorting</a></p>
 </li>
-                </ul>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8">
+                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-storing-uuids-opacity" class="xref">Storing UUIDs, Opacity</a></p>
 </li>
             </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-encoding-and-storage" class="xref">Encoding and Storage</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-global-uniqueness" class="xref">Global Uniqueness</a></p>
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-distributed-uuid-generation" class="xref">Distributed UUID Generation</a></p>
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-informative-references" class="xref">Informative References</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
-            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-normative-references" class="xref">Normative References</a></p>
+            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-example-code" class="xref">Example Code</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-creating-a-uuidv6-value" class="xref">Creating a UUIDv6 Value</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
+                <p id="section-toc.1-1.11.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-creating-a-uuidv7-value" class="xref">Creating a UUIDv7 Value</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3">
+                <p id="section-toc.1-1.11.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-creating-a-uuidv7-value-2" class="xref">Creating a UUIDv7 Value</a></p>
+</li>
+            </ul>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
-            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-informative-references" class="xref">Informative References</a></p>
+            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-test-vectors" class="xref">Test Vectors</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
+                <p id="section-toc.1-1.12.2.1.1"><a href="#appendix-B.1" class="xref">B.1</a>.  <a href="#name-example-of-a-uuidv6-value" class="xref">Example of a UUIDv6 Value</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
+                <p id="section-toc.1-1.12.2.2.1"><a href="#appendix-B.2" class="xref">B.2</a>.  <a href="#name-example-of-a-uuidv7-value" class="xref">Example of a UUIDv7 Value</a></p>
+</li>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
+                <p id="section-toc.1-1.12.2.3.1"><a href="#appendix-B.3" class="xref">B.3</a>.  <a href="#name-example-of-a-uuidv8-value" class="xref">Example of a UUIDv8 Value</a></p>
+</li>
+            </ul>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
-            <p id="section-toc.1-1.13.1"><a href="#appendix-A" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
+            <p id="section-toc.1-1.13.1"><a href="#appendix-C" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
 </li>
         </ul>
 </nav>
 </section>
 </div>
+<div id="Background">
 <section id="section-1">
       <h2 id="name-introduction">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
       </h2>
 <p id="section-1-1">
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
-        this document are to be interpreted as described in
-        <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
-</section>
-<div id="Background">
-<section id="section-2">
-      <h2 id="name-background">
-<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-background" class="section-name selfRef">Background</a>
-      </h2>
-<p id="section-2-1">
-            A lot of things have changed in the time since UUIDs were originally created.
-            Modern applications have a need to use (and many have already implemented) UUIDs
-            as database primary keys.<a href="#section-2-1" class="pilcrow">¶</a></p>
-<p id="section-2-2">
-            The motivation for using UUIDs as database keys stems primarily from the fact that applications
-            are increasingly distributed in nature. Simplistic "auto increment" schemes
-            with integers in sequence do not work well in a distributed system since the effort required to
-            synchronize such numbers across a network can easily become a burden.  
-            The fact that UUIDs can be used to create unique and reasonably short values in 
+ 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 primary keys, file names, machine
+ or system names, identifiers for transactions or other objects or processes.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<p id="section-1-2">
+ A specific use case for UUIDs which has gained popularity is as database primary keys.
+ The motivation for this stems primarily from the fact that applications
+ are increasingly distributed in nature. Simplistic "auto increment" schemes
+ with integers in sequence do not work well in a distributed system since the effort required to
+ synchronize such numbers across a network can easily become a burden.  
+ The fact that UUIDs can be used to create unique and reasonably short values in 
  distributed systems without requiring synchronization makes them a good candidate 
- for use as a database key in such environments.<a href="#section-2-2" class="pilcrow">¶</a></p>
-<p id="section-2-3">
-            However some properties of <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> UUIDs are not well suited to this task.
- First, most of the existing UUID versions such as UUIDv4 have poor database index locality.
+ for use as a database key in such environments.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-3">
+ UUID versions 1 through 5 lack certain desirable characteristics in some circumstances:<a href="#section-1-3" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-1-4">
+ <li id="section-1-4.1">
+          <p id="section-1-4.1.1">Non-time-ordered UUID versions such as UUIDv4 have poor database index locality.
  Meaning new values created in succession are not close to each other in the index and thus require 
-            inserts to be performed at random locations. The negative performance effects of which on 
-            common structures used for this (B-tree and its variants) can be dramatic. As such newly inserted 
-            values SHOULD be time-ordered to address this.<a href="#section-2-3" class="pilcrow">¶</a></p>
-<p id="section-2-4">
- While it is true that UUIDv1 does contain an embedded timestamp
- and can be time-ordered; UUIDv1 has other issues. It is possible to sort 
-            Version 1 UUIDs by time but it is a laborious task. The process requires breaking the bytes of the UUID 
- into various pieces, re-ordering the bits, and then determining the order from the reconstructed timestamp. This 
- is not efficient in very large systems. Implementations would be simplified with a sort order where the
- UUID can simply be treated as an opaque sequence of bytes and ordered as such.<a href="#section-2-4" class="pilcrow">¶</a></p>
-<p id="section-2-5">
-            After the embedded timestamp, the remaining 64 bits are in essence used to provide uniqueness both on a global scale and
- within a given timestamp tick. The clock sequence value ensures that when multiple UUIDs are 
- generated for the same timestamp value are given a monotonic sequence value. This explicit sequencing 
- helps further facilitate sorting. The remaining random bits ensure collisions are minimal.<a href="#section-2-5" class="pilcrow">¶</a></p>
-<p id="section-2-6">
- Furthermore, UUIDv1 utilizes a non-standard timestamp epoch derived from the Gregorian Calendar. More 
- specifically, the Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 
- 00:00:00.00, 15 October 1582. Implementations and many languages may find it easier to implement the widely adopted and well known 
- Unix Epoch, a custom epoch, or another timestamp source with various levels of timestamp precision required by the application.<a href="#section-2-6" class="pilcrow">¶</a></p>
-<p id="section-2-7">
-            Lastly, privacy and network security issues arise from using a MAC address in the node field of Version 1 UUIDs.
-            Exposed MAC addresses can be used as an attack surface to locate machines and reveal various other
-            information about such machines (minimally manufacturer, potentially other details). Instead 
- "cryptographically secure" pseudo-random number generators (CSPRNGs) or pseudo-random number generators (PRNG) 
- SHOULD be used within an application context to provide uniqueness and unguessability.<a href="#section-2-7" class="pilcrow">¶</a></p>
-<p id="section-2-8">
- Due to the shortcomings of UUIDv1 and UUIDv4 details so far, 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 lead to numerous implementations 
- over the past 10+ years solving the same problem in slightly different ways.<a href="#section-2-8" class="pilcrow">¶</a></p>
-<p id="section-2-9">
-    While preparing this specification the following 16 different implementations were analyzed for trends in total ID length, bit Layout, lexical formatting/encoding, timestamp type, timestamp format, timestamp accuracy, node format/components, collision handling and multi-timestamp tick generation sequencing.<a href="#section-2-9" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="compact type-1" id="section-2-10">
- <li id="section-2-10.1">
-          <p id="section-2-10.1.1"><span>[<a href="#LexicalUUID" class="xref">LexicalUUID</a>]</span> by Twitter<a href="#section-2-10.1.1" class="pilcrow">¶</a></p>
-</li>
-        <li id="section-2-10.2">
-          <p id="section-2-10.2.1"><span>[<a href="#Snowflake" class="xref">Snowflake</a>]</span> by Twitter<a href="#section-2-10.2.1" class="pilcrow">¶</a></p>
+ inserts to be performed at random locations. The negative performance effects of which on 
+ common structures used for this (B-tree and its variants) can be dramatic.<a href="#section-1-4.1.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.3">
-          <p id="section-2-10.3.1"><span>[<a href="#Flake" class="xref">Flake</a>]</span> by Boundary<a href="#section-2-10.3.1" class="pilcrow">¶</a></p>
+        <li id="section-1-4.2">
+          <p id="section-1-4.2.1">
+ The 100-nanosecond, Gregorian epoch used in UUIDv1 timestamps is uncommon and difficult to represent accurately using a standard number format such as <span>[<a href="#IEEE754" class="xref">IEEE754</a>]</span>.<a href="#section-1-4.2.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.4">
-          <p id="section-2-10.4.1"><span>[<a href="#ShardingID" class="xref">ShardingID</a>]</span> by Instagram<a href="#section-2-10.4.1" class="pilcrow">¶</a></p>
+        <li id="section-1-4.3">
+          <p id="section-1-4.3.1">
+ Introspection/parsing is required to order by time sequence; as opposed to being able to perform a simple byte-by-byte comparison.<a href="#section-1-4.3.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.5">
-          <p id="section-2-10.5.1"><span>[<a href="#KSUID" class="xref">KSUID</a>]</span> by Segment<a href="#section-2-10.5.1" class="pilcrow">¶</a></p>
+        <li id="section-1-4.4">
+          <p id="section-1-4.4.1">
+ Privacy and network security issues arise from using a MAC address in the node field of Version 1 UUIDs.
+ Exposed MAC addresses can be used as an attack surface to locate machines and reveal various other
+ information about such machines (minimally manufacturer, potentially other details). Additionally, with the advent of virtual machines and containers, MAC address uniqueness is no longer guaranteed.<a href="#section-1-4.4.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.6">
-          <p id="section-2-10.6.1"><span>[<a href="#Elasticflake" class="xref">Elasticflake</a>]</span> by P. Pearcy<a href="#section-2-10.6.1" class="pilcrow">¶</a></p>
+        <li id="section-1-4.5">
+          <p id="section-1-4.5.1">
+ Many implementation details are specified in <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> but some of the decisions made involve trade offs that are neither possible to specify for all applications nor necessary to produce interoperable implementations.<a href="#section-1-4.5.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.7">
-          <p id="section-2-10.7.1"><span>[<a href="#FlakeID" class="xref">FlakeID</a>]</span> by T. Pawlak<a href="#section-2-10.7.1" class="pilcrow">¶</a></p>
+        <li id="section-1-4.6">
+          <p id="section-1-4.6.1">
+ The previous specification also does not distinguish between the requirements for generation of a UUID versus an application which simply stores one, which are different.<a href="#section-1-4.6.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.8">
-          <p id="section-2-10.8.1"><span>[<a href="#Sonyflake" class="xref">Sonyflake</a>]</span> by Sony<a href="#section-2-10.8.1" class="pilcrow">¶</a></p>
+      </ol>
+<p id="section-1-5">
+ Due to the aforementioned issue, 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 lead to numerous implementations 
+ over the past 10+ years solving the same problem in slightly different ways.<a href="#section-1-5" class="pilcrow">¶</a></p>
+<p id="section-1-6">
+ While preparing this specification the following 16 different implementations were analyzed for trends in total ID length, bit Layout, lexical formatting/encoding, timestamp type, timestamp format, timestamp accuracy, node format/components, collision handling and multi-timestamp tick generation sequencing.<a href="#section-1-6" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-1-7">
+ <li id="section-1-7.1">
+          <p id="section-1-7.1.1"><span>[<a href="#ULID" class="xref">ULID</a>]</span> by A. Feerasta<a href="#section-1-7.1.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.9">
-          <p id="section-2-10.9.1"><span>[<a href="#orderedUuid" class="xref">orderedUuid</a>]</span> by IT. Cabrera<a href="#section-2-10.9.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.2">
+          <p id="section-1-7.2.1"><span>[<a href="#LexicalUUID" class="xref">LexicalUUID</a>]</span> by Twitter<a href="#section-1-7.2.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.10">
-          <p id="section-2-10.10.1"><span>[<a href="#COMBGUID" class="xref">COMBGUID</a>]</span> by R. Tallent<a href="#section-2-10.10.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.3">
+          <p id="section-1-7.3.1"><span>[<a href="#Snowflake" class="xref">Snowflake</a>]</span> by Twitter<a href="#section-1-7.3.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.11">
-          <p id="section-2-10.11.1"><span>[<a href="#ULID" class="xref">ULID</a>]</span> by A. Feerasta<a href="#section-2-10.11.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.4">
+          <p id="section-1-7.4.1"><span>[<a href="#Flake" class="xref">Flake</a>]</span> by Boundary<a href="#section-1-7.4.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.12">
-          <p id="section-2-10.12.1"><span>[<a href="#SID" class="xref">SID</a>]</span> by A. Chilton<a href="#section-2-10.12.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.5">
+          <p id="section-1-7.5.1"><span>[<a href="#ShardingID" class="xref">ShardingID</a>]</span> by Instagram<a href="#section-1-7.5.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.13">
-          <p id="section-2-10.13.1"><span>[<a href="#pushID" class="xref">pushID</a>]</span> by Google<a href="#section-2-10.13.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.6">
+          <p id="section-1-7.6.1"><span>[<a href="#KSUID" class="xref">KSUID</a>]</span> by Segment<a href="#section-1-7.6.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.14">
-          <p id="section-2-10.14.1"><span>[<a href="#XID" class="xref">XID</a>]</span> by O. Poitrey<a href="#section-2-10.14.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.7">
+          <p id="section-1-7.7.1"><span>[<a href="#Elasticflake" class="xref">Elasticflake</a>]</span> by P. Pearcy<a href="#section-1-7.7.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.15">
-          <p id="section-2-10.15.1"><span>[<a href="#ObjectID" class="xref">ObjectID</a>]</span> by MongoDB<a href="#section-2-10.15.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.8">
+          <p id="section-1-7.8.1"><span>[<a href="#FlakeID" class="xref">FlakeID</a>]</span> by T. Pawlak<a href="#section-1-7.8.1" class="pilcrow">¶</a></p>
 </li>
-        <li id="section-2-10.16">
-          <p id="section-2-10.16.1"><span>[<a href="#CUID" class="xref">CUID</a>]</span> by E. Elliott<a href="#section-2-10.16.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.9">
+          <p id="section-1-7.9.1"><span>[<a href="#Sonyflake" class="xref">Sonyflake</a>]</span> by Sony<a href="#section-1-7.9.1" class="pilcrow">¶</a></p>
 </li>
-      </ol>
-<p id="section-2-11">
- An inspection of these implementations details the following trends that help define this standard:<a href="#section-2-11" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty">
-<li class="compact ulEmpty" id="section-2-12.1">
-          <p id="section-2-12.1.1">- Timestamps MUST be k-sortable. That is, values within or close to the same timestamp are ordered properly by sorting algorithms.<a href="#section-2-12.1.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.10">
+          <p id="section-1-7.10.1"><span>[<a href="#orderedUuid" class="xref">orderedUuid</a>]</span> by IT. Cabrera<a href="#section-1-7.10.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.2">
-          <p id="section-2-12.2.1">- Timestamps SHOULD be big-endian with the most-significant bits of the time embedded as-is without reordering.<a href="#section-2-12.2.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.11">
+          <p id="section-1-7.11.1"><span>[<a href="#COMBGUID" class="xref">COMBGUID</a>]</span> by R. Tallent<a href="#section-1-7.11.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.3">
-          <p id="section-2-12.3.1">- Timestamps SHOULD utilize millisecond precision and Unix Epoch as timestamp source. Although,
-   there is some variation to this among implementations depending on the application requirements.<a href="#section-2-12.3.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.12">
+          <p id="section-1-7.12.1"><span>[<a href="#SID" class="xref">SID</a>]</span> by A. Chilton<a href="#section-1-7.12.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.4">
-          <p id="section-2-12.4.1">- The ID format SHOULD be Lexicographically sortable while in the textual representation.<a href="#section-2-12.4.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.13">
+          <p id="section-1-7.13.1"><span>[<a href="#pushID" class="xref">pushID</a>]</span> by Google<a href="#section-1-7.13.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.5">
-          <p id="section-2-12.5.1">- IDs MUST ensure proper embedded sequencing to facilitate sorting when multiple UUIDs are created during a given timestamp.<a href="#section-2-12.5.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.14">
+          <p id="section-1-7.14.1"><span>[<a href="#XID" class="xref">XID</a>]</span> by O. Poitrey<a href="#section-1-7.14.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.6">
-          <p id="section-2-12.6.1">- IDs MUST NOT require unique network identifiers as part of achieving uniqueness.<a href="#section-2-12.6.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.15">
+          <p id="section-1-7.15.1"><span>[<a href="#ObjectID" class="xref">ObjectID</a>]</span> by MongoDB<a href="#section-1-7.15.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact ulEmpty" id="section-2-12.7">
-          <p id="section-2-12.7.1">- Distributed nodes MUST be able to create collision resistant Unique IDs 
-   without consulting a centralized resource.<a href="#section-2-12.7.1" class="pilcrow">¶</a></p>
+        <li id="section-1-7.16">
+          <p id="section-1-7.16.1"><span>[<a href="#CUID" class="xref">CUID</a>]</span> by E. Elliott<a href="#section-1-7.16.1" class="pilcrow">¶</a></p>
 </li>
-      </ul>
+      </ol>
+<p id="section-1-8">
+ An inspection of these implementations and the issues described above has led to this document which attempts to adapt UUIDs to address these issues.<a href="#section-1-8" class="pilcrow">¶</a></p>
+</section>
+</div>
+<section id="section-2">
+      <h2 id="name-terminology">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
+      </h2>
+<div id="requirements_language">
+<section id="section-2.1">
+        <h3 id="name-requirements-language">
+<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
+        </h3>
+<p id="section-2.1-1">
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as shown here.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="acronyms">
+<section id="section-2.2">
+        <h3 id="name-abbreviations">
+<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
+        </h3>
+<p id="section-2.2-1">The following abbreviations are used in this document:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
+<span class="break"></span><dl class="dlParallel" id="section-2.2-2">
+          <dt id="section-2.2-2.1">UUID</dt>
+          <dd style="margin-left: 7.0em" id="section-2.2-2.2">Universally Unique Identifier <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span><a href="#section-2.2-2.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-2.2-2.3">CSPRNG</dt>
+          <dd style="margin-left: 7.0em" id="section-2.2-2.4">Cryptographically Secure Pseudo-Random Number Generator<a href="#section-2.2-2.4" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-2.2-2.5">MAC</dt>
+          <dd style="margin-left: 7.0em" id="section-2.2-2.6">Media Access Control<a href="#section-2.2-2.6" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-2.2-2.7">MSB</dt>
+          <dd style="margin-left: 7.0em" id="section-2.2-2.8">Most Significant Bit<a href="#section-2.2-2.8" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
 </section>
 </div>
+</section>
 <div id="Changes">
 <section id="section-3">
       <h2 id="name-summary-of-changes">
 <a href="#section-3" class="section-number selfRef">3. </a><a href="#name-summary-of-changes" class="section-name selfRef">Summary of Changes</a>
       </h2>
 <p id="section-3-1">
-        In order to solve these challenges this specification introduces three new version identifiers assigned 
- for time-based UUIDs.<a href="#section-3-1" class="pilcrow">¶</a></p>
-<p id="section-3-2">
- The first, UUIDv6, aims to be the easiest to implement for applications which already
- implement UUIDv1. The UUIDv6 specification keeps the original Gregorian timestamp source but does not reorder the timestamp bits as per the process  
- utilized by UUIDv1. UUIDv6 also requires that pseudo-random data MUST be used in place of the MAC address.
- The rest of the UUIDv1 format remains unchanged in UUIDv6. See <a href="#uuidv6layout" class="xref">Section 4.3</a><a href="#section-3-2" class="pilcrow">¶</a></p>
-<p id="section-3-3">
- Next, UUIDv7 introduces an entirely new time-based UUID bit layout utilizing a variable length timestamp sourced from the 
- widely implemented and well known Unix Epoch timestamp source.
-        The timestamp is broken into a 36 bit integer sections part, and is followed by a field of variable length which
-        represents the sub-second timestamp portion, encoded so that each bit from most to least significant adds more precision. See <a href="#uuidv7layout" class="xref">Section 4.4</a><a href="#section-3-3" class="pilcrow">¶</a></p>
-<p id="section-3-4">
- Finally, UUIDv8 introduces a relaxed time-based UUID format that caters to application implementations
- that cannot utilize UUIDv1, UUIDv6, or UUIDv7. UUIDv8 also future-proofs this specification by allowing 
- time-based UUID formats from timestamp sources that are not yet be defined. The variable size timestamp offers
- lots of flexibility to create an implementation specific RFC compliant time-based UUID while retaining the 
- properties that make UUID great. See <a href="#uuidv8layout" class="xref">Section 4.5</a><a href="#section-3-4" class="pilcrow">¶</a></p>
+ The following UUIDs are hereby introduced:<a href="#section-3-1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-3-2">
+ <li id="section-3-2.1">
+          <p id="section-3-2.1.1">UUID version 6: A re-ordering of UUID version 1 so it is sortable as an opaque sequence of bytes.  Easy to implement given an existing UUIDv1 implementation. See <a href="#uuidv6" class="xref">Section 4.2</a><a href="#section-3-2.1.1" class="pilcrow">¶</a></p>
+</li>
+        <li id="section-3-2.2">
+          <p id="section-3-2.2.1">UUID version 7: An entirely new time-based UUID bit layout sourced from the widely implemented and well known Unix Epoch timestamp source. See <a href="#uuidv7" class="xref">Section 4.3</a><a href="#section-3-2.2.1" class="pilcrow">¶</a></p>
+</li>
+        <li id="section-3-2.3">
+          <p id="section-3-2.3.1">UUID version 8: A free-form UUID format which has no explicit requirements except maintaining backward compatibility. See <a href="#uuidv8" class="xref">Section 4.4</a><a href="#section-3-2.3.1" class="pilcrow">¶</a></p>
+</li>
+      </ol>
 <div id="changelog">
 <section id="section-3.1">
         <h3 id="name-changelog">
 <a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-changelog" class="section-name selfRef">changelog</a>
         </h3>
 <p id="section-3.1-1">RFC EDITOR PLEASE DELETE THIS SECTION.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
-<p id="section-3.1-2">draft-02<a href="#section-3.1-2" class="pilcrow">¶</a></p>
+<p id="section-3.1-2">draft-03<a href="#section-3.1-2" class="pilcrow">¶</a></p>
 <ul class="compact ulEmpty">
 <li class="compact ulEmpty" id="section-3.1-3.1">
-            <p id="section-3.1-3.1.1">- Added Changelog<a href="#section-3.1-3.1.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.1.1">- Reworked the draft body to make the content more concise<a href="#section-3.1-3.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.2">
-            <p id="section-3.1-3.2.1">- Fixed misc. grammatical errors<a href="#section-3.1-3.2.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.2.1">- UUIDv6 section reworked to just the reorder of the timestamp<a href="#section-3.1-3.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.3">
-            <p id="section-3.1-3.3.1">- Fixed section numbering issue<a href="#section-3.1-3.3.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.3.1">- UUIDv7 changed to simplify timestamp mechanism to just millisecond unix timestamp<a href="#section-3.1-3.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.4">
-            <p id="section-3.1-3.4.1">- Fixed some UUIDvX reference issues<a href="#section-3.1-3.4.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.4.1">- UUIDv8 relaxed to be custom in all elements except version and variant<a href="#section-3.1-3.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.5">
-            <p id="section-3.1-3.5.1">- Changed all instances of "motonic" to "monotonic"<a href="#section-3.1-3.5.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.5.1">- Changed UUIDv7 and UUIDv8 to use Variant 111.<a href="#section-3.1-3.5.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.6">
-            <p id="section-3.1-3.6.1">- Changed all instances of "#-bit" to "# bit"<a href="#section-3.1-3.6.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.6.1">- Added C code samples in Appendix.<a href="#section-3.1-3.6.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.7">
-            <p id="section-3.1-3.7.1">- Changed "proceeding" veriage to "after" in section 7<a href="#section-3.1-3.7.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.7.1">- Added test vectors in Appendix.<a href="#section-3.1-3.7.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.8">
-            <p id="section-3.1-3.8.1">- Added details on how to pad 32 bit unix timestamp to 36 bits in UUIDv7<a href="#section-3.1-3.8.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.8.1">- Version and Variant section combined into one section.<a href="#section-3.1-3.8.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.9">
-            <p id="section-3.1-3.9.1">- Added details on how to truncate 64 bit unix timestamp to 36 bits in UUIDv7<a href="#section-3.1-3.9.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.9.1">- Changed from pseudo-random number generators to cryptographically secure pseudo-random number generator (CSPRNG).<a href="#section-3.1-3.9.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.10">
-            <p id="section-3.1-3.10.1">- Added forward reference and bullet to UUIDv8 if truncating 64 bit Unix Epoch is not an option.<a href="#section-3.1-3.10.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.10.1">- Split Encoding and Storage section into more sections: Text Format and Storing UUIDs, Opacity<a href="#section-3.1-3.10.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-3.11">
-            <p id="section-3.1-3.11.1">- Fixed bad reference to non-existent "time_or_node" in section 4.5.4<a href="#section-3.1-3.11.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-3.11.1">- Reworked Global Uniqueness under new section Global and Local Uniqueness<a href="#section-3.1-3.11.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-3.12">
+            <p id="section-3.1-3.12.1">- Combined redundant topics from all UUIDs into sections such as Timestamp granularity, Monotonicity and Counters, Collision Resistance, Sorting, and Unguessability, etc.<a href="#section-3.1-3.12.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-3.13">
+            <p id="section-3.1-3.13.1">- Node verbiage only used in UUIDv6 and v7 and v8 reference random instead<a href="#section-3.1-3.13.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-3.14">
+            <p id="section-3.1-3.14.1">- Clock sequence verbiage changed simply to counter in any section other than UUIDv6<a href="#section-3.1-3.14.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-3.15">
+            <p id="section-3.1-3.15.1">- Added Abbreviations section<a href="#section-3.1-3.15.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-3.16">
+            <p id="section-3.1-3.16.1">- Updated IETF Draft XML Layout<a href="#section-3.1-3.16.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
-<p id="section-3.1-4">draft-01<a href="#section-3.1-4" class="pilcrow">¶</a></p>
+<p id="section-3.1-4">draft-02<a href="#section-3.1-4" class="pilcrow">¶</a></p>
 <ul class="compact ulEmpty">
 <li class="compact ulEmpty" id="section-3.1-5.1">
-            <p id="section-3.1-5.1.1">- Complete rewrite of entire document.<a href="#section-3.1-5.1.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-5.1.1">- Added Changelog<a href="#section-3.1-5.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-5.2">
-            <p id="section-3.1-5.2.1">- The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards.<a href="#section-3.1-5.2.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-5.2.1">- Fixed misc. grammatical errors<a href="#section-3.1-5.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-5.3">
-            <p id="section-3.1-5.3.1">- Removed the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques.<a href="#section-3.1-5.3.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-5.3.1">- Fixed section numbering issue<a href="#section-3.1-5.3.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-5.4">
-            <p id="section-3.1-5.4.1">- Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)<a href="#section-3.1-5.4.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-5.4.1">- Fixed some UUIDvX reference issues<a href="#section-3.1-5.4.1" class="pilcrow">¶</a></p>
 </li>
           <li class="compact ulEmpty" id="section-3.1-5.5">
-            <p id="section-3.1-5.5.1">- Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes)<a href="#section-3.1-5.5.1" class="pilcrow">¶</a></p>
+            <p id="section-3.1-5.5.1">- Changed all instances of "motonic" to "monotonic"<a href="#section-3.1-5.5.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.6">
+            <p id="section-3.1-5.6.1">- Changed all instances of "#-bit" to "# bit"<a href="#section-3.1-5.6.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.7">
+            <p id="section-3.1-5.7.1">- Changed "proceeding" verbiage to "after" in section 7<a href="#section-3.1-5.7.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.8">
+            <p id="section-3.1-5.8.1">- Added details on how to pad 32 bit unix timestamp to 36 bits in UUIDv7<a href="#section-3.1-5.8.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.9">
+            <p id="section-3.1-5.9.1">- Added details on how to truncate 64 bit unix timestamp to 36 bits in UUIDv7<a href="#section-3.1-5.9.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.10">
+            <p id="section-3.1-5.10.1">- Added forward reference and bullet to UUIDv8 if truncating 64 bit Unix Epoch is not an option.<a href="#section-3.1-5.10.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-5.11">
+            <p id="section-3.1-5.11.1">- Fixed bad reference to non-existent "time_or_node" in section 4.5.4<a href="#section-3.1-5.11.1" class="pilcrow">¶</a></p>
+</li>
+        </ul>
+<p id="section-3.1-6">draft-01<a href="#section-3.1-6" class="pilcrow">¶</a></p>
+<ul class="compact ulEmpty">
+<li class="compact ulEmpty" id="section-3.1-7.1">
+            <p id="section-3.1-7.1.1">- Complete rewrite of entire document.<a href="#section-3.1-7.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-7.2">
+            <p id="section-3.1-7.2.1">- The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards.<a href="#section-3.1-7.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-7.3">
+            <p id="section-3.1-7.3.1">- Removed the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques.<a href="#section-3.1-7.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-7.4">
+            <p id="section-3.1-7.4.1">- Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)<a href="#section-3.1-7.4.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact ulEmpty" id="section-3.1-7.5">
+            <p id="section-3.1-7.5.1">- Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes)<a href="#section-3.1-7.5.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>
@@ -1628,21 +1701,76 @@ <h3 id="name-changelog">
       <h2 id="name-format">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-format" class="section-name selfRef">Format</a>
       </h2>
-<p id="section-4-1">
- The UUID length of 16 octets (128 bits) remains unchanged. The textual representation of a UUID consisting of 36
-        hexadecimal and dash characters in the format 8-4-4-4-12 remains unchanged for human readability.
-        In addition the position of both the Version and Variant bits remain unchanged in the layout.<a href="#section-4-1" class="pilcrow">¶</a></p>
-<div id="versions">
+<p id="section-4-1">The UUID format is 16 octets; some bits of the eight octet variant field specified below determine finer structure.<a href="#section-4-1" class="pilcrow">¶</a></p>
+<div id="variant_and_version_fields">
 <section id="section-4.1">
-        <h3 id="name-versions">
-<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-versions" class="section-name selfRef">Versions</a>
+        <h3 id="name-variant-and-version-fields">
+<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-variant-and-version-fields" class="section-name selfRef">Variant and Version Fields</a>
         </h3>
 <p id="section-4.1-1">
- Table 1 defines the 4 bit version found in Bits 48 through 51 within a given UUID.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
-<span id="name-uuid-versions-defined-by-th"></span><table class="center" id="table-1">
+ The variant bits utilized by UUIDs in this specification 
+ remain in the same octet as originally defined by <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.1" class="relref">Section 4.1.1</a></span>.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
+<p id="section-4.1-2">For UUIDv6 the version and variant field placement from <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> are unchanged and a new version (0110b [6]) has been added.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
+<span id="name-uuidv6-version-and-variant-"></span><figure id="figure-1">
+          <div class="alignLeft art-text artwork" id="section-4.1-3.1">
+<pre>
+00000000-0000-6000-8000-000000000000
+00000000-0000-6000-9000-000000000000
+00000000-0000-6000-A000-000000000000
+00000000-0000-6000-B000-000000000000
+xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
+</pre>
+</div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<a href="#name-uuidv6-version-and-variant-" class="selfRef">UUIDv6 Version and Variant Examples</a>
+          </figcaption></figure>
+<span class="break"></span><dl class="dlParallel" id="section-4.1-4">
+          <dt id="section-4.1-4.1">M:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.1-4.2">Version (0110b [6])<a href="#section-4.1-4.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-4.1-4.3">N:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.1-4.4">Variant (1000b [8], 1001b [9], 1010b [A] or 1011b [B]) are all valid values<a href="#section-4.1-4.4" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
+<p id="section-4.1-5">
+ For UUID versions 7 and 8, the variant field has been incremented and the version field has been moved to the same octet as the variant. Since the bits of the variant remain in the same place as described in <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> but utilized the previously reserved value 111, this allows a UUID to simply define octet 8 as var_ver, and the values 0xE7 and 0xE8 indicate UUID versions 7 and 8 respectively.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
+<span id="name-uuidv7-version-and-variant-"></span><figure id="figure-2">
+          <div class="alignLeft art-text artwork" id="section-4.1-6.1">
+<pre>
+00000000-0000-0000-E700-000000000000
+xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+
+00000000-0000-0000-E800-000000000000
+xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+</pre>
+</div>
+<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<a href="#name-uuidv7-version-and-variant-" class="selfRef">UUIDv7 Version and Variant Examples</a>
+          </figcaption></figure>
+<span class="break"></span><dl class="dlParallel" id="section-4.1-7">
+          <dt id="section-4.1-7.1">N:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.1-7.2">Variant (1110b [E])<a href="#section-4.1-7.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-4.1-7.3">M:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.1-7.4">Version (0111b [7] or 1000 [8])<a href="#section-4.1-7.4" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
+<p id="section-4.1-8">
+ While this specification makes use of the unused variant bits of 111 defined in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.1" class="relref">Section 4.1.1</a></span>; the placement of the version within the same octet as the variant leaves room for a future variant.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
+<p id="section-4.1-9">
+ UUID Version 7 and 8 specified by this document MUST set the first 3 bits of octet 8 to 111 and the fourth bit to 0. The 4 bit version MUST follow the variant to fill out the final bits of octet 8.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
+<p id="section-4.1-10">
+ Future specifications that wish to utilize variant 111 for a different version position (or any other bit layout position) MUST set the first 3 bits of octet 8 to 111 and then the fourth bit to 1.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
+<p id="section-4.1-11">
+ As such the tables below detail the three variants and versions described in this document where the letter "x" indicates a "don't-care" value.<a href="#section-4.1-11" class="pilcrow">¶</a></p>
+<span id="name-uuid-variant-defined-by-thi"></span><table class="center" id="table-1">
           <caption>
 <a href="#table-1" class="selfRef">Table 1</a>:
-<a href="#name-uuid-versions-defined-by-th" class="selfRef">UUID versions defined by this specification</a>
+<a href="#name-uuid-variant-defined-by-thi" class="selfRef">UUID Variant defined by this specification</a>
           </caption>
 <thead>
             <tr>
@@ -1650,93 +1778,99 @@ <h3 id="name-versions">
               <td class="text-left" rowspan="1" colspan="1">Msb1</td>
               <td class="text-left" rowspan="1" colspan="1">Msb2</td>
               <td class="text-left" rowspan="1" colspan="1">Msb3</td>
-              <td class="text-left" rowspan="1" colspan="1">Version</td>
               <td class="text-left" rowspan="1" colspan="1">Description</td>
             </tr>
           </thead>
           <tbody>
             <tr>
-              <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">6</td>
-              <td class="text-left" rowspan="1" colspan="1">Reordered Gregorian time-based UUID</td>
+              <td class="text-left" rowspan="1" colspan="1">x</td>
+              <td class="text-left" rowspan="1" colspan="1">x</td>
+              <td class="text-left" rowspan="1" colspan="1">The variant specified by <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span>. Hex characters 8, 9, A, B.</td>
             </tr>
             <tr>
-              <td class="text-left" rowspan="1" colspan="1">0</td>
               <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">1</td>
-              <td class="text-left" rowspan="1" colspan="1">7</td>
-              <td class="text-left" rowspan="1" colspan="1">Variable length Unix Epoch time-based UUID</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">The variant specified in this document. Hex character E,</td>
             </tr>
             <tr>
               <td class="text-left" rowspan="1" colspan="1">1</td>
-              <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">8</td>
-              <td class="text-left" rowspan="1" colspan="1">Custom time-based UUID</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">Reserved for future definition. Hex Character F.</td>
             </tr>
           </tbody>
         </table>
-</section>
-</div>
-<div id="variant">
-<section id="section-4.2">
-        <h3 id="name-variant">
-<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-variant" class="section-name selfRef">Variant</a>
-        </h3>
-<p id="section-4.2-1">
- The variant bits utilized by UUIDs in this specification 
- remains the same as <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.1" class="relref">Section 4.1.1</a></span>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.2-2">
- The Table 2 lists the contents of the variant field, bits 64 and 65,
- where the letter "x" indicates a "don't-care" value. Common hex values of 
- 8 (1000), 9 (1001), A (1010), and B (1011) frequent the text representation.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
-<span id="name-uuid-variant-defined-by-thi"></span><table class="center" id="table-2">
+<span id="name-uuid-versions-defined-by-th"></span><table class="center" id="table-2">
           <caption>
 <a href="#table-2" class="selfRef">Table 2</a>:
-<a href="#name-uuid-variant-defined-by-thi" class="selfRef">UUID Variant defined by this specification</a>
+<a href="#name-uuid-versions-defined-by-th" class="selfRef">UUID versions defined by this specification</a>
           </caption>
 <thead>
             <tr>
               <td class="text-left" rowspan="1" colspan="1">Msb0</td>
               <td class="text-left" rowspan="1" colspan="1">Msb1</td>
               <td class="text-left" rowspan="1" colspan="1">Msb2</td>
+              <td class="text-left" rowspan="1" colspan="1">Msb3</td>
+              <td class="text-left" rowspan="1" colspan="1">Version</td>
               <td class="text-left" rowspan="1" colspan="1">Description</td>
             </tr>
           </thead>
           <tbody>
             <tr>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">1</td>
               <td class="text-left" rowspan="1" colspan="1">0</td>
-              <td class="text-left" rowspan="1" colspan="1">x</td>
-              <td class="text-left" rowspan="1" colspan="1">The variant specified in this document.</td>
+              <td class="text-left" rowspan="1" colspan="1">6</td>
+              <td class="text-left" rowspan="1" colspan="1">Reordered Gregorian time-based UUID</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">7</td>
+              <td class="text-left" rowspan="1" colspan="1">Unix Epoch time-based UUID</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">1</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">0</td>
+              <td class="text-left" rowspan="1" colspan="1">8</td>
+              <td class="text-left" rowspan="1" colspan="1">Custom UUID</td>
             </tr>
           </tbody>
         </table>
 </section>
 </div>
-<div id="uuidv6layout">
-<section id="section-4.3">
-        <h3 id="name-uuidv6-layout-and-bit-order">
-<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-uuidv6-layout-and-bit-order" class="section-name selfRef">UUIDv6 Layout and Bit Order</a>
+<div id="uuidv6">
+<section id="section-4.2">
+        <h3 id="name-uuid-version-6">
+<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-uuid-version-6" class="section-name selfRef">UUID Version 6</a>
         </h3>
-<p id="section-4.3-1">
- UUIDv6 aims to be the easiest to implement by reusing most of the layout of bits
- found in UUIDv1 but with changes to bit ordering for the timestamp.
- Where UUIDv1 splits the timestamp bits into three distinct parts and orders them as
- time_low, time_mid, time_high_and_version. UUIDv6 instead keeps the source bits
- from the timestamp intact and changes the order to time_high, time_mid, and time_low.
- Incidentally this will match the original 60 bit Gregorian timestamp source with 100-nanosecond precision defined in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.4" class="relref">Section 4.1.4</a></span> 
- The clock sequence bits remain unchanged from their usage and position in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.5" class="relref">Section 4.1.5</a></span>.
- The 48 bit node SHOULD be set to a pseudo-random value however implementations MAY choose retain the old MAC address behavior from <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.6" class="relref">Section 4.1.6</a></span> and <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.5" class="relref">Section 4.5</a></span><a href="#section-4.3-1" class="pilcrow">¶</a></p>
-<p id="section-4.3-2">
- The format for the 16-octet, 128 bit UUIDv6 is shown in Figure 1<a href="#section-4.3-2" class="pilcrow">¶</a></p>
-<span id="name-uuidv6-field-and-bit-layout"></span><figure id="figure-1">
-          <div class="alignLeft art-text artwork" id="section-4.3-3.1">
+<p id="section-4.2-1">
+ UUID version 6 is a field-compatible version of UUIDv1, reordered for improved DB locality. 
+ It is expected that UUIDv6 will primarily be used in contexts where there are existing v1 UUIDs.
+ Systems that do not involve legacy UUIDv1 SHOULD consider using UUIDv7 instead.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
+<p id="section-4.2-2">
+ 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 timestamp value as specified for UUIDv1 in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.4" class="relref">Section 4.1.4</a></span>,
+ for UUIDv6, the first 48 most significant bits are stored
+ first, followed by the 4 bit version (same position), followed by the remaining 12 bits of the original 60 bit timestamp.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
+<p id="section-4.2-3">
+ The clock sequence bits remain unchanged from their usage and position in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.5" class="relref">Section 4.1.5</a></span>.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
+<p id="section-4.2-4">
+ The 48 bit node SHOULD be set to a pseudo-random value however implementations MAY choose retain the old MAC address behavior from <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.6" class="relref">Section 4.1.6</a></span> and <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.5" class="relref">Section 4.5</a></span>. For more information on MAC address usage within UUIDs see the <a href="#Security" class="xref">Section 7</a><a href="#section-4.2-4" class="pilcrow">¶</a></p>
+<p id="section-4.2-5">
+ The format for the 16-byte, 128 bit UUIDv6 is shown in Figure 1<a href="#section-4.2-5" class="pilcrow">¶</a></p>
+<span id="name-uuidv6-field-and-bit-layout"></span><figure id="figure-3">
+          <div class="alignLeft art-text artwork" id="section-4.2-6.1">
 <pre>
      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
@@ -1751,1045 +1885,498 @@ <h3 id="name-uuidv6-layout-and-bit-order">
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 </div>
-<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
+<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
 <a href="#name-uuidv6-field-and-bit-layout" class="selfRef">UUIDv6 Field and Bit Layout</a>
           </figcaption></figure>
-<span class="break"></span><dl class="dlNewline" id="section-4.3-4">
-          <dt id="section-4.3-4.1">time_high:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.2">The most significant 32 bits of the 60 bit starting timestamp.
-            Occupies bits 0 through 31 (octets 0-3)<a href="#section-4.3-4.2" class="pilcrow">¶</a>
+<span class="break"></span><dl class="dlNewline" id="section-4.2-7">
+          <dt id="section-4.2-7.1">time_high:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.2">The most significant 32 bits of the 60 bit starting timestamp.
+            Occupies bits 0 through 31 (octets 0-3)<a href="#section-4.2-7.2" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.3-4.3">time_mid:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.4">The middle 16 bits of the 60 bit starting timestamp.
-            Occupies bits 32 through 47 (octets 4-5)<a href="#section-4.3-4.4" class="pilcrow">¶</a>
+<dt id="section-4.2-7.3">time_mid:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.4">The middle 16 bits of the 60 bit starting timestamp.
+            Occupies bits 32 through 47 (octets 4-5)<a href="#section-4.2-7.4" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.3-4.5">time_low_and_version:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.6">The first four most significant bits MUST contain
+<dt id="section-4.2-7.5">time_low_and_version:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.6">The first four most significant bits MUST contain
             the UUIDv6 version (0110) while the remaining 12 bits will contain
             the least significant 12 bits from the 60 bit starting timestamp.
-            Occupies bits 48 through 63 (octets 6-7)<a href="#section-4.3-4.6" class="pilcrow">¶</a>
+            Occupies bits 48 through 63 (octets 6-7)<a href="#section-4.2-7.6" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.3-4.7">clk_seq_hi_res:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.8">The first two bits MUST be set to the UUID variant (10)
+<dt id="section-4.2-7.7">clk_seq_hi_res:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.8">The first two bits MUST be set to the UUID variant (10)
             The remaining 6 bits contain the high portion of the clock sequence.
-            Occupies bits 64 through 71 (octet 8)<a href="#section-4.3-4.8" class="pilcrow">¶</a>
+            Occupies bits 64 through 71 (octet 8)<a href="#section-4.2-7.8" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.3-4.9">clock_seq_low:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.10">The 8 bit low portion of the clock sequence.
-            Occupies bits 72 through 79 (octet 9)<a href="#section-4.3-4.10" class="pilcrow">¶</a>
+<dt id="section-4.2-7.9">clock_seq_low:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.10">The 8 bit low portion of the clock sequence.
+            Occupies bits 72 through 79 (octet 9)<a href="#section-4.2-7.10" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.3-4.11">node:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.3-4.12">48 bit spatially unique identifier
-            Occupies bits 80 through 127 (octets 10-15)<a href="#section-4.3-4.12" class="pilcrow">¶</a>
+<dt id="section-4.2-7.11">node:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.2-7.12">48 bit spatially unique identifier
+            Occupies bits 80 through 127 (octets 10-15)<a href="#section-4.2-7.12" class="pilcrow">¶</a>
 </dd>
         <dd class="break"></dd>
 </dl>
-<div id="uuidv6pseudo">
-<section id="section-4.3.1">
-          <h4 id="name-uuidv6-basic-creation-algor">
-<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-uuidv6-basic-creation-algor" class="section-name selfRef">UUIDv6 Basic Creation Algorithm</a>
-          </h4>
-<p id="section-4.3.1-1">
- The following implementation algorithm is based on <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span>
- but with changes specific to UUIDv6:<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.3.1-2">
- <li id="section-4.3.1-2.1">
-              <p id="section-4.3.1-2.1.1">From a system-wide shared stable store (e.g., a file) or global variable, read the
-   UUID generator state: the values of the timestamp and clock sequence
-   used to generate the last UUID.<a href="#section-4.3.1-2.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.2">
-              <p id="section-4.3.1-2.2.1">Obtain the current time as a 60 bit count of 100-nanosecond intervals
-   since 00:00:00.00, 15 October 1582.<a href="#section-4.3.1-2.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.3">
-              <p id="section-4.3.1-2.3.1">Set the time_low field to the 12 least significant bits
-   of the starting 60 bit timestamp.<a href="#section-4.3.1-2.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.4">
-              <p id="section-4.3.1-2.4.1">Truncate the timestamp to the 48 most significant bits
-   in order to create time_high_and_time_mid.<a href="#section-4.3.1-2.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.5">
-              <p id="section-4.3.1-2.5.1">Set the time_high field to the 32 most significant bits of the truncated timestamp.<a href="#section-4.3.1-2.5.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.6">
-              <p id="section-4.3.1-2.6.1">Set the time_mid field to the 16 least significant bits of the truncated timestamp.<a href="#section-4.3.1-2.6.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.7">
-              <p id="section-4.3.1-2.7.1">Create the 16 bit time_low_and_version by concatenating the 4 bit UUIDv6 version
-   with the 12 bit time_low.<a href="#section-4.3.1-2.7.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.8">
-              <p id="section-4.3.1-2.8.1">If the state was unavailable (e.g., non-existent or corrupted)
-   or the timestamp is greater than the current timestamp generate
-   a random 14 bit clock sequence value.<a href="#section-4.3.1-2.8.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.9">
-              <p id="section-4.3.1-2.9.1">If the state was available, but the saved timestamp is less than or equal to the current
-   timestamp, increment the clock sequence value.<a href="#section-4.3.1-2.9.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.10">
-              <p id="section-4.3.1-2.10.1">Complete the 16 bit clock sequence high, low and reserved creation
-   by concatenating the clock sequence onto UUID variant bits which take
-   the most significant position in the 16 bit value.<a href="#section-4.3.1-2.10.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.11">
-              <p id="section-4.3.1-2.11.1">Generate a 48 bit pseudo-random node.<a href="#section-4.3.1-2.11.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.12">
-              <p id="section-4.3.1-2.12.1">Format by concatenating the 128 bits from each parts:
-   time_high|time_mid|time_low_and_version|variant_clk_seq|node<a href="#section-4.3.1-2.12.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.3.1-2.13">
-              <p id="section-4.3.1-2.13.1">Save the state (current timestamp and clock sequence)
-   back to the stable store<a href="#section-4.3.1-2.13.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
-<p id="section-4.3.1-3">
- The steps for splitting time_high_and_time_mid into time_high and time_mid are optional
- since the 48 bits of time_high and time_mid will remain in the same order as time_high_and_time_mid
- during the final concatenation. This extra step of splitting into the most significant
+<p id="section-4.2-8">
+ With UUIDv6 the steps for splitting the timestamp into time_high and time_mid are optional
+ 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.
- In which the following logic can be applied to reshuffle the bits with minimal modifications.<a href="#section-4.3.1-3" class="pilcrow">¶</a></p>
+ In which the following logic can be applied to reshuffle the bits with minimal modifications.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
 <span id="name-uuidv1-to-uuidv6-field-mapp"></span><table class="center" id="table-3">
-            <caption>
+          <caption>
 <a href="#table-3" class="selfRef">Table 3</a>:
 <a href="#name-uuidv1-to-uuidv6-field-mapp" class="selfRef">UUIDv1 to UUIDv6 Field Mappings</a>
-            </caption>
+          </caption>
 <thead>
-              <tr>
-                <td class="text-left" rowspan="1" colspan="1">UUIDv1 Field</td>
-                <td class="text-left" rowspan="1" colspan="1">Bits</td>
-                <td class="text-left" rowspan="1" colspan="1">UUIDv6 Field</td>
-              </tr>
-            </thead>
-            <tbody>
-              <tr>
-                <td class="text-left" rowspan="1" colspan="1">time_low </td>
-                <td class="text-left" rowspan="1" colspan="1">32</td>
-                <td class="text-left" rowspan="1" colspan="1">time_high</td>
-              </tr>
-              <tr>
-                <td class="text-left" rowspan="1" colspan="1">time_mid </td>
-                <td class="text-left" rowspan="1" colspan="1">16</td>
-                <td class="text-left" rowspan="1" colspan="1">time_mid</td>
-              </tr>
-              <tr>
-                <td class="text-left" rowspan="1" colspan="1">time_high</td>
-                <td class="text-left" rowspan="1" colspan="1">12</td>
-                <td class="text-left" rowspan="1" colspan="1">time_low</td>
-              </tr>
-            </tbody>
-          </table>
-</section>
-</div>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">UUIDv1 Field</td>
+              <td class="text-left" rowspan="1" colspan="1">Bits</td>
+              <td class="text-left" rowspan="1" colspan="1">UUIDv6 Field</td>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">time_low </td>
+              <td class="text-left" rowspan="1" colspan="1">32</td>
+              <td class="text-left" rowspan="1" colspan="1">time_high</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">time_mid </td>
+              <td class="text-left" rowspan="1" colspan="1">16</td>
+              <td class="text-left" rowspan="1" colspan="1">time_mid</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">time_high</td>
+              <td class="text-left" rowspan="1" colspan="1">12</td>
+              <td class="text-left" rowspan="1" colspan="1">time_low</td>
+            </tr>
+          </tbody>
+        </table>
 </section>
 </div>
-<div id="uuidv7layout">
-<section id="section-4.4">
-        <h3 id="name-uuidv7-layout-and-bit-order">
-<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-uuidv7-layout-and-bit-order" class="section-name selfRef">UUIDv7 Layout and Bit Order</a>
+<div id="uuidv7">
+<section id="section-4.3">
+        <h3 id="name-uuid-version-7">
+<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-uuid-version-7" class="section-name selfRef">UUID Version 7</a>
         </h3>
-<p id="section-4.4-1">
- The UUIDv7 format is designed to encode a Unix timestamp with arbitrary sub-second precision.
- The key property provided by UUIDv7 is that timestamp values generated by one system and parsed by
- another are guaranteed to have sub-second precision of either the generator or the parser,
- whichever is less. Additionally, the system parsing the UUIDv7 value does not need to know which precision
- was used during encoding in order to function correctly.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
-<p id="section-4.4-2">
- The format for the 16-octet, 128 bit UUIDv7 is shown in Figure 2<a href="#section-4.4-2" class="pilcrow">¶</a></p>
-<span id="name-uuidv7-field-and-bit-layout"></span><figure id="figure-2">
-          <div class="alignLeft art-text artwork" id="section-4.4-3.1">
+<p id="section-4.3-1">
+ UUID version 7 features a time-ordered value field derived from the widely implemented and well known Unix Epoch timestamp source, as well as improved entropy characteristics over versions 1 or 6.
+ Implementations SHOULD utilize UUID version 7 over UUID version 1 and 6 if possible.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
+<span id="name-uuidv7-field-and-bit-layout"></span><figure id="figure-4">
+          <div class="alignLeft art-text artwork" id="section-4.3-2.1">
 <pre>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |       subsec_a        |  ver  |       subsec_b        |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|                   subsec_seq_node                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                       subsec_seq_node                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ 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           |             rand              |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    var_ver    |            rand_b                             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                            rand_b                             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 </div>
-<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
+<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
 <a href="#name-uuidv7-field-and-bit-layout" class="selfRef">UUIDv7 Field and Bit Layout</a>
           </figcaption></figure>
-<span class="break"></span><dl class="dlNewline" id="section-4.4-4">
-          <dt id="section-4.4-4.1">unixts:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.2">36 bit big-endian unsigned Unix Timestamp value<a href="#section-4.4-4.2" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-4.4-4.3">subsec_a:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.4">12 bits allocated to sub-second precision values.<a href="#section-4.4-4.4" class="pilcrow">¶</a>
+<span class="break"></span><dl class="dlNewline" id="section-4.3-3">
+          <dt id="section-4.3-3.1">unix_ts_ms:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.3-3.2">48 bit big-endian unsigned number of unix epoch timestamp as per <a href="#timestamp_granularity" class="xref">Section 5.1</a><a href="#section-4.3-3.2" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.4-4.5">ver:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.6">The 4 bit UUIDv7 version (0111)<a href="#section-4.4-4.6" class="pilcrow">¶</a>
+<dt id="section-4.3-3.3">rand_a:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.3-3.4">16 bits pseudo-random data to provide uniqueness as per <a href="#unguessability" class="xref">Section 5.6</a><a href="#section-4.3-3.4" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.4-4.7">subsec_b:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.8">12 bits allocated to sub-second precision values.<a href="#section-4.4-4.8" class="pilcrow">¶</a>
+<dt id="section-4.3-3.5">var_ver:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.3-3.6">The 8 bit combined variant and version field with the value 0xE7 as defined by <a href="#variant_and_version_fields" class="xref">Section 4.1</a>.<a href="#section-4.3-3.6" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.4-4.9">var:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.10">2 bit UUID variant (10)<a href="#section-4.4-4.10" class="pilcrow">¶</a>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-4.4-4.11">subsec_seq_node:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.4-4.12">The remaining 62 bits which MAY be allocated to any combination of additional sub-second precision, sequence counter, or pseudo-random data.<a href="#section-4.4-4.12" class="pilcrow">¶</a>
+<dt id="section-4.3-3.7">rand_b:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.3-3.8">The final 56 bits of pseudo-random data to provide uniqueness as per <a href="#unguessability" class="xref">Section 5.6</a> and <a href="#monotonicity_counters" class="xref">Section 5.2</a>.<a href="#section-4.3-3.8" class="pilcrow">¶</a>
 </dd>
         <dd class="break"></dd>
 </dl>
-<div id="uuidv7timestamp">
-<section id="section-4.4.1">
-          <h4 id="name-uuidv7-timestamp-usage">
-<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-uuidv7-timestamp-usage" class="section-name selfRef">UUIDv7 Timestamp Usage</a>
-          </h4>
-<p id="section-4.4.1-1">UUIDv7 utilizes a 36 bit big-endian unsigned Unix Timestamp value (number of seconds since the epoch of 1 Jan 1970, leap seconds excluded so each hour is exactly 3600 seconds long). The 36 bit value was selected in order to provide more available time to the unix timestamp and avoid the Year 2038 problem by extending the maximum timestamp to the year 4147.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.1-2">To achieve a 36 bit UUIDv7 timestamp, the lower 36 bits of a 64 bit unix time are extracted verbatim into UUIDv7<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
-<p id="section-4.4.1-3">In the event that 32 bit Unix Timestamp are in use; four zeros MUST be appended at the start in the most significant (left-most) bits of the 32 bit Unix timestamp creating the 36 bit Unix timestamp. This ensures sorting compatibility with 64 bit unix timestamp which have been truncated to 36 bits.<a href="#section-4.4.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.4.1-4">Additional sub-second precision (millisecond, nanosecond, microsecond, etc) MAY be provided for encoding and decoding in the remaining bits in the layout.<a href="#section-4.4.1-4" class="pilcrow">¶</a></p>
-<p id="section-4.4.1-5">UUIDv8 SHOULD be used in place of UUIDv7 if an application or implementation does not want to truncate a 64 bit Unix Epoch to the lower 36 bits.<a href="#section-4.4.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="uuidv7sequence">
-<section id="section-4.4.2">
-          <h4 id="name-uuidv7-clock-sequence-usage">
-<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-uuidv7-clock-sequence-usage" class="section-name selfRef">UUIDv7 Clock Sequence Usage</a>
-          </h4>
-<p id="section-4.4.2-1">
- UUIDv7 SHOULD utilize a monotonic sequence counter to provide additional sequencing guarantees when multiple UUIDv7 values are created in the same UNIXTS and SUBSEC timestamp.
- The amount of bits allocates to the sequence counter depend on the precision of the timestamp. For example, a more accurate timestamp source using nanosecond precision will require less clock sequence bits than a timestamp source utilizing seconds for precision.
- For best sequencing results the sequence counter SHOULD be placed immediately after available sub-second bits.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.2-2">
- The clock sequence MUST start at zero and increment monotonically
- for each new UUIDv7 created on by the application on the same timestamp.
- When the timestamp increments the clock sequence MUST be reset to zero.
- The clock sequence MUST NOT rollover or reset to zero unless the timestamp
- has incremented. Care MUST be given to ensure that an adequate sized
- clock sequence is selected for a given application based on expected
- timestamp precision and expected UUIDv7 generation rates.<a href="#section-4.4.2-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="uuidv7node">
-<section id="section-4.4.3">
-          <h4 id="name-uuidv7-node-usage">
-<a href="#section-4.4.3" class="section-number selfRef">4.4.3. </a><a href="#name-uuidv7-node-usage" class="section-name selfRef">UUIDv7 Node Usage</a>
-          </h4>
-<p id="section-4.4.3-1">
- UUIDv7 implementations, even with very detailed sub-second precision and the optional sequence counter, MAY have leftover bits that will be identified as the Node for this section.
- The UUIDv7 Node MAY contain any set of data an implementation desires however the node MUST NOT be set to all 0s which does not ensure global uniqueness. In most scenarios the node SHOULD be filled with pseudo-random data.<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="uuidv7encodingdecoding">
-<section id="section-4.4.4">
-          <h4 id="name-uuidv7-encoding-and-decodin">
-<a href="#section-4.4.4" class="section-number selfRef">4.4.4. </a><a href="#name-uuidv7-encoding-and-decodin" class="section-name selfRef">UUIDv7 Encoding and Decoding</a>
-          </h4>
-<p id="section-4.4.4-1">
- The UUIDv7 bit layout for encoding and decoding are described separately in this document.<a href="#section-4.4.4-1" class="pilcrow">¶</a></p>
-<div id="uuidv7encoding">
-<section id="section-4.4.4.1">
-            <h5 id="name-uuidv7-encoding">
-<a href="#section-4.4.4.1" class="section-number selfRef">4.4.4.1. </a><a href="#name-uuidv7-encoding" class="section-name selfRef">UUIDv7 Encoding</a>
-            </h5>
-<p id="section-4.4.4.1-1">
-  Since the UUIDv7 Unix timestamp is fixed at 36 bits in length the exact layout for encoding UUIDv7 depends on the precision (number of bits)
-  used for the sub-second portion and the sizes of the optionally desired sequence counter and node bits.<a href="#section-4.4.4.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-2">
- Three examples of UUIDv7 encoding are given below as a general guidelines but implementations are not limited to just these three examples.<a href="#section-4.4.4.1-2" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-3">
- All of these fields are only used during encoding, and during decoding the system is unaware of the bit layout used for them and considers this information opaque.
- As such, implementations generating these values can assign whatever lengths to each field it deems applicable, as long as it does not break decoding compatibility
- (i.e. Unix timestamp (unixts), version (ver) and variant (var) have to stay where they are, and clock sequence counter (seq), random (random) or other implementation specific values must follow the sub-second encoding).<a href="#section-4.4.4.1-3" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-4">
- In Figure 3 the UUIDv7 has been created with millisecond precision with the available sub-second precision bits.<a href="#section-4.4.4.1-4" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-5">
- Examining Figure 3 one can observe:<a href="#section-4.4.4.1-5" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.4.4.1-6.1">
-                <p id="section-4.4.4.1-6.1.1">The first 36 bits have been dedicated to the Unix Timestamp (unixts)<a href="#section-4.4.4.1-6.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-6.2">
-                <p id="section-4.4.4.1-6.2.1">All 12 bits of scenario subsec_a is fully dedicated to millisecond information (msec).<a href="#section-4.4.4.1-6.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-6.3">
-                <p id="section-4.4.4.1-6.3.1">The 4 Version bits remain unchanged (ver).<a href="#section-4.4.4.1-6.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-6.4">
-                <p id="section-4.4.4.1-6.4.1">All 12 bits of subsec_b have been dedicated to a monotonic clock sequence counter (seq).<a href="#section-4.4.4.1-6.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-6.5">
-                <p id="section-4.4.4.1-6.5.1">The 2 Variant bits remain unchanged (var).<a href="#section-4.4.4.1-6.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-6.6">
-                <p id="section-4.4.4.1-6.6.1">Finally the remaining 62 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).<a href="#section-4.4.4.1-6.6.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-<span id="name-uuidv7-field-and-bit-layout-"></span><figure id="figure-3">
-              <div class="alignLeft art-text artwork" id="section-4.4.4.1-7.1">
-<pre>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         msec          |  ver  |          seq          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|                         rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</pre>
-</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
-<a href="#name-uuidv7-field-and-bit-layout-" class="selfRef">UUIDv7 Field and Bit Layout - Encoding Example (Millisecond Precision)</a>
-              </figcaption></figure>
-<p id="section-4.4.4.1-8">
- In Figure 4 the UUIDv7 has been created with Microsecond precision with the available sub-second precision bits.<a href="#section-4.4.4.1-8" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-9">
- Examining Figure 4 one can observe:<a href="#section-4.4.4.1-9" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.4.4.1-10.1">
-                <p id="section-4.4.4.1-10.1.1">The first 36 bits have been dedicated to the Unix Timestamp (unixts)<a href="#section-4.4.4.1-10.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.2">
-                <p id="section-4.4.4.1-10.2.1">All 12 bits of scenario subsec_a is fully dedicated to providing sub-second encoding for the Microsecond precision (usec).<a href="#section-4.4.4.1-10.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.3">
-                <p id="section-4.4.4.1-10.3.1">The 4 Version bits remain unchanged (ver).<a href="#section-4.4.4.1-10.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.4">
-                <p id="section-4.4.4.1-10.4.1">All 12 bits of subsec_b have been dedicated to providing sub-second encoding for the Microsecond precision (usec).<a href="#section-4.4.4.1-10.4.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.5">
-                <p id="section-4.4.4.1-10.5.1">The 2 Variant bits remain unchanged (var).<a href="#section-4.4.4.1-10.5.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.6">
-                <p id="section-4.4.4.1-10.6.1">A 14 bit monotonic clock sequence counter (seq) has been embedded in the most significant position of subsec_seq_node<a href="#section-4.4.4.1-10.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-10.7">
-                <p id="section-4.4.4.1-10.7.1">Finally the remaining 48 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).<a href="#section-4.4.4.1-10.7.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-<span id="name-uuidv7-field-and-bit-layout-e"></span><figure id="figure-4">
-              <div class="alignLeft art-text artwork" id="section-4.4.4.1-11.1">
-<pre>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         usec          |  ver  |         usec          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|             seq           |            rand               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</pre>
-</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
-<a href="#name-uuidv7-field-and-bit-layout-e" class="selfRef">UUIDv7 Field and Bit Layout - Encoding Example (Microsecond Precision)</a>
-              </figcaption></figure>
-<p id="section-4.4.4.1-12">
- In Figure 5 the UUIDv7 has been created with Nanosecond precision with the available sub-second precision bits.<a href="#section-4.4.4.1-12" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.1-13">
- Examining Figure 5 one can observe:<a href="#section-4.4.4.1-13" class="pilcrow">¶</a></p>
+<div id="uuidv8">
+<section id="section-4.4">
+        <h3 id="name-uuid-version-8">
+<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-uuid-version-8" class="section-name selfRef">UUID Version 8</a>
+        </h3>
+<p id="section-4.4-1">
+ UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases.
+ The only requirement is that the variant and version bits MUST be set as defined in <a href="#variant_and_version_fields" class="xref">Section 4.1</a>. 
+ UUIDv8's uniqueness will be implementation-specific and should not be assumed.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
+<p id="section-4.4-2">
+ UUIDv8 SHOULD only be utilized if an implementation cannot utilize another UUID in this document or <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span>.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
+<p id="section-4.4-3">
+ The only explicitly defined bits are the Version and Variant leaving 120 bits
+ for implementation specific time-based UUIDs. To be clear:
+ UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
+ filled with random data.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
+<p id="section-4.4-4">
+ Some example situations in which UUIDv8 usage could occur:<a href="#section-4.4-4" class="pilcrow">¶</a></p>
 <ul class="normal">
-<li class="normal" id="section-4.4.4.1-14.1">
-                <p id="section-4.4.4.1-14.1.1">The first 36 bits have been dedicated to the Unix Timestamp (unixts)<a href="#section-4.4.4.1-14.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-14.2">
-                <p id="section-4.4.4.1-14.2.1">All 12 bits of scenario subsec_a is fully dedicated to providing sub-second encoding for the Nanosecond precision (nsec).<a href="#section-4.4.4.1-14.2.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-14.3">
-                <p id="section-4.4.4.1-14.3.1">The 4 Version bits remain unchanged (ver).<a href="#section-4.4.4.1-14.3.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-14.4">
-                <p id="section-4.4.4.1-14.4.1">All 12 bits of subsec_b have been dedicated to providing sub-second encoding for the Nanosecond precision (nsec).<a href="#section-4.4.4.1-14.4.1" class="pilcrow">¶</a></p>
+<li class="normal" id="section-4.4-5.1">
+            <p id="section-4.4-5.1.1">An implementation would like to embed extra information
+   within the UUID other than what is defined in this document.<a href="#section-4.4-5.1.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="normal" id="section-4.4.4.1-14.5">
-                <p id="section-4.4.4.1-14.5.1">The 2 Variant bits remain unchanged (var).<a href="#section-4.4.4.1-14.5.1" class="pilcrow">¶</a></p>
+          <li class="normal" id="section-4.4-5.2">
+            <p id="section-4.4-5.2.1">An implementation has other application/language restrictions which
+   inhibit the use of one of the current UUIDs.<a href="#section-4.4-5.2.1" class="pilcrow">¶</a></p>
 </li>
-              <li class="normal" id="section-4.4.4.1-14.6">
-                <p id="section-4.4.4.1-14.6.1">The first 14 bit of the subsec_seq_node dedicated to providing sub-second encoding for the Nanosecond precision (nsec).<a href="#section-4.4.4.1-14.6.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-14.7">
-                <p id="section-4.4.4.1-14.7.1">The next 8 bits of subsec_seq_node dedicated a monotonic clock sequence counter (seq).<a href="#section-4.4.4.1-14.7.1" class="pilcrow">¶</a></p>
-</li>
-              <li class="normal" id="section-4.4.4.1-14.8">
-                <p id="section-4.4.4.1-14.8.1">Finally the remaining 40 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).<a href="#section-4.4.4.1-14.8.1" class="pilcrow">¶</a></p>
-</li>
-            </ul>
-<span id="name-uuidv7-field-and-bit-layout-en"></span><figure id="figure-5">
-              <div class="alignLeft art-text artwork" id="section-4.4.4.1-15.1">
+        </ul>
+<span id="name-uuidv8-field-and-bit-layout"></span><figure id="figure-5">
+          <div class="alignLeft art-text artwork" id="section-4.4-6.1">
 <pre>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         nsec          |  ver  |         nsec          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|             nsec          |      seq      |     rand      |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ 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                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    var_ver    |           custom_b                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           custom_b                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </pre>
 </div>
 <figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
-<a href="#name-uuidv7-field-and-bit-layout-en" class="selfRef">UUIDv7 Field and Bit Layout - Encoding Example (Nanosecond Precision)</a>
-              </figcaption></figure>
-</section>
-</div>
-<div id="uuidv7decoding">
-<section id="section-4.4.4.2">
-            <h5 id="name-uuidv7-decoding">
-<a href="#section-4.4.4.2" class="section-number selfRef">4.4.4.2. </a><a href="#name-uuidv7-decoding" class="section-name selfRef">UUIDv7 Decoding</a>
-            </h5>
-<p id="section-4.4.4.2-1">
- When decoding or parsing a UUIDv7 value there are only two values to be considered:<a href="#section-4.4.4.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.4.4.2-2">
- <li id="section-4.4.4.2-2.1">
-                <p id="section-4.4.4.2-2.1.1">The unix timestamp defined as unixts<a href="#section-4.4.4.2-2.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li id="section-4.4.4.2-2.2">
-                <p id="section-4.4.4.2-2.2.1">The sub-second precision values defined as subsec_a, subsec_b, and subsec_seq_node<a href="#section-4.4.4.2-2.2.1" class="pilcrow">¶</a></p>
-</li>
-            </ol>
-<p id="section-4.4.4.2-3">As detailed in Figure 2 the unix timestamp (unixts) is always the first 36 bits of the UUIDv7 layout.<a href="#section-4.4.4.2-3" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.2-4">
- Similarly as per Figure 2, the sub-second precision values lie within subsec_a, subsec_b, and subsec_seq_node which are all interpreted as sub-second information after skipping over the version (ver) and (var) bits.  
- These concatenated sub-second information bits are interpreted in a way where most to least significant bits represent a further division by two.
- This is the same normal place notation used to express fractional numbers, except in binary. For example, in decimal ".1" means one tenth, and ".01" means one hundredth.
- In this subsec field, a 1 means one half, 01 means one quarter, 001 is one eighth, etc.
- This scheme can work for any number of bits up to the maximum available, and keeps the most significant data leftmost in the bit sequence.<a href="#section-4.4.4.2-4" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.2-5">
- To perform the sub-second math, simply take the first (most significant/leftmost) N bits of subsec and divide it by 2^N. Take for example:<a href="#section-4.4.4.2-5" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.4.4.2-6">
- <li id="section-4.4.4.2-6.1">
-                <p id="section-4.4.4.2-6.1.1">To parse the first 16 bits, extract that value as an integer and divide it by 65536 (2 to the 16th).<a href="#section-4.4.4.2-6.1.1" class="pilcrow">¶</a></p>
-</li>
-              <li id="section-4.4.4.2-6.2">
-                <p id="section-4.4.4.2-6.2.1">If these 16 bits are 0101 0101 0101 0101, then treating that as an integer gives 0x5555 or 21845 in decimal, and dividing by 65536 gives 0.3333282<a href="#section-4.4.4.2-6.2.1" class="pilcrow">¶</a></p>
-</li>
-            </ol>
-<p id="section-4.4.4.2-7">
- This sub-second encoding scheme provides maximum interoperability across systems where different levels of time precision are required/feasible/available.
- The timestamp value derived from a UUIDv7 value SHOULD be "as close to the correct value as possible" when parsed, even across disparate systems.<a href="#section-4.4.4.2-7" class="pilcrow">¶</a></p>
-<p id="section-4.4.4.2-8">
- Take for example the starting point for our next two UUIDv7 parsing scenarios:<a href="#section-4.4.4.2-8" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.4.4.2-9">
- <li id="section-4.4.4.2-9.1">System A produces a UUIDv7 with a microsecond-precise timestamp value.<a href="#section-4.4.4.2-9.1" class="pilcrow">¶</a>
-</li>
-              <li id="section-4.4.4.2-9.2">System B is unaware of the precision encoded in the UUIDv7 timestamp by System A.<a href="#section-4.4.4.2-9.2" class="pilcrow">¶</a>
-</li>
-            </ol>
-<p id="section-4.4.4.2-10">
- Scenario 1:<a href="#section-4.4.4.2-10" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.4.4.2-11">
- <li id="section-4.4.4.2-11.1">System B parses the embedded timestamp with millisecond precision. (Less precision than the encoder)<a href="#section-4.4.4.2-11.1" class="pilcrow">¶</a>
-</li>
-              <li id="section-4.4.4.2-11.2">System B SHOULD return the correct millisecond value encoded by system A (truncated to milliseconds).<a href="#section-4.4.4.2-11.2" class="pilcrow">¶</a>
-</li>
-            </ol>
-<p id="section-4.4.4.2-12">
- Scenario 2:<a href="#section-4.4.4.2-12" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.4.4.2-13">
- <li id="section-4.4.4.2-13.1">System B parses the timestamp with nanosecond precision. (More precision than the encoder)<a href="#section-4.4.4.2-13.1" class="pilcrow">¶</a>
-</li>
-              <li id="section-4.4.4.2-13.2">System B's value returned SHOULD have the same microsecond level of precision provided by the encoder with the additional precision down to nanosecond level being essentially random as per the encoded random value at the end of the UUIDv7.<a href="#section-4.4.4.2-13.2" class="pilcrow">¶</a>
-</li>
-            </ol>
-</section>
-</div>
+<a href="#name-uuidv8-field-and-bit-layout" class="selfRef">UUIDv8 Field and Bit Layout</a>
+          </figcaption></figure>
+<span class="break"></span><dl class="dlNewline" id="section-4.4-7">
+          <dt id="section-4.4-7.1">custom_a:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.4-7.2">The first 64 bits of the layout that can be filled as an implementation sees fit.<a href="#section-4.4-7.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-4.4-7.3">var_ver:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.4-7.4">The 8 bit combined variant and version field with the value 0xE8 as defined by <a href="#variant_and_version_fields" class="xref">Section 4.1</a>.<a href="#section-4.4-7.4" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-4.4-7.5">custom_b:</dt>
+          <dd style="margin-left: 1.5em" id="section-4.4-7.6">The final 56 bits of the layout immediatly following the var_var field to be filled as an implementation sees fit.<a href="#section-4.4-7.6" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
 </section>
 </div>
 </section>
 </div>
-<div id="uuidv8layout">
-<section id="section-4.5">
-        <h3 id="name-uuidv8-layout-and-bit-order">
-<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-uuidv8-layout-and-bit-order" class="section-name selfRef">UUIDv8 Layout and Bit Order</a>
+<div id="uuid_best_practices">
+<section id="section-5">
+      <h2 id="name-uuid-best-practices">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-uuid-best-practices" class="section-name selfRef">UUID Best Practices</a>
+      </h2>
+<p id="section-5-1">
+ The minimum requirements for generating UUIDs are 
+ described in this document for each version.
+ Everything else is an implementation detail and 
+ up to the implementer to decide what is appropriate for a given 
+ implementation. That being said, various relevant factors are covered
+ below to help guide an implementer through the different trade-offs among differing UUID implementations.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<div id="timestamp_granularity">
+<section id="section-5.1">
+        <h3 id="name-timestamp-granularity">
+<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-timestamp-granularity" class="section-name selfRef">Timestamp Granularity</a>
         </h3>
-<p id="section-4.5-1">
-        UUIDv8 offers variable-size timestamp, clock sequence, and node values
-        which allow for a highly customizable UUID that fits a given application needs.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
-<p id="section-4.5-2">
-        UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv7.
-        Some situations in which UUIDv8 usage could occur:<a href="#section-4.5-2" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.5-3.1">
-            <p id="section-4.5-3.1.1">An implementation would like to utilize a timestamp source
-              not defined by the current time-based UUIDs.<a href="#section-4.5-3.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-4.5-3.2">
-            <p id="section-4.5-3.2.1">An implementation would like to utilize a timestamp bit layout
-              not defined by the current time-based UUIDs.<a href="#section-4.5-3.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-4.5-3.3">
-            <p id="section-4.5-3.3.1">An implementation would like to avoid truncating a 64 bit Unix to 36 bits as defined by UUIDv7.<a href="#section-4.5-3.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-4.5-3.4">
-            <p id="section-4.5-3.4.1">An implementation would like a specific level of precision
-              within the timestamp not offered by current time-based UUIDs.<a href="#section-4.5-3.4.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-4.5-3.5">
-            <p id="section-4.5-3.5.1">An implementation would like to embed extra information
-              within the UUID node other than what is defined in this document.<a href="#section-4.5-3.5.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-4.5-3.6">
-            <p id="section-4.5-3.6.1">An implementation has other application/language restrictions which
-              inhibit the usage of one of the current time-based UUIDs.<a href="#section-4.5-3.6.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-<p id="section-4.5-4">
-        Roughly speaking a properly formatted UUIDv8 SHOULD contain
-        the following sections adding up to a total of 128 bits.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty">
-<li class="compact ulEmpty" id="section-4.5-5.1">
-            <p id="section-4.5-5.1.1">- Timestamp Bits (Variable Length)<a href="#section-4.5-5.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="compact ulEmpty" id="section-4.5-5.2">
-            <p id="section-4.5-5.2.1">- Clock Sequence Bits (Variable Length)<a href="#section-4.5-5.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="compact ulEmpty" id="section-4.5-5.3">
-            <p id="section-4.5-5.3.1">- Node Bits (Variable Length)<a href="#section-4.5-5.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="compact ulEmpty" id="section-4.5-5.4">
-            <p id="section-4.5-5.4.1">- UUIDv8 Version Bits (4 bits)<a href="#section-4.5-5.4.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="compact ulEmpty" id="section-4.5-5.5">
-            <p id="section-4.5-5.5.1">- UUID Variant Bits (2 Bits)<a href="#section-4.5-5.5.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-<p id="section-4.5-6">
-        The only explicitly defined bits are the Version and Variant leaving 122 bits
-        for implementation specific time-based UUIDs. To be clear:
-        UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
-        filled with random data. UUIDv8's 128 bits (including the version and variant)
-        SHOULD contain at the minimum a timestamp of some format in the most
-        significant bit position followed directly by a clock sequence counter
-        and finally a node containing either random data or implementation specific data.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
-<p id="section-4.5-7">
-        A sample format in Figure 6 is used to further illustrate the point
-        for the 16-octet, 128 bit UUIDv8.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
-<span id="name-uuidv8-field-and-bit-layout"></span><figure id="figure-6">
-          <div class="alignLeft art-text artwork" id="section-4.5-8.1">
-<pre>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                          timestamp_32                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |           timestamp_48        |  ver  |      time_or_seq      |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|  seq_or_node  |          node                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                              node                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</pre>
-</div>
-<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
-<a href="#name-uuidv8-field-and-bit-layout" class="selfRef">UUIDv8 Field and Bit Layout</a>
-          </figcaption></figure>
-<span class="break"></span><dl class="dlNewline" id="section-4.5-9">
-          <dt id="section-4.5-9.1">timestamp_32:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.2">The most significant 32 bits of the desired timestamp source.
-            Occupies bits 0 through 31 (octets 0-3).<a href="#section-4.5-9.2" class="pilcrow">¶</a>
+<p id="section-5.1-1">
+ UUID timestamp source, precision and length was the topic of great debate while creating this specification. As such choosing the right timestamp for your application is a very important topic. This section will detail some of the most common points on this topic.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
+<span class="break"></span><dl class="dlNewline" id="section-5.1-2">
+          <dt id="section-5.1-2.1">Reliability:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.2">Implementations SHOULD use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing. Care SHOULD be taken to ensure the timestamp does not move backwards which will impact UUID sorting.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.3">timestamp_48:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.4">The next 16 bits of the timestamp source when a timestamp
-            source with at least 48 bits is used. When a 32 bit timestamp source
-            is utilized, these bits are set to 0. Occupies bits 32 through 47<a href="#section-4.5-9.4" class="pilcrow">¶</a>
+<dt id="section-5.1-2.3">Source:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.4">UUID version 1 and 6 both utilize a Gregorian epoch timestamp while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp sources or a custom timestamp epoch are required UUIDv8 SHOULD be leveraged.<a href="#section-5.1-2.4" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.5">ver:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.6">The 4 bit UUIDv8 version (1000). Occupies bits 48 through 51.<a href="#section-4.5-9.6" class="pilcrow">¶</a>
+<dt id="section-5.1-2.5">Sub-second Precision and Accuracy:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.6">Many levels of precision exist for timestamps: milliseconds, microseconds, nanoseconds, and beyond. Additionally fractional representations of sub-second precision may be desired to mix various levels of precision in a time-ordered manner. With UUID version 1 and 6, 100-nanoseconds of precision are present while UUIDv7 features fixed millisecond level of precision within the Unix epoch. If additional levels of precision are required UUIDv8 SHOULD be utilized.<a href="#section-5.1-2.6" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.7">time_or_seq:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.8">If a 60 bit, or larger, timestamp is used these 12 bits are used to
-            fill out the remaining timestamp. If a 32 or 48 bit timestamp
-            is leveraged a 12 bit clock sequence MAY be used. 
- Together ver and time_or_seq occupy bits 48 through 63 (octets 6-7)<a href="#section-4.5-9.8" class="pilcrow">¶</a>
+<dt id="section-5.1-2.7">Length:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.8">The length of a given timestamp directly impacts how long a given UUID will be valid. Care should be given to ensure that the proper length is selected for a given timestamp. UUID version 1 and 6 utilize a 60 bit timestamp and UUIDv7 features a 48 bit timestamp.<a href="#section-5.1-2.8" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.9">var:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.10">2 bit UUID variant (10)<a href="#section-4.5-9.10" class="pilcrow">¶</a>
+<dt id="section-5.1-2.9">Fuzzing:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.10">Implementations MAY fuzz a timestamp. Some examples included security considerations around providing a real clock value within a UUID or to correct inaccurate clocks. This specification makes no requirement or guarantee about how close the clock value needs to be to actual time.<a href="#section-5.1-2.10" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.11">seq_or_node:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.12">If a 60 bit, or larger, timestamp source is leverages these 8 bits
-            SHOULD be allocated for an 8 bit clock sequence counter. If
-            a 32 or 48 bit timestamp source is used these 8 bits SHOULD be set to random.<a href="#section-4.5-9.12" class="pilcrow">¶</a>
+<dt id="section-5.1-2.11">Padding:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.12">When timestamp padding is required, implementations MUST pad the most significant bits (left-most) bits with zeros. An example is padding the most significant, left-most bits of a 32 bit unix timestamp with zero's to fill out the 48 bit timestamp in UUIDv7.<a href="#section-5.1-2.12" class="pilcrow">¶</a>
 </dd>
           <dd class="break"></dd>
-<dt id="section-4.5-9.13">node:</dt>
-          <dd style="margin-left: 1.5em" id="section-4.5-9.14">In most implementations these bits will likely be set to
-            pseudo-random data. However, implementations utilize the node as they see fit.
-            Together var, seq_or_node, and node occupy Bits 64 through 127 (octets 8-15)<a href="#section-4.5-9.14" class="pilcrow">¶</a>
+<dt id="section-5.1-2.13">Truncating:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.1-2.14">Similarly, when timestamps need to be truncated: the lower, least significant bits MUST be used. An example would be truncating a 64 bit unix timestamp to the least significant, right-most 48 bits for UUIDv7.<a href="#section-5.1-2.14" class="pilcrow">¶</a>
 </dd>
         <dd class="break"></dd>
 </dl>
-<div id="uuidv8timestamp">
-<section id="section-4.5.1">
-          <h4 id="name-uuidv8-timestamp-usage">
-<a href="#section-4.5.1" class="section-number selfRef">4.5.1. </a><a href="#name-uuidv8-timestamp-usage" class="section-name selfRef">UUIDv8 Timestamp Usage</a>
-          </h4>
-<p id="section-4.5.1-1">
-            UUIDv8's usage of timestamp relaxes both the timestamp source
-            and timestamp length. Implementations are free to utilize
-            any monotonically stable timestamp source for UUIDv8.<a href="#section-4.5.1-1" class="pilcrow">¶</a></p>
-<p id="section-4.5.1-2">
-            Some examples include:<a href="#section-4.5.1-2" class="pilcrow">¶</a></p>
-<ul class="compact ulEmpty">
-<li class="compact ulEmpty" id="section-4.5.1-3.1">
-              <p id="section-4.5.1-3.1.1">- Custom Epoch<a href="#section-4.5.1-3.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="compact ulEmpty" id="section-4.5.1-3.2">
-              <p id="section-4.5.1-3.2.1">- NTP timestamp<a href="#section-4.5.1-3.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="compact ulEmpty" id="section-4.5.1-3.3">
-              <p id="section-4.5.1-3.3.1">- ISO 8601 timestamp<a href="#section-4.5.1-3.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="compact ulEmpty" id="section-4.5.1-3.4">
-              <p id="section-4.5.1-3.4.1">- Full, Non-truncated 64 bit Unix Epoch timestamp<a href="#section-4.5.1-3.4.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="section-4.5.1-4">
-            The relaxed nature UUIDv8 timestamps also works to future proof
-            this specification and allow implementations a method to create
-            compliant time-based UUIDs using timestamp source that might not yet be defined.<a href="#section-4.5.1-4" class="pilcrow">¶</a></p>
-<p id="section-4.5.1-5">
-            Timestamps come in many sizes and UUIDv8 defines three fields
-            that can easily used for the majority of timestamp lengths:<a href="#section-4.5.1-5" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-4.5.1-6.1">
-              <p id="section-4.5.1-6.1.1">32 bit timestamp: using timestamp_32 and setting timestamp_48 to 0s<a href="#section-4.5.1-6.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.5.1-6.2">
-              <p id="section-4.5.1-6.2.1">48 bit timestamp: using timestamp_32 and timestamp_48 entirely<a href="#section-4.5.1-6.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.5.1-6.3">
-              <p id="section-4.5.1-6.3.1">60 bit timestamp: using timestamp_32, timestamp_48, and time_or_seq<a href="#section-4.5.1-6.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-4.5.1-6.4">
-              <p id="section-4.5.1-6.4.1">64 bit timestamp: using timestamp_32, timestamp_48, and time_or_seq
-                  and truncating the timestamp the 60 most significant bits.<a href="#section-4.5.1-6.4.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="section-4.5.1-7">
-            Although it is possible to create a timestamp larger than 64 bits in size
-            The usage and bit layout of that timestamp format is up to the implementation.
-            When a timestamp exceeds the 64th bit (octet 7), extra care must be taken to
-            ensure the Variant bits are properly inserted at their respective location
-            in the UUID. Likewise, the Version MUST always be implemented at the appropriate
-            location.<a href="#section-4.5.1-7" class="pilcrow">¶</a></p>
-<p id="section-4.5.1-8">
-            Any timestamps that does not entirely fill the timestamp_32, timestamp_48
-            or time_or_seq MUST set all leftover bits in the least significant position
-            of the respective field to 0. For example a 36 bit timestamp source would
-            fully utilize timestamp_32 and 4 bits of timestamp_48.
-            The remaining 12 bits in timestamp_48 MUST be set to 0.<a href="#section-4.5.1-8" class="pilcrow">¶</a></p>
-<p id="section-4.5.1-9">
-            By using implementation-specific timestamp sources it is not
-            guaranteed that devices outside of the application context are able to
-            extract and parse the timestamp from UUIDv8 without some pre-existing
-            knowledge of the source timestamp used by the UUIDv8 implementation.<a href="#section-4.5.1-9" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="uuidv8sequence">
-<section id="section-4.5.2">
-          <h4 id="name-uuidv8-clock-sequence-usage">
-<a href="#section-4.5.2" class="section-number selfRef">4.5.2. </a><a href="#name-uuidv8-clock-sequence-usage" class="section-name selfRef">UUIDv8 Clock Sequence Usage</a>
-          </h4>
-<p id="section-4.5.2-1">
-            A clock sequence MUST be used with UUIDv8 as added sequencing guarantees
-            when multiple UUIDv8 will be created on the same clock tick.
-            The amount of bits allocated to the clock sequence depends on the
-            precision of the timestamp source. For example, a more accurate timestamp source using
-            nanosecond precision will require less clock sequence bits than a timestamp
-            source utilizing seconds for precision.<a href="#section-4.5.2-1" class="pilcrow">¶</a></p>
-<p id="section-4.5.2-2">
-            The UUIDv8 layout in Figure 6 generically defines two possible
-            clock sequence values that can leveraged:<a href="#section-4.5.2-2" class="pilcrow">¶</a></p>
-<ul class="compact">
-<li class="compact" id="section-4.5.2-3.1">
-              <p id="section-4.5.2-3.1.1">12 bit clock sequence using time_or_seq for use when the timestamp
-                  is less than 48 bits which allows for 4095 UUIDs per clock tick.<a href="#section-4.5.2-3.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="compact" id="section-4.5.2-3.2">
-              <p id="section-4.5.2-3.2.1">8 bit clock sequence using seq_or_node when the timestamp uses
-                  more than 48 bits which allows for 255 UUIDs per clock tick.<a href="#section-4.5.2-3.2.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="section-4.5.2-4">
-            An implementation MAY use both time_or_seq and seq_or_node for clock sequencing
-            however it is highly unlikely that 20 bits of clock sequence are needed
-            for a given clock tick. Furthermore, more bits from the node MAY be used
-            for clock sequencing in the event that 8 bits is not sufficient.<a href="#section-4.5.2-4" class="pilcrow">¶</a></p>
-<p id="section-4.5.2-5">
-            The clock sequence MUST start at zero and increment monotonically
-            for each new UUIDv8 created on by the application on the same timestamp.
-            When the timestamp increments the clock sequence MUST be reset to zero.
-            The clock sequence MUST NOT rollover or reset to zero unless the timestamp
-            has incremented. Care MUST be given to ensure that an adequate sized
-            clock sequence is selected for a given application based on expected
-            timestamp precision and expected UUIDv8 generation rates.<a href="#section-4.5.2-5" class="pilcrow">¶</a></p>
+<div id="monotonicity_counters">
+<section id="section-5.2">
+        <h3 id="name-monotonicity-and-counters">
+<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-monotonicity-and-counters" class="section-name selfRef">Monotonicity and Counters</a>
+        </h3>
+<p id="section-5.2-1">
+ Monotonicity is the backbone of time-based sortable UUIDs. Naturally 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.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
+<p id="section-5.2-2">
+ Additionally, care MUST be taken to ensure UUIDs generated in batches are also monotonic. That is, if one-thousand UUIDs are generated for the same timestamp; there is sufficient logic for organizing the creation of order of those one-thousand UUIDs.
+ For batch UUID creation implements MAY utilize a monotonic counter which SHOULD increment for each UUID created during a given timestamp.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
+<p id="section-5.2-3">
+ For single-node UUID implementations that do not need to create batches of UUIDs, the embedded timestamp within UUID version 1, 6, and 7 can provide sufficient monotonicity guarantees by simply ensuring that timestamp increments before creating a new UUID. For the topic of Distributed Nodes please refer to <a href="#distributed_shared_knowledge" class="xref">Section 5.3</a><a href="#section-5.2-3" class="pilcrow">¶</a></p>
+<p id="section-5.2-4">
+ The following methods SHOULD be employed for single-node UUID implementations that do require batch UUID creation.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
+<span class="break"></span><dl class="dlNewline" id="section-5.2-5">
+          <dt id="section-5.2-5.1">Fixed-Length Dedicated Counter Bits (Position A):</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.2">
+ This references the practice of allocating 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.
+ Positioning of a fixed bit-length counter SHOULD be immediatly after the embedded timestamp. This promotes sortability and allows random data generation for each counter increment. UUIDs utilizing this method should be created using UUIDv8.<a href="#section-5.2-5.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.2-5.3">Fixed-Length Dedicated Counter Bits (Position B):</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.4">
+ An alternative approach to the previous method is to dedicate a number of bits in the least significant position of the UUID. With this alternative method, the random data MUST be frozen for a given timestamp tick else sorting will be impacted. UUIDs utilizing this method should be created using UUIDv8.<a href="#section-5.2-5.4" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.2-5.5">Fixed-Length Dedicated Counter Seeding:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.6">
+ Implementations utilizing fixed-length counter bits SHOULD initialize the counter at zero to ensure the full bit-space is utilized and help avoid counter rollovers.<a href="#section-5.2-5.6" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.2-5.7">Fixed-Length Dedicated Counter Length</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.8">Care MUST be taken to select a counter bit-length that can properly handle the level of timestamp precision in use. For example, millisecond precision SHOULD require a larger counter than a timestamp with nanosecond precision. General Guidance is that the counter SHOULD be at least 12 bits and no more than a maximum of 24 bits.<a href="#section-5.2-5.8" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.2-5.9">Fixed-Length Dedicated Counter Rollover Handling</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.10">
+ Counter rollovers SHOULD be handled by the application to avoid sorting issues. The general guidance is that applications should freeze the counter and wait for the timestamp to advance which ensures monotonicity is not broken.<a href="#section-5.2-5.10" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.2-5.11">Monotonic Random:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.2-5.12">
+ With this method the random data is extended to also double as a counter. This monotonic random can be thought of as a "randomly seeded counter" which MUST be incremented in the least significant position for each UUID created on a given timestamp tick. This is similar to the Fixed-Length Dedicated Counter Bits (Position B) method described in the previous bullets but does not suffer from rollover issues, length problems, or wasted entropy bits plagued by both fixed-length counter bit positions. As such, UUIDv7 SHOULD utilize this method to handle batch UUID generation during a single timestamp tick.<a href="#section-5.2-5.12" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
+<p id="section-5.2-6">
+ Implementations MAY use the following logic to ensure UUIDs featuring embedded counters are monotonic in nature:<a href="#section-5.2-6" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2-7">
+ <li id="section-5.2-7.1">
+            <p id="section-5.2-7.1.1">Compare the current timestamp against the previously stored timestamp.<a href="#section-5.2-7.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-5.2-7.2">
+            <p id="section-5.2-7.2.1">If the current timestamp is equal to the previous timestamp; increment desired counter logic.<a href="#section-5.2-7.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-5.2-7.3">
+            <p id="section-5.2-7.3.1">If the current timestamp is greater than the previous timestamp; re-initialize the counter to the new timestamp and generate new random bytes (if the bytes were frozen or being used as the seed for a monotonic counter).<a href="#section-5.2-7.3.1" class="pilcrow">¶</a></p>
+</li>
+        </ol>
+<p id="section-5.2-8">
+ Implementations SHOULD check if the the currently generated UUID is greater than the previously generated UUID. If this is not the case then any number of things could have occurred. Such as, but not limited to, clock rollbacks or counter rollovers. Applications SHOULD embed sufficient logic to catch these scenarios and correct the problem ensuring the next UUID generated is greater than the previous.<a href="#section-5.2-8" class="pilcrow">¶</a></p>
+<p id="section-5.2-9">
+ UUIDv1, and by extension UUIDv6, utilize a slightly different counter in the form of "clock sequence" bits. The usage of the clock sequence will remain as defined in <span>[<a href="#RFC4122" class="xref">RFC4122</a>], <a href="https://rfc-editor.org/rfc/rfc4122#section-4.1.5" class="relref">Section 4.1.5</a></span>.<a href="#section-5.2-9" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="uuidv8node">
-<section id="section-4.5.3">
-          <h4 id="name-uuidv8-node-usage">
-<a href="#section-4.5.3" class="section-number selfRef">4.5.3. </a><a href="#name-uuidv8-node-usage" class="section-name selfRef">UUIDv8 Node Usage</a>
-          </h4>
-<p id="section-4.5.3-1">
-            The UUIDv8 Node MAY contain any set of data an implementation desires however
-            the node MUST NOT be set to all 0s which does not ensure global uniqueness.
-            In most scenarios the node will be filled with pseudo-random data.<a href="#section-4.5.3-1" class="pilcrow">¶</a></p>
-<p id="section-4.5.3-2">
-            The UUIDv8 layout in Figure 6 defines 2 sizes of Node
-            depending on the timestamp size:<a href="#section-4.5.3-2" class="pilcrow">¶</a></p>
-<ul class="compact">
-<li class="compact" id="section-4.5.3-3.1">
-              <p id="section-4.5.3-3.1.1">62 bit node encompassing seq_or_node and node
-                  Used when a timestamp of 48 bits or less is leveraged.<a href="#section-4.5.3-3.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="compact" id="section-4.5.3-3.2">
-              <p id="section-4.5.3-3.2.1">54 bit node when all 60 bits of the timestamp are
-                  in use and the seq_or_node is used as clock sequencing.<a href="#section-4.5.3-3.2.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<p id="section-4.5.3-4">
-            An implementation MAY choose to allocate bits from the node to the timestamp,
-            clock sequence or application-specific embedded field.
-            It is recommended that implementation utilize a node of at least 48 bits to
-            ensure global uniqueness can be guaranteed.<a href="#section-4.5.3-4" class="pilcrow">¶</a></p>
+<div id="distributed_shared_knowledge">
+<section id="section-5.3">
+        <h3 id="name-distributed-uuid-generation">
+<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-distributed-uuid-generation" class="section-name selfRef">Distributed UUID Generation</a>
+        </h3>
+<p id="section-5.3-1">
+ Some implementations MAY desire to utilize multi-node, clustered, applications which involve two or more 
+ applications 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 nodes increase; so does the likelihood of a collision. 
+ This section will detail the approaches that MAY be utilized by multi-node UUID implementations in distributed environments.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
+<span class="break"></span><dl class="dlNewline" id="section-5.3-2">
+          <dt id="section-5.3-2.1">Shared Knowledge System:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.3-2.2">With this 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. Utilization of shared knowledge schemes with central/global registries is outside the scope of this specification.<a href="#section-5.3-2.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.3-2.3">Node IDs:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.3-2.4">With this method, a nondescript pseudo-random Node ID value is placed within the UUID layout. This identifier ensures the 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 SHOULD utilize UUIDv8. The node id SHOULD NOT be an IEEE 802 MAC address as per <a href="#Security" class="xref">Section 7</a>. The location and bit length are up to implements and outside the scope of this specification. Furthermore, the creation and negotiation of a node id among distributed nodes is also out of scope for this specification.<a href="#section-5.3-2.4" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
+<p id="section-5.3-3">
+ Utilization of either a shared knowledge scheme or Node ID are not required for implementing UUIDs in this specification. However implementations SHOULD utilize one of the two aforementioned methods if distributed UUID generation is a requirements.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="collision_resistance">
+<section id="section-5.4">
+        <h3 id="name-collision-resistance">
+<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-collision-resistance" class="section-name selfRef">Collision Resistance</a>
+        </h3>
+<p id="section-5.4-1">
+ Implementations SHOULD weigh the importance of a collision within their application and take this into account when making a selections around the total entropy (random) to dedicated to a UUID layout versus the other components such as <a href="#timestamp_granularity" class="xref">Section 5.1</a> and <a href="#monotonicity_counters" class="xref">Section 5.2</a>. This is especially true for distributed node collision resistance as defined by <a href="#distributed_shared_knowledge" class="xref">Section 5.3</a>.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
+<p id="section-5.4-2">
+ There are two example scenarios below which help illustrate the varying seriousness of a collision within an application.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
+<span class="break"></span><dl class="dlNewline" id="section-5.4-3">
+          <dt id="section-5.4-3.1">Low Impact</dt>
+          <dd style="margin-left: 1.5em" id="section-5.4-3.2">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.<a href="#section-5.4-3.2" class="pilcrow">¶</a>
+</dd>
+          <dd class="break"></dd>
+<dt id="section-5.4-3.3">High Impact:</dt>
+          <dd style="margin-left: 1.5em" id="section-5.4-3.4"> A duplicate key causes an airplane to receive the wrong course which puts people's lives at risk. In this scenario there is no margin for error. Collisions MUST be avoided and failure is unacceptable. As such applications dealing with this type of scenario MUST employ as much collision resistance as possible within the given application context.<a href="#section-5.4-3.4" class="pilcrow">¶</a>
+</dd>
+        <dd class="break"></dd>
+</dl>
 </section>
 </div>
-<div id="uuidv8pseudo">
-<section id="section-4.5.4">
-          <h4 id="name-uuidv8-basic-creation-algor">
-<a href="#section-4.5.4" class="section-number selfRef">4.5.4. </a><a href="#name-uuidv8-basic-creation-algor" class="section-name selfRef">UUIDv8 Basic Creation Algorithm</a>
-          </h4>
-<p id="section-4.5.4-1">
-            The entire usage of UUIDv8 is meant to be variable
-            and allow as much customization as possible to meet
-            specific application/language requirements.
-            As such any UUIDv8 implementations will likely vary among applications.<a href="#section-4.5.4-1" class="pilcrow">¶</a></p>
-<p id="section-4.5.4-2">
-            The following algorithm is a generic implementation using Figure 6
-            and the recommendations outlined in this specification.<a href="#section-4.5.4-2" class="pilcrow">¶</a></p>
-<p id="section-4.5.4-3">
-            <strong>32 bit timestamp, 12 bit sequence counter, 62 bit node:</strong><a href="#section-4.5.4-3" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.5.4-4">
- <li id="section-4.5.4-4.1">
-              <p id="section-4.5.4-4.1.1">From a system-wide shared stable store (e.g., a file) or global variable,
-   read the UUID generator state: the values of the timestamp
-   and clock sequence used to generate the last UUID.<a href="#section-4.5.4-4.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.2">
-              <p id="section-4.5.4-4.2.1">Obtain the current time from the selected clock source as 32 bits.<a href="#section-4.5.4-4.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.3">
-              <p id="section-4.5.4-4.3.1">Set the 32 bit field timestamp_32 to the 32 bits from the timestamp<a href="#section-4.5.4-4.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.4">
-              <p id="section-4.5.4-4.4.1">Set 16 bit timestamp_48 to all 0s<a href="#section-4.5.4-4.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.5">
-              <p id="section-4.5.4-4.5.1">Set the version to 8 (1000)<a href="#section-4.5.4-4.5.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.6">
-              <p id="section-4.5.4-4.6.1">If the state was unavailable (e.g., non-existent or corrupted) or
-   the timestamp is greater than the current timestamp;
-   set the 12 bit clock sequence value (time_or_seq) to 0<a href="#section-4.5.4-4.6.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.7">
-              <p id="section-4.5.4-4.7.1">If the state was available, but the saved timestamp is less than
-   or equal to the current timestamp, increment the clock sequence
-   value (time_or_seq).<a href="#section-4.5.4-4.7.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.8">
-              <p id="section-4.5.4-4.8.1">Set the variant to binary 10<a href="#section-4.5.4-4.8.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.9">
-              <p id="section-4.5.4-4.9.1">Generate 62 random bits and fill in 8 bits for seq_or_node and
-   54 bits for the node.<a href="#section-4.5.4-4.9.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.10">
-              <p id="section-4.5.4-4.10.1">Format by concatenating the 128 bits as:
-   timestamp_32|timestamp_48|version|time_or_seq|variant|seq_or_node|node<a href="#section-4.5.4-4.10.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-4.11">
-              <p id="section-4.5.4-4.11.1">Save the state (current timestamp and clock sequence)
-   back to the stable store<a href="#section-4.5.4-4.11.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
-<p id="section-4.5.4-5">
-            <strong>48 bit timestamp, 12 bit sequence counter, 62 bit node:</strong><a href="#section-4.5.4-5" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.5.4-6">
- <li id="section-4.5.4-6.1">
-              <p id="section-4.5.4-6.1.1">From a system-wide shared stable store (e.g., a file) or global variable,
-   read the UUID generator state: the values of the timestamp
-   and clock sequence used to generate the last UUID.<a href="#section-4.5.4-6.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-6.2">
-              <p id="section-4.5.4-6.2.1">Obtain the current time from the selected clock source as 32 bits.<a href="#section-4.5.4-6.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-6.3">
-              <p id="section-4.5.4-6.3.1">Set the 32 bit field timestamp_32 to the 32 most significant bits
-   from the timestamp<a href="#section-4.5.4-6.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-6.4">
-              <p id="section-4.5.4-6.4.1">Set 16 bit timestamp_48 to the 16 least significant bits
-   from the timestamp<a href="#section-4.5.4-6.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-6.5">
-              <p id="section-4.5.4-6.5.1">The rest of the steps are the same as the previous example.<a href="#section-4.5.4-6.5.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
-<p id="section-4.5.4-7">
-            <strong>60 bit timestamp, 8 bit sequence counter, 54 bit node:</strong><a href="#section-4.5.4-7" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.5.4-8">
- <li id="section-4.5.4-8.1">
-              <p id="section-4.5.4-8.1.1">From a system-wide shared stable store (e.g., a file) or global variable,
-   read the UUID generator state: the values of the timestamp
-   and clock sequence used to generate the last UUID.<a href="#section-4.5.4-8.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.2">
-              <p id="section-4.5.4-8.2.1">Obtain the current time from the selected clock source as 32 bits.<a href="#section-4.5.4-8.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.3">
-              <p id="section-4.5.4-8.3.1">Set the 32 bit field timestamp_32 to the 32 bits from the timestamp<a href="#section-4.5.4-8.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.4">
-              <p id="section-4.5.4-8.4.1">Set 16 bit timestamp_48 to the 16 middle bits from the timestamp<a href="#section-4.5.4-8.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.5">
-              <p id="section-4.5.4-8.5.1">Set the version to 8 (1000)<a href="#section-4.5.4-8.5.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.6">
-              <p id="section-4.5.4-8.6.1">Set 12 bit time_or_seq to the 12 least significant bits from the timestamp<a href="#section-4.5.4-8.6.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.7">
-              <p id="section-4.5.4-8.7.1">Set the variant to 10<a href="#section-4.5.4-8.7.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.8">
-              <p id="section-4.5.4-8.8.1">If the state was unavailable (e.g., non-existent or corrupted)
-   or the timestamp is greater than the current timestamp;
-   set the 12 bit clock sequence value (seq_or_node) to 0<a href="#section-4.5.4-8.8.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.9">
-              <p id="section-4.5.4-8.9.1">If the state was available, but the saved timestamp is less than
-   or equal to the current timestamp, increment the clock sequence
-   value (seq_or_node).<a href="#section-4.5.4-8.9.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.10">
-              <p id="section-4.5.4-8.10.1">Generate 54 random bits and fill in the node<a href="#section-4.5.4-8.10.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.11">
-              <p id="section-4.5.4-8.11.1">Format by concatenating the 128 bits as:
-   timestamp_32|timestamp_48|version|time_or_seq|variant|seq_or_node|node<a href="#section-4.5.4-8.11.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-8.12">
-              <p id="section-4.5.4-8.12.1">Save the state (current timestamp and clock sequence) back to the stable store<a href="#section-4.5.4-8.12.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
-<p id="section-4.5.4-9">
-            <strong>64 bit timestamp, 8 bit sequence counter, 54 bit node:</strong><a href="#section-4.5.4-9" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.5.4-10">
- <li id="section-4.5.4-10.1">
-              <p id="section-4.5.4-10.1.1">The same steps as the 60 bit timestamp can be utilized
-   if the 64 bit timestamp is truncated to 60 bits.<a href="#section-4.5.4-10.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-10.2">
-              <p id="section-4.5.4-10.2.1">Implementations MAY chose to truncate the most or least significant
-   bits but it is recommended to utilize the most significant 60 bits
-   and lose 4 bits of precision in the nanoseconds or microseconds position.<a href="#section-4.5.4-10.2.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
-<p id="section-4.5.4-11">
-            <strong>General algorithm for generation of UUIDv8 not defined here:</strong><a href="#section-4.5.4-11" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-4.5.4-12">
- <li id="section-4.5.4-12.1">
-              <p id="section-4.5.4-12.1.1">From a system-wide shared stable store (e.g., a file) or global variable,
-   read the UUID generator state: the values of the timestamp
-   and clock sequence used to generate the last UUID.<a href="#section-4.5.4-12.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.2">
-              <p id="section-4.5.4-12.2.1">Obtain the current time from the selected clock source as desired bit total<a href="#section-4.5.4-12.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.3">
-              <p id="section-4.5.4-12.3.1">Set total amount of bits for timestamp as required in the most significant
-   positions of the 128 bit UUID<a href="#section-4.5.4-12.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.4">
-              <p id="section-4.5.4-12.4.1">Care MUST be taken to ensure that the UUID Version and UUID Variant are in the correct bit positions.<a href="#section-4.5.4-12.4.1" class="pilcrow">¶</a></p>
-<p id="section-4.5.4-12.4.2">UUID Version: Bits 48 through 51<a href="#section-4.5.4-12.4.2" class="pilcrow">¶</a></p>
-<p id="section-4.5.4-12.4.3">UUID Variant: Bits 64 and 65<a href="#section-4.5.4-12.4.3" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.5">
-              <p id="section-4.5.4-12.5.1">If the state was unavailable (e.g., non-existent or corrupted)
-   or the timestamp is greater than the current timestamp;
-   set the desired clock sequence value to 0<a href="#section-4.5.4-12.5.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.6">
-              <p id="section-4.5.4-12.6.1">If the state was available, but the saved timestamp is less than
-   or equal to the current timestamp, increment the clock sequence value.<a href="#section-4.5.4-12.6.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.7">
-              <p id="section-4.5.4-12.7.1">Set the remaining bits to the node as pseudo-random data<a href="#section-4.5.4-12.7.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.8">
-              <p id="section-4.5.4-12.8.1">Format by concatenating the 128 bits together<a href="#section-4.5.4-12.8.1" class="pilcrow">¶</a></p>
-</li>
-            <li id="section-4.5.4-12.9">
-              <p id="section-4.5.4-12.9.1">Save the state (current timestamp and clock sequence)
-   back to the stable store<a href="#section-4.5.4-12.9.1" class="pilcrow">¶</a></p>
-</li>
-          </ol>
+<div id="global_local_uniqueness">
+<section id="section-5.5">
+        <h3 id="name-global-and-local-uniqueness">
+<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-global-and-local-uniqueness" class="section-name selfRef">Global and Local Uniqueness</a>
+        </h3>
+<p id="section-5.5-1">
+ UUIDs created by this specification MAY be used to provide local uniqueness guarantees. 
+ For example, ensuring UUIDs created within a local application context are unique within a database MAY be sufficient for some implementations where global uniqueness outside of the application context, in other applications, or around the world is not required.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
+<p id="section-5.5-2">
+ Although true global uniqueness is impossible to guarantee without shared knowledge scheme; a shared knowledge scheme is not required by UUID to provide uniqueness guarantees.
+ Implementations MAY implement a shared knowledge scheme introduced in <a href="#distributed_shared_knowledge" class="xref">Section 5.3</a> as they see fit to extend the uniqueness guaranteed this specification and <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span>.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
 </section>
 </div>
+<div id="unguessability">
+<section id="section-5.6">
+        <h3 id="name-unguessability">
+<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-unguessability" class="section-name selfRef">Unguessability</a>
+        </h3>
+<p id="section-5.6-1">
+ Implementations SHOULD utilize a cryptographically secure pseudo-random number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique").
+ CSPRNG ensures the best of <a href="#collision_resistance" class="xref">Section 5.4</a> and <a href="#Security" class="xref">Section 7</a> are present in modern UUIDs.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
 </section>
 </div>
+<div id="sorting">
+<section id="section-5.7">
+        <h3 id="name-sorting">
+<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-sorting" class="section-name selfRef">Sorting</a>
+        </h3>
+<p id="section-5.7-1">
+ UUIDv6 and UUIDv7 are designed so that implementations that require sorting (e.g. database indexes) SHOULD sort as opaque raw bytes, without examining the contents at all.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
+<p id="section-5.7-2">
+ Time ordered monotonic UUIDs benefit from greater index locality because the new values are near each other in the index. 
+ As a result objects can much more easily be clustered together for better performance.  
+ The real-world differences in this approach of index locality vs random data inserts can be quite large.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="encoding">
-<section id="section-5">
-      <h2 id="name-encoding-and-storage">
-<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-encoding-and-storage" class="section-name selfRef">Encoding and Storage</a>
-      </h2>
-<p id="section-5-1">
-        The existing UUID hex and dash format of 8-4-4-4-12 is retained for both
-        backwards compatibility and human readability.<a href="#section-5-1" class="pilcrow">¶</a></p>
-<p id="section-5-2">
-        For many applications such as databases
-        this format is unnecessarily verbose totaling 288 bits.<a href="#section-5-2" class="pilcrow">¶</a></p>
+<div id="storing_uuids_opacity">
+<section id="section-5.8">
+        <h3 id="name-storing-uuids-opacity">
+<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-storing-uuids-opacity" class="section-name selfRef">Storing UUIDs, Opacity</a>
+        </h3>
+<p id="section-5.8-1">
+ For many applications, such as databases, storing UUIDs as the text is unnecessarily verbose totaling 288 bits to convey the 128 bit UUID value.
+ Due to the this, where possible, UUIDs SHOULD be stored within database applications as the underlying 128 bit binary value.<a href="#section-5.8-1" class="pilcrow">¶</a></p>
 <ul class="compact">
-<li class="compact" id="section-5-3.1">
-          <p id="section-5-3.1.1">8 bits for each of the 32 hex characters = 256 bits<a href="#section-5-3.1.1" class="pilcrow">¶</a></p>
+<li class="compact" id="section-5.8-2.1">
+            <p id="section-5.8-2.1.1">8 bits for each of the 32 hex characters = 256 bits<a href="#section-5.8-2.1.1" class="pilcrow">¶</a></p>
 </li>
-        <li class="compact" id="section-5-3.2">
-          <p id="section-5-3.2.1">8 bits for each of the 4 hyphens = 32 bits<a href="#section-5-3.2.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.8-2.2">
+            <p id="section-5.8-2.2.1">8 bits for each of the 4 hyphens = 32 bits<a href="#section-5.8-2.2.1" class="pilcrow">¶</a></p>
 </li>
-      </ul>
-<p id="section-5-4">
-        Where possible UUIDs SHOULD be stored within
-        database applications as the underlying 128 bit binary value.<a href="#section-5-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="uniquness">
-<section id="section-6">
-      <h2 id="name-global-uniqueness">
-<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-global-uniqueness" class="section-name selfRef">Global Uniqueness</a>
-      </h2>
-<p id="section-6-1">
-        UUIDs created by this specification offer the same guarantees for global uniqueness 
- as those found in <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span>. Furthermore, the time-based UUIDs defined in this specification 
- are geared towards database applications but MAY be used for a wide variety of use-cases. 
- Just as global uniqueness is guaranteed, UUIDs are guaranteed to be unique within an application 
- context within the enterprise domain.<a href="#section-6-1" class="pilcrow">¶</a></p>
+        </ul>
+<p id="section-5.8-3">
+ 
+ For other systems, UUIDs MAY be stored in binary form or as text, as appropriate. 
+ The trade offs to both approaches are as such:<a href="#section-5.8-3" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.8-4.1">
+            <p id="section-5.8-4.1.1">Storing as binary requires less space and may result in faster data access.<a href="#section-5.8-4.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="compact" id="section-5.8-4.2">
+            <p id="section-5.8-4.2.1">Storing as text requires more space but may require less translation if the resulting text form is to be used after retrieval and thus maybe simpler to implement.<a href="#section-5.8-4.2.1" class="pilcrow">¶</a></p>
+</li>
+        </ul>
+<p id="section-5.8-5">
+ UUIDs SHOULD be treated as opaque values and implementations SHOULD NOT examine the bits in a UUID to whatever extent is possible.<a href="#section-5.8-5" class="pilcrow">¶</a></p>
+<p id="section-5.8-6">
+ Where necessary, the version number may be extracted by first verifying the variant field bits 64 and 65 contain 1 and 0 respectively, and then extract the version from bits 48 through 51.
+ UUID versions 7 and 8 can be identified by checking octet 8 for the values 0xE7 or 0xE8 respectively.
+ The version number can then be used to inspect the remainder of the UUID according to the specification for that version.
+ See <a href="#variant_and_version_fields" class="xref">Section 4.1</a> for more information on determining a UUID version based on the inspected variant bits.<a href="#section-5.8-6" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="distributed">
-<section id="section-7">
-      <h2 id="name-distributed-uuid-generation">
-<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-distributed-uuid-generation" class="section-name selfRef">Distributed UUID Generation</a>
-      </h2>
-<p id="section-7-1">
-        Some implementations might desire to utilize multi-node, clustered, applications which involve 2 or more 
- applications independently generating UUIDs that will be stored in a common location. UUIDs already feature sufficient 
- entropy to ensure that the chances of collision are low. However, implementations MAY dedicate a 
- portion of the node's most significant random bits to a pseudo-random machineID which helps identify 
- UUIDs created by a given node. This works to add an extra layer of collision avoidance.<a href="#section-7-1" class="pilcrow">¶</a></p>
-<p id="section-7-2">
- This machine ID MUST be placed in the UUID after the timestamp and sequence counter bits. 
- This position is selected to ensure that the sorting by timestamp and clock sequence is still possible. 
- The machineID MUST NOT be an IEEE 802 MAC address. The creation and negotiation of the machineID 
- among distributed nodes is out of scope for this specification.<a href="#section-7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="IANA">
-<section id="section-8">
+<section id="section-6">
       <h2 id="name-iana-considerations">
-<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
       </h2>
-<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
+<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="Security">
-<section id="section-9">
+<section id="section-7">
       <h2 id="name-security-considerations">
-<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
       </h2>
-<p id="section-9-1"> 
-        MAC addresses pose inherent security risks and MUST not be used for node generation. 
- As such they have been strictly forbidden from time-based UUIDs within this specification.
- Instead pseudo-random bits SHOULD selected from a source with sufficient entropy to ensure guaranteed
- uniqueness among UUID generation.<a href="#section-9-1" class="pilcrow">¶</a></p>
-<p id="section-9-2">
-        Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with 
- the clock sequence does signal the order of creation for a given UUID and it's corresponding data but 
+<p id="section-7-1"> 
+ MAC addresses pose inherent security risks and SHOULD not be used within a UUID. 
+ Instead CSPRNG data SHOULD selected from a source with sufficient entropy to ensure guaranteed
+ uniqueness among UUID generation. See <a href="#unguessability" class="xref">Section 5.6</a> for more information.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-2">
+ 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 it's 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 then <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> UUIDv4 
- SHOULD be utilized.<a href="#section-9-2" class="pilcrow">¶</a></p>
-<p id="section-9-3">
-        The machineID portion of node, described in <a href="#distributed" class="xref">Section 7</a>, does 
- provide small unique identifier which could be used to determine which application is generating 
- data but this machineID alone is not enough to identify a node on the network without other corresponding 
- data points. Furthermore the machineID, like the timestamp+sequence, does not provide any context about 
- the data the corresponds to the UUID or the current state of the application as a whole.<a href="#section-9-3" class="pilcrow">¶</a></p>
+ use with any security operation within an application context in any shape or form then <span>[<a href="#RFC4122" class="xref">RFC4122</a>]</span> UUIDv4 SHOULD be utilized.<a href="#section-7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="Acknowledgements">
-<section id="section-10">
+<section id="section-8">
       <h2 id="name-acknowledgements">
-<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
       </h2>
-<p id="section-10-1">The authors gratefully acknowledge the contributions of 
-            Ben Campbell,
-            Ben Ramsey,
-            Fabio Lima,
-            Gonzalo Salgueiro, 
-            Martin Thomson,
-            Murray S. Kucherawy,
-            Rick van Rein,
-            Rob Wilton,
-            Sean Leonard,
-            Theodore Y. Ts'o.
-            As well as all of those in and outside the IETF community to who contributed to the discussions which resulted in this document.<a href="#section-10-1" class="pilcrow">¶</a></p>
+<p id="section-8-1">The authors gratefully acknowledge the contributions of 
+ 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,
+ sergeyprokhorenko,
+ LiosK
+ As well as all of those in the IETF community and on GitHub to who contributed to the discussions which resulted in this document.<a href="#section-8-1" class="pilcrow">¶</a></p>
 </section>
 </div>
-<section id="section-11">
+<section id="section-9">
       <h2 id="name-normative-references">
-<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
       </h2>
 <dl class="references">
 <dt id="RFC2119">[RFC2119]</dt>
       <dd>
 <span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="RFC8174">[RFC8174]</dt>
+      <dd>
+<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
+<dd class="break"></dd>
 <dt id="RFC4122">[RFC4122]</dt>
     <dd>
 <span class="refAuthor">Leach, P.</span>, <span class="refAuthor">Mealling, M.</span>, and <span class="refAuthor">R. Salz</span>, <span class="refTitle">"A Universally Unique IDentifier (UUID) URN Namespace"</span>, <span class="seriesInfo">RFC 4122</span>, <span class="seriesInfo">DOI 10.17487/RFC4122</span>, <time datetime="2005-07" class="refDate">July 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4122">https://www.rfc-editor.org/info/rfc4122</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 </dl>
 </section>
-<section id="section-12">
+<section id="section-10">
       <h2 id="name-informative-references">
-<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
+<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
       </h2>
 <dl class="references">
 <dt id="LexicalUUID">[LexicalUUID]</dt>
@@ -2853,13 +2440,304 @@ <h2 id="name-informative-references">
 <span class="refAuthor">MongoDB</span>, <span class="refTitle">"ObjectId - MongoDB Manual"</span>, <span>&lt;<a href="https://docs.mongodb.com/manual/reference/method/ObjectId/">https://docs.mongodb.com/manual/reference/method/ObjectId/</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="CUID">[CUID]</dt>
-    <dd>
+      <dd>
 <span class="refAuthor">Elliott, E.</span>, <span class="refTitle">"Collision-resistant ids optimized for horizontal scaling and performance."</span>, <span class="seriesInfo">Commit 215b27b</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://github.com/ericelliott/cuid">https://github.com/ericelliott/cuid</a>&gt;</span>. </dd>
 <dd class="break"></dd>
+<dt id="IEEE754">[IEEE754]</dt>
+    <dd>
+<span class="refAuthor">IEEE</span>, <span class="refTitle">"Collision-resistant ids optimized for horizontal scaling and performance."</span>, <span class="seriesInfo">Series 754-2019</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://standards.ieee.org/ieee/754/6210/">https://standards.ieee.org/ieee/754/6210/</a>&gt;</span>. </dd>
+<dd class="break"></dd>
 </dl>
 </section>
-<div id="authors-addresses">
+<div id="example_code">
 <section id="appendix-A">
+      <h2 id="name-example-code">
+<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-example-code" class="section-name selfRef">Example Code</a>
+      </h2>
+<div id="creating_a_uuidv6_value">
+<section id="appendix-A.1">
+        <h3 id="name-creating-a-uuidv6-value">
+<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-creating-a-uuidv6-value" class="section-name selfRef">Creating a UUIDv6 Value</a>
+        </h3>
+<p id="appendix-A.1-1">This section details a function in C which converts from a UUID version 1 to version 6:<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
+<span id="name-uuidv6-function-in-c"></span><figure id="figure-6">
+          <div class="alignLeft art-text artwork" id="appendix-A.1-2.1">
+<pre>
+#include &lt;stdio.h&gt;
+#include &lt;stdint.h&gt;
+#include &lt;inttypes.h&gt;
+#include &lt;arpa/inet.h&gt;
+#include &lt;uuid/uuid.h&gt;
+
+/* Converts UUID version 1 to version 6 in place. */
+void uuidv1tov6(uuid_t u) {
+
+  uint64_t ut;
+  unsigned char *up = (unsigned char *)u;
+
+  // load ut with the first 64 bits of the UUID
+  ut = ((uint64_t)ntohl(*((uint32_t*)up))) &lt;&lt; 32;
+  ut |= ((uint64_t)ntohl(*((uint32_t*)&amp;up[4])));
+
+  // dance the bit-shift...
+  ut =
+    ((ut &gt;&gt; 32) &amp; 0x0FFF) | // 12 least significant bits
+    (0x6000) | // version number
+    ((ut &gt;&gt; 28) &amp; 0x0000000FFFFF0000) | // next 20 bits
+    ((ut &lt;&lt; 20) &amp; 0x000FFFF000000000) | // next 16 bits
+    (ut &lt;&lt; 52); // 12 most significant bits
+
+  // store back in UUID
+  *((uint32_t*)up) = htonl((uint32_t)(ut &gt;&gt; 32));
+  *((uint32_t*)&amp;up[4]) = htonl((uint32_t)(ut));
+
+}
+</pre>
+</div>
+<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
+<a href="#name-uuidv6-function-in-c" class="selfRef">UUIDv6 Function in C</a>
+          </figcaption></figure>
+</section>
+</div>
+<div id="creating_a_uuidv7_value">
+<section id="appendix-A.2">
+        <h3 id="name-creating-a-uuidv7-value">
+<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-creating-a-uuidv7-value" class="section-name selfRef">Creating a UUIDv7 Value</a>
+        </h3>
+<span id="name-uuidv7-function-in-c"></span><figure id="figure-7">
+          <div class="alignLeft art-text artwork" id="appendix-A.2-1.1">
+<pre>
+#include &lt;stdio.h&gt;
+#include &lt;stdlib.h&gt;
+#include &lt;stdint.h&gt;
+#include &lt;string.h&gt;
+#include &lt;time.h&gt;
+
+// ...
+
+// csprng data source
+FILE *rndf;
+rndf = fopen("/dev/urandom", "r");
+if (rndf == 0) {
+        printf("fopen /dev/urandom error\n");
+        return 1;
+}
+
+// ...
+
+// generate one UUIDv7
+uint8_t u[16];
+struct timespec ts;
+int ret;
+
+ret = clock_gettime(CLOCK_REALTIME, &amp;ts);
+if (ret != 0) {
+        printf("clock_gettime error: %d\n", ret);
+        return 1;
+}
+
+uint64_t tms;
+
+tms = ((uint64_t)ts.tv_sec) * 1000;
+tms += ((uint64_t)ts.tv_nsec) / 1000000;
+
+printf("tms: %lld\n", tms);
+
+memset(u, 0, 16);
+
+fread(&amp;u[6], 10, 1, rndf); // fill everything after the timestamp with random bytes
+
+*((uint64_t*)(u)) |= htonll(tms &lt;&lt; 16); // shift time into first 48 bits and OR into place
+
+u[8] = 0xE7; // set var-ver field
+</pre>
+</div>
+<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
+<a href="#name-uuidv7-function-in-c" class="selfRef">UUIDv7 Function in C</a>
+          </figcaption></figure>
+</section>
+</div>
+<div id="creating_a_uuidv8_value">
+<section id="appendix-A.3">
+        <h3 id="name-creating-a-uuidv7-value-2">
+<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-creating-a-uuidv7-value-2" class="section-name selfRef">Creating a UUIDv7 Value</a>
+        </h3>
+<p id="appendix-A.3-1">UUIDv8 will vary greatly from implementation to implementation. A good candidate use case for UUIDv8 is to embed exotic timestamps like the one found in this example which employs approximately 0.25 milliseconds and approximately 5 microseconds per timestamp tick as a 48 bit value.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
+<span id="name-uuid8-function-in-c"></span><figure id="figure-8">
+          <div class="alignLeft art-text artwork" id="appendix-A.3-2.1">
+<pre>
+#include &lt;stdint.h&gt;
+#include &lt;stdio.h&gt;
+#include &lt;time.h&gt;
+
+int main() {
+  struct timespec tp;
+  clock_gettime(CLOCK_REALTIME, &amp;tp);
+  uint64_t timestamp = (uint64_t)tp.tv_sec &lt;&lt; 12;
+
+  // compute 12-bit (~0.25 msec precision) fraction from nsecs
+  timestamp |= ((uint64_t)tp.tv_nsec &lt;&lt; 12) / 1000000000;
+
+  printf("%08llx-%04llx\n", timestamp &gt;&gt; 16, timestamp &amp; 0xFFFF);
+  return 0;
+}
+</pre>
+</div>
+<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
+<a href="#name-uuid8-function-in-c" class="selfRef">UUID8 Function in C</a>
+          </figcaption></figure>
+</section>
+</div>
+</section>
+</div>
+<div id="test_vectors">
+<section id="appendix-B">
+      <h2 id="name-test-vectors">
+<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-test-vectors" class="section-name selfRef">Test Vectors</a>
+      </h2>
+<p id="appendix-B-1">Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00<a href="#appendix-B-1" class="pilcrow">¶</a></p>
+<p id="appendix-B-2">Both UUIDv1 and UUIDv6 utilize the same values in clk_seq_hi_res, clock_seq_low, and node. All of which have been generated with random data.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
+<span id="name-test-vector-timestamp-pseud"></span><figure id="figure-9">
+        <div class="alignLeft art-text artwork" id="appendix-B-3.1">
+<pre>
+# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
+gregorian_100_ns = (unix_64_bit_nanoseconds / 100) + gregorian_unix_offset
+
+# 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.
+# gregorian_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_nanoseconds = 0x16D6320C3D4DCC00 or 1645557742000000000
+
+# Work:
+# gregorian_100_ns = (1645557742000000000 / 100) + 122192928000000000
+# (138648505420000000 - 122192928000000000) * 100 = unix_64_bit_nanoseconds
+
+# Final:
+# gregorian_100_ns = 0x1EC9414C232AB00 or 138648505420000000
+
+# Original: 000111101100100101000001010011000010001100101010101100000000
+# UUIDv1:   11000010001100101010101100000000|1001010000010100|0001|000111101100
+# UUIDv6:   00011110110010010100000101001100|0010001100101010|0110|101100000000
+</pre>
+</div>
+<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
+<a href="#name-test-vector-timestamp-pseud" class="selfRef">Test Vector Timestamp Pseudo-code</a>
+        </figcaption></figure>
+<div id="uuidv6_example">
+<section id="appendix-B.1">
+        <h3 id="name-example-of-a-uuidv6-value">
+<a href="#appendix-B.1" class="section-number selfRef">B.1. </a><a href="#name-example-of-a-uuidv6-value" class="section-name selfRef">Example of a UUIDv6 Value</a>
+        </h3>
+<span id="name-uuidv1-example-test-vector"></span><figure id="figure-10">
+          <div class="alignLeft art-text artwork" id="appendix-B.1-1.1">
+<pre>
+----------------------------------------------
+field                 bits    value_hex
+----------------------------------------------
+time_low              32      0xC232AB00
+time_mid              16      0x9414
+time_hi_and_version   16      0x11EC
+clk_seq_hi_res         8      0xB3
+clock_seq_low          8      0xC8
+node                  48      0x9E6BDECED846
+----------------------------------------------
+total                128
+----------------------------------------------
+final_hex: C232AB00-9414-11EC-B3C8-9E6BDECED846
+</pre>
+</div>
+<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
+<a href="#name-uuidv1-example-test-vector" class="selfRef">UUIDv1 Example Test Vector</a>
+          </figcaption></figure>
+<span id="name-uuidv6-example-test-vector"></span><figure id="figure-11">
+          <div class="alignLeft art-text artwork" id="appendix-B.1-2.1">
+<pre>
+-----------------------------------------------
+field                 bits    value_hex
+-----------------------------------------------
+time_high              32      0x1EC9414C
+time_mid               16      0x232A
+time_low_and_version   16      0x6B00
+clk_seq_hi_res          8      0xB3
+clock_seq_low           8      0xC8
+node                   48      0x9E6BDECED846
+-----------------------------------------------
+total                 128
+-----------------------------------------------
+final_hex: 1EC9414C-232A-6B00-B3C8-9E6BDECED846
+</pre>
+</div>
+<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
+<a href="#name-uuidv6-example-test-vector" class="selfRef">UUIDv6 Example Test Vector</a>
+          </figcaption></figure>
+</section>
+</div>
+<div id="uuidv7_example">
+<section id="appendix-B.2">
+        <h3 id="name-example-of-a-uuidv7-value">
+<a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-example-of-a-uuidv7-value" class="section-name selfRef">Example of a UUIDv7 Value</a>
+        </h3>
+<p id="appendix-B.2-1">This example UUIDv7 test vector utilizes a well-known 32-bit unix epoch with additional millisecond precision to fill the first 48 bits<a href="#appendix-B.2-1" class="pilcrow">¶</a></p>
+<p id="appendix-B.2-2">rand_a and rand_b are filled with random data.<a href="#appendix-B.2-2" class="pilcrow">¶</a></p>
+<p id="appendix-B.2-3">The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00 represented as 0x17F21CFD130 or 1645539742000<a href="#appendix-B.2-3" class="pilcrow">¶</a></p>
+<span id="name-uuidv7-example-test-vector"></span><figure id="figure-12">
+          <div class="alignLeft art-text artwork" id="appendix-B.2-4.1">
+<pre>
+-------------------------------
+field      bits    value
+-------------------------------
+unix_ts_ms   48    0x017F21CFD130
+rand_a       16    0xF8B8
+var_ver       8    0xE7
+rand_b       56    0xD6A139DC9535C5
+-------------------------------
+total        128
+-------------------------------
+final: 017F21CF-D130-F8B8-E7D6-A139DC9535C5
+</pre>
+</div>
+<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
+<a href="#name-uuidv7-example-test-vector" class="selfRef">UUIDv7 Example Test Vector</a>
+          </figcaption></figure>
+</section>
+</div>
+<div id="uuidv8_example">
+<section id="appendix-B.3">
+        <h3 id="name-example-of-a-uuidv8-value">
+<a href="#appendix-B.3" class="section-number selfRef">B.3. </a><a href="#name-example-of-a-uuidv8-value" class="section-name selfRef">Example of a UUIDv8 Value</a>
+        </h3>
+<p id="appendix-B.3-1">This example UUIDv8 test vector utilizes a well-known 64-bit unix epoch with nanosecond precision to fill the first 64 bits through ver_var.<a href="#appendix-B.3-1" class="pilcrow">¶</a></p>
+<p id="appendix-B.3-2">The final 56 bits are filled with random data.<a href="#appendix-B.3-2" class="pilcrow">¶</a></p>
+<p id="appendix-B.3-3">Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 represented as 0x16D6320C3D4DCC00 or 1645557742000000000<a href="#appendix-B.3-3" class="pilcrow">¶</a></p>
+<p id="appendix-B.3-4">It should be noted that this example is just to illustrate one scenario for UUIDv8. Test vectors will likely be implementation specific and vary greatly from this simple example.<a href="#appendix-B.3-4" class="pilcrow">¶</a></p>
+<span id="name-uuidv8-example-test-vector"></span><figure id="figure-13">
+          <div class="alignLeft art-text artwork" id="appendix-B.3-5.1">
+<pre>
+-------------------------------
+field      bits    value
+-------------------------------
+custom_a     64    0x16D6320C3D4DCC00
+var_ver       8    0xE8
+custom_b     56    0x3C2D06302FC417
+-------------------------------
+total        128
+-------------------------------
+final: 16D6320C-3D4D-CC00-E83C-2D06302FC417
+</pre>
+</div>
+<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
+<a href="#name-uuidv8-example-test-vector" class="selfRef">UUIDv8 Example Test Vector</a>
+          </figcaption></figure>
+</section>
+</div>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="appendix-C">
       <h2 id="name-authors-addresses">
 <a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
       </h2>
diff --git a/draft-peabody-dispatch-new-uuid-format-03.txt b/draft-peabody-dispatch-new-uuid-format-03.txt
index 4a8154c..10adf09 100644
--- a/draft-peabody-dispatch-new-uuid-format-03.txt
+++ b/draft-peabody-dispatch-new-uuid-format-03.txt
@@ -5,8 +5,8 @@
 dispatch                                                    BGP. Peabody
 Internet-Draft                                                          
 Updates: 4122 (if approved)                                     K. Davis
-Intended status: Standards Track                         1 February 2022
-Expires: 5 August 2022
+Intended status: Standards Track                        28 February 2022
+Expires: 1 September 2022
 
 
                             New UUID Formats
@@ -14,8 +14,8 @@ Expires: 5 August 2022
 
 Abstract
 
-   This document presents new time-based UUID formats which are suited
-   for use as a database key.
+   This document presents three new Universally Unique Identifier (UUID)
+   formats.
 
    A common case for modern applications is to create a unique
    identifier for use as a primary key in a database table.  This
@@ -43,7 +43,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 5 August 2022.
+   This Internet-Draft will expire on 1 September 2022.
 
 Copyright Notice
 
@@ -53,7 +53,7 @@ Copyright Notice
 
 
 
-Peabody & Davis           Expires 5 August 2022                 [Page 1]
+Peabody & Davis         Expires 1 September 2022                [Page 1]
 
 Internet-Draft               new-uuid-format               February 2022
 
@@ -69,58 +69,62 @@ Internet-Draft               new-uuid-format               February 2022
 
 Table of Contents
 
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
+     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   5
    3.  Summary of Changes  . . . . . . . . . . . . . . . . . . . . .   5
-     3.1.  changelog . . . . . . . . . . . . . . . . . . . . . . . .   6
-   4.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-     4.1.  Versions  . . . . . . . . . . . . . . . . . . . . . . . .   7
-     4.2.  Variant . . . . . . . . . . . . . . . . . . . . . . . . .   7
-     4.3.  UUIDv6 Layout and Bit Order . . . . . . . . . . . . . . .   7
-       4.3.1.  UUIDv6 Basic Creation Algorithm . . . . . . . . . . .   9
-     4.4.  UUIDv7 Layout and Bit Order . . . . . . . . . . . . . . .  10
-       4.4.1.  UUIDv7 Timestamp Usage  . . . . . . . . . . . . . . .  11
-       4.4.2.  UUIDv7 Clock Sequence Usage . . . . . . . . . . . . .  12
-       4.4.3.  UUIDv7 Node Usage . . . . . . . . . . . . . . . . . .  12
-       4.4.4.  UUIDv7 Encoding and Decoding  . . . . . . . . . . . .  12
-     4.5.  UUIDv8 Layout and Bit Order . . . . . . . . . . . . . . .  17
-       4.5.1.  UUIDv8 Timestamp Usage  . . . . . . . . . . . . . . .  19
-       4.5.2.  UUIDv8 Clock Sequence Usage . . . . . . . . . . . . .  20
-       4.5.3.  UUIDv8 Node Usage . . . . . . . . . . . . . . . . . .  21
-       4.5.4.  UUIDv8 Basic Creation Algorithm . . . . . . . . . . .  21
-   5.  Encoding and Storage  . . . . . . . . . . . . . . . . . . . .  24
-   6.  Global Uniqueness . . . . . . . . . . . . . . . . . . . . . .  25
-   7.  Distributed UUID Generation . . . . . . . . . . . . . . . . .  25
-   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
-   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
-   11. Normative References  . . . . . . . . . . . . . . . . . . . .  26
-   12. Informative References  . . . . . . . . . . . . . . . . . . .  26
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
-
-1.  Introduction
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-Peabody & Davis           Expires 5 August 2022                 [Page 2]
+     3.1.  changelog . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.1.  Variant and Version Fields  . . . . . . . . . . . . . . .   7
+     4.2.  UUID Version 6  . . . . . . . . . . . . . . . . . . . . .   9
+     4.3.  UUID Version 7  . . . . . . . . . . . . . . . . . . . . .  11
+     4.4.  UUID Version 8  . . . . . . . . . . . . . . . . . . . . .  12
+   5.  UUID Best Practices . . . . . . . . . . . . . . . . . . . . .  13
+     5.1.  Timestamp Granularity . . . . . . . . . . . . . . . . . .  13
+     5.2.  Monotonicity and Counters . . . . . . . . . . . . . . . .  14
+     5.3.  Distributed UUID Generation . . . . . . . . . . . . . . .  16
+     5.4.  Collision Resistance  . . . . . . . . . . . . . . . . . .  17
+     5.5.  Global and Local Uniqueness . . . . . . . . . . . . . . .  17
+     5.6.  Unguessability  . . . . . . . . . . . . . . . . . . . . .  18
+     5.7.  Sorting . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     5.8.  Storing UUIDs, Opacity  . . . . . . . . . . . . . . . . .  18
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
+   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  19
+   10. Informative References  . . . . . . . . . . . . . . . . . . .  20
+   Appendix A.  Example Code . . . . . . . . . . . . . . . . . . . .  21
+     A.1.  Creating a UUIDv6 Value . . . . . . . . . . . . . . . . .  21
+     A.2.  Creating a UUIDv7 Value . . . . . . . . . . . . . . . . .  22
+     A.3.  Creating a UUIDv7 Value . . . . . . . . . . . . . . . . .  24
+   Appendix B.  Test Vectors . . . . . . . . . . . . . . . . . . . .  24
+     B.1.  Example of a UUIDv6 Value . . . . . . . . . . . . . . . .  25
+     B.2.  Example of a UUIDv7 Value . . . . . . . . . . . . . . . .  26
+     B.3.  Example of a UUIDv8 Value . . . . . . . . . . . . . . . .  26
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27
+
+
+
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 2]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-2.  Background
+1.  Introduction
 
-   A lot of things have changed in the time since UUIDs were originally
-   created.  Modern applications have a need to use (and many have
-   already implemented) UUIDs as database primary keys.
+   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 primary
+   keys, file names, machine or system names, identifiers for
+   transactions or other objects or processes.
 
-   The motivation for using UUIDs as database keys stems primarily from
+   A specific use case for UUIDs which has gained popularity is as
+   database primary keys.  The motivation for this stems primarily from
    the fact that applications are increasingly distributed in nature.
    Simplistic "auto increment" schemes with integers in sequence do not
    work well in a distributed system since the effort required to
@@ -129,35 +133,31 @@ Internet-Draft               new-uuid-format               February 2022
    values in distributed systems without requiring synchronization makes
    them a good candidate for use as a database key in such environments.
 
-   However some properties of [RFC4122] UUIDs are not well suited to
-   this task.  First, most of the existing UUID versions such as UUIDv4
-   have poor database index locality.  Meaning new values created in
-   succession are not close to each other in the index and thus require
-   inserts to be performed at random locations.  The negative
-   performance effects of which on common structures used for this
-   (B-tree and its variants) can be dramatic.  As such newly inserted
-   values SHOULD be time-ordered to address this.
-
-   While it is true that UUIDv1 does contain an embedded timestamp and
-   can be time-ordered; UUIDv1 has other issues.  It is possible to sort
-   Version 1 UUIDs by time but it is a laborious task.  The process
-   requires breaking the bytes of the UUID into various pieces, re-
-   ordering the bits, and then determining the order from the
-   reconstructed timestamp.  This is not efficient in very large
-   systems.  Implementations would be simplified with a sort order where
-   the UUID can simply be treated as an opaque sequence of bytes and
-   ordered as such.
+   UUID versions 1 through 5 lack certain desirable characteristics in
+   some circumstances:
 
-   After the embedded timestamp, the remaining 64 bits are in essence
-   used to provide uniqueness both on a global scale and within a given
-   timestamp tick.  The clock sequence value ensures that when multiple
-   UUIDs are generated for the same timestamp value are given a
-   monotonic sequence value.  This explicit sequencing helps further
-   facilitate sorting.  The remaining random bits ensure collisions are
-   minimal.
+   1.  Non-time-ordered UUID versions such as UUIDv4 have poor database
+       index locality.  Meaning new values created in succession are not
+       close to each other in the index and thus require inserts to be
+       performed at random locations.  The negative performance effects
+       of which on common structures used for this (B-tree and its
+       variants) can be dramatic.
 
+   2.  The 100-nanosecond, Gregorian epoch used in UUIDv1 timestamps is
+       uncommon and difficult to represent accurately using a standard
+       number format such as [IEEE754].
 
+   3.  Introspection/parsing is required to order by time sequence; as
+       opposed to being able to perform a simple byte-by-byte
+       comparison.
 
+   4.  Privacy and network security issues arise from using a MAC
+       address in the node field of Version 1 UUIDs.  Exposed MAC
+       addresses can be used as an attack surface to locate machines and
+       reveal various other information about such machines (minimally
+       manufacturer, potentially other details).  Additionally, with the
+       advent of virtual machines and containers, MAC address uniqueness
+       is no longer guaranteed.
 
 
 
@@ -165,34 +165,26 @@ Internet-Draft               new-uuid-format               February 2022
 
 
 
-Peabody & Davis           Expires 5 August 2022                 [Page 3]
+Peabody & Davis         Expires 1 September 2022                [Page 3]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   Furthermore, UUIDv1 utilizes a non-standard timestamp epoch derived
-   from the Gregorian Calendar.  More specifically, the Coordinated
-   Universal Time (UTC) as a count of 100-nanosecond intervals since
-   00:00:00.00, 15 October 1582.  Implementations and many languages may
-   find it easier to implement the widely adopted and well known Unix
-   Epoch, a custom epoch, or another timestamp source with various
-   levels of timestamp precision required by the application.
-
-   Lastly, privacy and network security issues arise from using a MAC
-   address in the node field of Version 1 UUIDs.  Exposed MAC addresses
-   can be used as an attack surface to locate machines and reveal
-   various other information about such machines (minimally
-   manufacturer, potentially other details).  Instead "cryptographically
-   secure" pseudo-random number generators (CSPRNGs) or pseudo-random
-   number generators (PRNG) SHOULD be used within an application context
-   to provide uniqueness and unguessability.
-
-   Due to the shortcomings of UUIDv1 and UUIDv4 details so far, 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 lead to numerous implementations over the past 10+ years solving
-   the same problem in slightly different ways.
+   5.  Many implementation details are specified in [RFC4122] but some
+       of the decisions made involve trade offs that are neither
+       possible to specify for all applications nor necessary to produce
+       interoperable implementations.
+
+   6.  The previous specification also does not distinguish between the
+       requirements for generation of a UUID versus an application which
+       simply stores one, which are different.
+
+   Due to the aforementioned issue, 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 lead to numerous implementations
+   over the past 10+ years solving the same problem in slightly
+   different ways.
 
    While preparing this specification the following 16 different
    implementations were analyzed for trends in total ID length, bit
@@ -200,92 +192,114 @@ Internet-Draft               new-uuid-format               February 2022
    format, timestamp accuracy, node format/components, collision
    handling and multi-timestamp tick generation sequencing.
 
-   1.   [LexicalUUID] by Twitter
-   2.   [Snowflake] by Twitter
-   3.   [Flake] by Boundary
-   4.   [ShardingID] by Instagram
-   5.   [KSUID] by Segment
-   6.   [Elasticflake] by P.  Pearcy
-   7.   [FlakeID] by T.  Pawlak
-   8.   [Sonyflake] by Sony
-   9.   [orderedUuid] by IT.  Cabrera
-   10.  [COMBGUID] by R.  Tallent
-   11.  [ULID] by A.  Feerasta
+   1.   [ULID] by A.  Feerasta
+   2.   [LexicalUUID] by Twitter
+   3.   [Snowflake] by Twitter
+   4.   [Flake] by Boundary
+   5.   [ShardingID] by Instagram
+   6.   [KSUID] by Segment
+   7.   [Elasticflake] by P.  Pearcy
+   8.   [FlakeID] by T.  Pawlak
+   9.   [Sonyflake] by Sony
+   10.  [orderedUuid] by IT.  Cabrera
+   11.  [COMBGUID] by R.  Tallent
    12.  [SID] by A.  Chilton
    13.  [pushID] by Google
    14.  [XID] by O.  Poitrey
    15.  [ObjectID] by MongoDB
    16.  [CUID] by E.  Elliott
 
+   An inspection of these implementations and the issues described above
+   has led to this document which attempts to adapt UUIDs to address
+   these issues.
+
+2.  Terminology
+
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                 [Page 4]
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 4]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   An inspection of these implementations details the following trends
-   that help define this standard:
-
-      - Timestamps MUST be k-sortable.  That is, values within or close
-      to the same timestamp are ordered properly by sorting algorithms.
-      - Timestamps SHOULD be big-endian with the most-significant bits
-      of the time embedded as-is without reordering.
-      - Timestamps SHOULD utilize millisecond precision and Unix Epoch
-      as timestamp source.  Although, there is some variation to this
-      among implementations depending on the application requirements.
-      - The ID format SHOULD be Lexicographically sortable while in the
-      textual representation.
-      - IDs MUST ensure proper embedded sequencing to facilitate sorting
-      when multiple UUIDs are created during a given timestamp.
-      - IDs MUST NOT require unique network identifiers as part of
-      achieving uniqueness.
-      - Distributed nodes MUST be able to create collision resistant
-      Unique IDs without consulting a centralized resource.
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.2.  Abbreviations
+
+   The following abbreviations are used in this document:
+
+   UUID          Universally Unique Identifier [RFC4122]
+
+   CSPRNG        Cryptographically Secure Pseudo-Random Number Generator
+
+   MAC           Media Access Control
+
+   MSB           Most Significant Bit
 
 3.  Summary of Changes
 
-   In order to solve these challenges this specification introduces
-   three new version identifiers assigned for time-based UUIDs.
-
-   The first, UUIDv6, aims to be the easiest to implement for
-   applications which already implement UUIDv1.  The UUIDv6
-   specification keeps the original Gregorian timestamp source but does
-   not reorder the timestamp bits as per the process utilized by UUIDv1.
-   UUIDv6 also requires that pseudo-random data MUST be used in place of
-   the MAC address.  The rest of the UUIDv1 format remains unchanged in
-   UUIDv6.  See Section 4.3
-
-   Next, UUIDv7 introduces an entirely new time-based UUID bit layout
-   utilizing a variable length timestamp sourced from the widely
-   implemented and well known Unix Epoch timestamp source.  The
-   timestamp is broken into a 36 bit integer sections part, and is
-   followed by a field of variable length which represents the sub-
-   second timestamp portion, encoded so that each bit from most to least
-   significant adds more precision.  See Section 4.4
-
-   Finally, UUIDv8 introduces a relaxed time-based UUID format that
-   caters to application implementations that cannot utilize UUIDv1,
-   UUIDv6, or UUIDv7.  UUIDv8 also future-proofs this specification by
-   allowing time-based UUID formats from timestamp sources that are not
-   yet be defined.  The variable size timestamp offers lots of
-   flexibility to create an implementation specific RFC compliant time-
-   based UUID while retaining the properties that make UUID great.  See
-   Section 4.5
-
-
-
-Peabody & Davis           Expires 5 August 2022                 [Page 5]
-
-Internet-Draft               new-uuid-format               February 2022
+   The following UUIDs are hereby introduced:
 
+   1.  UUID version 6: A re-ordering of UUID version 1 so it is sortable
+       as an opaque sequence of bytes.  Easy to implement given an
+       existing UUIDv1 implementation.  See Section 4.2
+   2.  UUID version 7: An entirely new time-based UUID bit layout
+       sourced from the widely implemented and well known Unix Epoch
+       timestamp source.  See Section 4.3
+   3.  UUID version 8: A free-form UUID format which has no explicit
+       requirements except maintaining backward compatibility.  See
+       Section 4.4
 
 3.1.  changelog
 
    RFC EDITOR PLEASE DELETE THIS SECTION.
 
+   draft-03
+
+      - Reworked the draft body to make the content more concise
+      - UUIDv6 section reworked to just the reorder of the timestamp
+      - UUIDv7 changed to simplify timestamp mechanism to just
+      millisecond unix timestamp
+      - UUIDv8 relaxed to be custom in all elements except version and
+      variant
+      - Changed UUIDv7 and UUIDv8 to use Variant 111.
+      - Added C code samples in Appendix.
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 5]
+
+Internet-Draft               new-uuid-format               February 2022
+
+
+      - Added test vectors in Appendix.
+      - Version and Variant section combined into one section.
+      - Changed from pseudo-random number generators to
+      cryptographically secure pseudo-random number generator (CSPRNG).
+      - Split Encoding and Storage section into more sections: Text
+      Format and Storing UUIDs, Opacity
+      - Reworked Global Uniqueness under new section Global and Local
+      Uniqueness
+      - Combined redundant topics from all UUIDs into sections such as
+      Timestamp granularity, Monotonicity and Counters, Collision
+      Resistance, Sorting, and Unguessability, etc.
+      - Node verbiage only used in UUIDv6 and v7 and v8 reference random
+      instead
+      - Clock sequence verbiage changed simply to counter in any section
+      other than UUIDv6
+      - Added Abbreviations section
+      - Updated IETF Draft XML Layout
+
    draft-02
 
       - Added Changelog
@@ -294,7 +308,7 @@ Internet-Draft               new-uuid-format               February 2022
       - Fixed some UUIDvX reference issues
       - Changed all instances of "motonic" to "monotonic"
       - Changed all instances of "#-bit" to "# bit"
-      - Changed "proceeding" veriage to "after" in section 7
+      - Changed "proceeding" verbiage to "after" in section 7
       - Added details on how to pad 32 bit unix timestamp to 36 bits in
       UUIDv7
       - Added details on how to truncate 64 bit unix timestamp to 36
@@ -312,6 +326,18 @@ Internet-Draft               new-uuid-format               February 2022
       standards.
       - Removed the topics of UUID length modification, alternate UUID
       text formats, and alternate UUID encoding techniques.
+
+
+
+
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 6]
+
+Internet-Draft               new-uuid-format               February 2022
+
+
       - Research into 16 different historical and current
       implementations of time-based universal identifiers was completed
       at the end of 2020 in attempt to identify trends which have
@@ -323,84 +349,162 @@ Internet-Draft               new-uuid-format               February 2022
 
 4.  Format
 
-   The UUID length of 16 octets (128 bits) remains unchanged.  The
-   textual representation of a UUID consisting of 36 hexadecimal and
-   dash characters in the format 8-4-4-4-12 remains unchanged for human
-   readability.  In addition the position of both the Version and
-   Variant bits remain unchanged in the layout.
+   The UUID format is 16 octets; some bits of the eight octet variant
+   field specified below determine finer structure.
+
+4.1.  Variant and Version Fields
+
+   The variant bits utilized by UUIDs in this specification remain in
+   the same octet as originally defined by [RFC4122], Section 4.1.1.
 
+   For UUIDv6 the version and variant field placement from [RFC4122] are
+   unchanged and a new version (0110b [6]) has been added.
 
+   00000000-0000-6000-8000-000000000000
+   00000000-0000-6000-9000-000000000000
+   00000000-0000-6000-A000-000000000000
+   00000000-0000-6000-B000-000000000000
+   xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
 
+               Figure 1: UUIDv6 Version and Variant Examples
 
+   M:  Version (0110b [6])
 
-Peabody & Davis           Expires 5 August 2022                 [Page 6]
+   N:  Variant (1000b [8], 1001b [9], 1010b [A] or 1011b [B]) are all
+      valid values
+
+   For UUID versions 7 and 8, the variant field has been incremented and
+   the version field has been moved to the same octet as the variant.
+   Since the bits of the variant remain in the same place as described
+   in [RFC4122] but utilized the previously reserved value 111, this
+   allows a UUID to simply define octet 8 as var_ver, and the values
+   0xE7 and 0xE8 indicate UUID versions 7 and 8 respectively.
+
+   00000000-0000-0000-E700-000000000000
+   xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+
+   00000000-0000-0000-E800-000000000000
+   xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 7]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-4.1.  Versions
+               Figure 2: UUIDv7 Version and Variant Examples
+
+   N:  Variant (1110b [E])
+
+   M:  Version (0111b [7] or 1000 [8])
+
+   While this specification makes use of the unused variant bits of 111
+   defined in [RFC4122], Section 4.1.1; the placement of the version
+   within the same octet as the variant leaves room for a future
+   variant.
+
+   UUID Version 7 and 8 specified by this document MUST set the first 3
+   bits of octet 8 to 111 and the fourth bit to 0.  The 4 bit version
+   MUST follow the variant to fill out the final bits of octet 8.
+
+   Future specifications that wish to utilize variant 111 for a
+   different version position (or any other bit layout position) MUST
+   set the first 3 bits of octet 8 to 111 and then the fourth bit to 1.
+
+   As such the tables below detail the three variants and versions
+   described in this document where the letter "x" indicates a
+   "don't-care" value.
 
-   Table 1 defines the 4 bit version found in Bits 48 through 51 within
-   a given UUID.
+    +------+------+------+------+-------------------------------------+
+    | Msb0 | Msb1 | Msb2 | Msb3 | Description                         |
+    +------+------+------+------+-------------------------------------+
+    | 1    | 0    | x    | x    | The variant specified by [RFC4122]. |
+    |      |      |      |      | Hex characters 8, 9, A, B.          |
+    +------+------+------+------+-------------------------------------+
+    | 1    | 1    | 1    | 0    | The variant specified in this       |
+    |      |      |      |      | document.  Hex character E,         |
+    +------+------+------+------+-------------------------------------+
+    | 1    | 1    | 1    | 1    | Reserved for future definition.     |
+    |      |      |      |      | Hex Character F.                    |
+    +------+------+------+------+-------------------------------------+
 
-      +------+------+------+------+---------+-----------------------+
-      | Msb0 | Msb1 | Msb2 | Msb3 | Version | Description           |
-      +------+------+------+------+---------+-----------------------+
-      | 0    | 1    | 1    | 0    | 6       | Reordered Gregorian   |
-      |      |      |      |      |         | time-based UUID       |
-      +------+------+------+------+---------+-----------------------+
-      | 0    | 1    | 1    | 1    | 7       | Variable length Unix  |
-      |      |      |      |      |         | Epoch time-based UUID |
-      +------+------+------+------+---------+-----------------------+
-      | 1    | 0    | 0    | 0    | 8       | Custom time-based     |
-      |      |      |      |      |         | UUID                  |
-      +------+------+------+------+---------+-----------------------+
+            Table 1: UUID Variant defined by this specification
 
-            Table 1: UUID versions defined by this specification
 
-4.2.  Variant
 
-   The variant bits utilized by UUIDs in this specification remains the
-   same as [RFC4122], Section 4.1.1.
 
-   The Table 2 lists the contents of the variant field, bits 64 and 65,
-   where the letter "x" indicates a "don't-care" value.  Common hex
-   values of 8 (1000), 9 (1001), A (1010), and B (1011) frequent the
-   text representation.
 
-     +------+------+------+-----------------------------------------+
-     | Msb0 | Msb1 | Msb2 | Description                             |
-     +------+------+------+-----------------------------------------+
-     | 1    | 0    | x    | The variant specified in this document. |
-     +------+------+------+-----------------------------------------+
 
-           Table 2: UUID Variant defined by this specification
 
-4.3.  UUIDv6 Layout and Bit Order
 
-   UUIDv6 aims to be the easiest to implement by reusing most of the
-   layout of bits found in UUIDv1 but with changes to bit ordering for
-   the timestamp.  Where UUIDv1 splits the timestamp bits into three
-   distinct parts and orders them as time_low, time_mid,
-   time_high_and_version.  UUIDv6 instead keeps the source bits from the
-   timestamp intact and changes the order to time_high, time_mid, and
-   time_low.  Incidentally this will match the original 60 bit Gregorian
-   timestamp source with 100-nanosecond precision defined in [RFC4122],
 
 
 
-Peabody & Davis           Expires 5 August 2022                 [Page 7]
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 8]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   Section 4.1.4 The clock sequence bits remain unchanged from their
-   usage and position in [RFC4122], Section 4.1.5.  The 48 bit node
-   SHOULD be set to a pseudo-random value however implementations MAY
-   choose retain the old MAC address behavior from [RFC4122],
-   Section 4.1.6 and [RFC4122], Section 4.5
+       +------+------+------+------+---------+---------------------+
+       | Msb0 | Msb1 | Msb2 | Msb3 | Version | Description         |
+       +------+------+------+------+---------+---------------------+
+       | 0    | 1    | 1    | 0    | 6       | Reordered Gregorian |
+       |      |      |      |      |         | time-based UUID     |
+       +------+------+------+------+---------+---------------------+
+       | 0    | 1    | 1    | 1    | 7       | Unix Epoch time-    |
+       |      |      |      |      |         | based UUID          |
+       +------+------+------+------+---------+---------------------+
+       | 1    | 0    | 0    | 0    | 8       | Custom UUID         |
+       +------+------+------+------+---------+---------------------+
+
+            Table 2: UUID versions defined by this specification
+
+4.2.  UUID Version 6
+
+   UUID version 6 is a field-compatible version of UUIDv1, reordered for
+   improved DB locality.  It is expected that UUIDv6 will primarily be
+   used in contexts where there are existing v1 UUIDs.  Systems that do
+   not involve legacy UUIDv1 SHOULD consider using UUIDv7 instead.
+
+   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
+   timestamp value as specified for UUIDv1 in [RFC4122], Section 4.1.4,
+   for UUIDv6, the first 48 most significant bits are stored first,
+   followed by the 4 bit version (same position), followed by the
+   remaining 12 bits of the original 60 bit timestamp.
+
+   The clock sequence bits remain unchanged from their usage and
+   position in [RFC4122], Section 4.1.5.
+
+   The 48 bit node SHOULD be set to a pseudo-random value however
+   implementations MAY choose retain the old MAC address behavior from
+   [RFC4122], Section 4.1.6 and [RFC4122], Section 4.5.  For more
+   information on MAC address usage within UUIDs see the Section 7
+
+   The format for the 16-byte, 128 bit UUIDv6 is shown in Figure 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peabody & Davis         Expires 1 September 2022                [Page 9]
+
+Internet-Draft               new-uuid-format               February 2022
 
-   The format for the 16-octet, 128 bit UUIDv6 is shown in Figure 1
 
         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
@@ -414,7 +518,7 @@ Internet-Draft               new-uuid-format               February 2022
        |                         node (2-5)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-                   Figure 1: UUIDv6 Field and Bit Layout
+                   Figure 3: UUIDv6 Field and Bit Layout
 
    time_high:
       The most significant 32 bits of the 60 bit starting timestamp.
@@ -443,78 +547,21 @@ Internet-Draft               new-uuid-format               February 2022
       48 bit spatially unique identifier Occupies bits 80 through 127
       (octets 10-15)
 
-
-
-Peabody & Davis           Expires 5 August 2022                 [Page 8]
-
-Internet-Draft               new-uuid-format               February 2022
-
-
-4.3.1.  UUIDv6 Basic Creation Algorithm
-
-   The following implementation algorithm is based on [RFC4122] but with
-   changes specific to UUIDv6:
-
-   1.   From a system-wide shared stable store (e.g., a file) or global
-        variable, read the UUID generator state: the values of the
-        timestamp and clock sequence used to generate the last UUID.
-
-   2.   Obtain the current time as a 60 bit count of 100-nanosecond
-        intervals since 00:00:00.00, 15 October 1582.
-
-   3.   Set the time_low field to the 12 least significant bits of the
-        starting 60 bit timestamp.
-
-   4.   Truncate the timestamp to the 48 most significant bits in order
-        to create time_high_and_time_mid.
-
-   5.   Set the time_high field to the 32 most significant bits of the
-        truncated timestamp.
-
-   6.   Set the time_mid field to the 16 least significant bits of the
-        truncated timestamp.
-
-   7.   Create the 16 bit time_low_and_version by concatenating the 4
-        bit UUIDv6 version with the 12 bit time_low.
-
-   8.   If the state was unavailable (e.g., non-existent or corrupted)
-        or the timestamp is greater than the current timestamp generate
-        a random 14 bit clock sequence value.
-
-   9.   If the state was available, but the saved timestamp is less than
-        or equal to the current timestamp, increment the clock sequence
-        value.
-
-   10.  Complete the 16 bit clock sequence high, low and reserved
-        creation by concatenating the clock sequence onto UUID variant
-        bits which take the most significant position in the 16 bit
-        value.
-
-   11.  Generate a 48 bit pseudo-random node.
-
-   12.  Format by concatenating the 128 bits from each parts:
-        time_high|time_mid|time_low_and_version|variant_clk_seq|node
-
-   13.  Save the state (current timestamp and clock sequence) back to
-        the stable store
-
+   With UUIDv6 the steps for splitting the timestamp into time_high and
+   time_mid are optional 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.  In which the following logic can be applied to
+   reshuffle the bits with minimal modifications.
 
 
 
-Peabody & Davis           Expires 5 August 2022                 [Page 9]
+Peabody & Davis         Expires 1 September 2022               [Page 10]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   The steps for splitting time_high_and_time_mid into time_high and
-   time_mid are optional since the 48 bits of time_high and time_mid
-   will remain in the same order as time_high_and_time_mid during the
-   final concatenation.  This extra step of splitting into the most
-   significant 32 bits and least significant 16 bits proves useful when
-   reusing an existing UUIDv1 implementation.  In which the following
-   logic can be applied to reshuffle the bits with minimal
-   modifications.
-
                   +--------------+------+--------------+
                   | UUIDv1 Field | Bits | UUIDv6 Field |
                   +--------------+------+--------------+
@@ -528,809 +575,761 @@ Internet-Draft               new-uuid-format               February 2022
                      Table 3: UUIDv1 to UUIDv6 Field
                                  Mappings
 
-4.4.  UUIDv7 Layout and Bit Order
-
-   The UUIDv7 format is designed to encode a Unix timestamp with
-   arbitrary sub-second precision.  The key property provided by UUIDv7
-   is that timestamp values generated by one system and parsed by
-   another are guaranteed to have sub-second precision of either the
-   generator or the parser, whichever is less.  Additionally, the system
-   parsing the UUIDv7 value does not need to know which precision was
-   used during encoding in order to function correctly.
-
-   The format for the 16-octet, 128 bit UUIDv7 is shown in Figure 2
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                            unixts                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |unixts |       subsec_a        |  ver  |       subsec_b        |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |var|                   subsec_seq_node                         |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                       subsec_seq_node                         |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                   Figure 2: UUIDv7 Field and Bit Layout
-
+4.3.  UUID Version 7
 
+   UUID version 7 features a time-ordered value field derived from the
+   widely implemented and well known Unix Epoch timestamp source, as
+   well as improved entropy characteristics over versions 1 or 6.
+   Implementations SHOULD utilize UUID version 7 over UUID version 1 and
+   6 if possible.
 
+    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           |             rand              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    var_ver    |            rand_b                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            rand_b                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-Peabody & Davis           Expires 5 August 2022                [Page 10]
-
-Internet-Draft               new-uuid-format               February 2022
-
-
-   unixts:
-      36 bit big-endian unsigned Unix Timestamp value
-
-   subsec_a:
-      12 bits allocated to sub-second precision values.
-
-   ver:
-      The 4 bit UUIDv7 version (0111)
-
-   subsec_b:
-      12 bits allocated to sub-second precision values.
-
-   var:
-      2 bit UUID variant (10)
-
-   subsec_seq_node:
-      The remaining 62 bits which MAY be allocated to any combination of
-      additional sub-second precision, sequence counter, or pseudo-
-      random data.
-
-4.4.1.  UUIDv7 Timestamp Usage
-
-   UUIDv7 utilizes a 36 bit big-endian unsigned Unix Timestamp value
-   (number of seconds since the epoch of 1 Jan 1970, leap seconds
-   excluded so each hour is exactly 3600 seconds long).  The 36 bit
-   value was selected in order to provide more available time to the
-   unix timestamp and avoid the Year 2038 problem by extending the
-   maximum timestamp to the year 4147.
-
-   To achieve a 36 bit UUIDv7 timestamp, the lower 36 bits of a 64 bit
-   unix time are extracted verbatim into UUIDv7
-
-   In the event that 32 bit Unix Timestamp are in use; four zeros MUST
-   be appended at the start in the most significant (left-most) bits of
-   the 32 bit Unix timestamp creating the 36 bit Unix timestamp.  This
-   ensures sorting compatibility with 64 bit unix timestamp which have
-   been truncated to 36 bits.
+                   Figure 4: UUIDv7 Field and Bit Layout
 
-   Additional sub-second precision (millisecond, nanosecond,
-   microsecond, etc) MAY be provided for encoding and decoding in the
-   remaining bits in the layout.
+   unix_ts_ms:
+      48 bit big-endian unsigned number of unix epoch timestamp as per
+      Section 5.1
 
-   UUIDv8 SHOULD be used in place of UUIDv7 if an application or
-   implementation does not want to truncate a 64 bit Unix Epoch to the
-   lower 36 bits.
+   rand_a:
+      16 bits pseudo-random data to provide uniqueness as per
+      Section 5.6
 
+   var_ver:
+      The 8 bit combined variant and version field with the value 0xE7
+      as defined by Section 4.1.
 
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 11]
+Peabody & Davis         Expires 1 September 2022               [Page 11]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-4.4.2.  UUIDv7 Clock Sequence Usage
+   rand_b:
+      The final 56 bits of pseudo-random data to provide uniqueness as
+      per Section 5.6 and Section 5.2.
 
-   UUIDv7 SHOULD utilize a monotonic sequence counter to provide
-   additional sequencing guarantees when multiple UUIDv7 values are
-   created in the same UNIXTS and SUBSEC timestamp.  The amount of bits
-   allocates to the sequence counter depend on the precision of the
-   timestamp.  For example, a more accurate timestamp source using
-   nanosecond precision will require less clock sequence bits than a
-   timestamp source utilizing seconds for precision.  For best
-   sequencing results the sequence counter SHOULD be placed immediately
-   after available sub-second bits.
+4.4.  UUID Version 8
 
-   The clock sequence MUST start at zero and increment monotonically for
-   each new UUIDv7 created on by the application on the same timestamp.
-   When the timestamp increments the clock sequence MUST be reset to
-   zero.  The clock sequence MUST NOT rollover or reset to zero unless
-   the timestamp has incremented.  Care MUST be given to ensure that an
-   adequate sized clock sequence is selected for a given application
-   based on expected timestamp precision and expected UUIDv7 generation
-   rates.
+   UUID version 8 provides an RFC-compatible format for experimental or
+   vendor-specific use cases.  The only requirement is that the variant
+   and version bits MUST be set as defined in Section 4.1.  UUIDv8's
+   uniqueness will be implementation-specific and should not be assumed.
 
-4.4.3.  UUIDv7 Node Usage
-
-   UUIDv7 implementations, even with very detailed sub-second precision
-   and the optional sequence counter, MAY have leftover bits that will
-   be identified as the Node for this section.  The UUIDv7 Node MAY
-   contain any set of data an implementation desires however the node
-   MUST NOT be set to all 0s which does not ensure global uniqueness.
-   In most scenarios the node SHOULD be filled with pseudo-random data.
+   UUIDv8 SHOULD only be utilized if an implementation cannot utilize
+   another UUID in this document or [RFC4122].
 
-4.4.4.  UUIDv7 Encoding and Decoding
+   The only explicitly defined bits are the Version and Variant leaving
+   120 bits for implementation specific time-based UUIDs.  To be clear:
+   UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
+   filled with random data.
 
-   The UUIDv7 bit layout for encoding and decoding are described
-   separately in this document.
+   Some example situations in which UUIDv8 usage could occur:
 
-4.4.4.1.  UUIDv7 Encoding
+   *  An implementation would like to embed extra information within the
+      UUID other than what is defined in this document.
 
-   Since the UUIDv7 Unix timestamp is fixed at 36 bits in length the
-   exact layout for encoding UUIDv7 depends on the precision (number of
-   bits) used for the sub-second portion and the sizes of the optionally
-   desired sequence counter and node bits.
+   *  An implementation has other application/language restrictions
+      which inhibit the use of one of the current UUIDs.
 
-   Three examples of UUIDv7 encoding are given below as a general
-   guidelines but implementations are not limited to just these three
-   examples.
+    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                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    var_ver    |           custom_b                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           custom_b                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
+                   Figure 5: UUIDv8 Field and Bit Layout
 
+   custom_a:
+      The first 64 bits of the layout that can be filled as an
+      implementation sees fit.
 
+   var_ver:
+      The 8 bit combined variant and version field with the value 0xE8
+      as defined by Section 4.1.
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 12]
+Peabody & Davis         Expires 1 September 2022               [Page 12]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   All of these fields are only used during encoding, and during
-   decoding the system is unaware of the bit layout used for them and
-   considers this information opaque.  As such, implementations
-   generating these values can assign whatever lengths to each field it
-   deems applicable, as long as it does not break decoding compatibility
-   (i.e.  Unix timestamp (unixts), version (ver) and variant (var) have
-   to stay where they are, and clock sequence counter (seq), random
-   (random) or other implementation specific values must follow the sub-
-   second encoding).
+   custom_b:
+      The final 56 bits of the layout immediatly following the var_var
+      field to be filled as an implementation sees fit.
 
-   In Figure 3 the UUIDv7 has been created with millisecond precision
-   with the available sub-second precision bits.
+5.  UUID Best Practices
 
-   Examining Figure 3 one can observe:
+   The minimum requirements for generating UUIDs are described in this
+   document for each version.  Everything else is an implementation
+   detail and up to the implementer to decide what is appropriate for a
+   given implementation.  That being said, various relevant factors are
+   covered below to help guide an implementer through the different
+   trade-offs among differing UUID implementations.
 
-   *  The first 36 bits have been dedicated to the Unix Timestamp
-      (unixts)
+5.1.  Timestamp Granularity
 
-   *  All 12 bits of scenario subsec_a is fully dedicated to millisecond
-      information (msec).
+   UUID timestamp source, precision and length was the topic of great
+   debate while creating this specification.  As such choosing the right
+   timestamp for your application is a very important topic.  This
+   section will detail some of the most common points on this topic.
 
-   *  The 4 Version bits remain unchanged (ver).
+   Reliability:
+      Implementations SHOULD use the current timestamp from a reliable
+      source to provide values that are time-ordered and continually
+      increasing.  Care SHOULD be taken to ensure the timestamp does not
+      move backwards which will impact UUID sorting.
 
-   *  All 12 bits of subsec_b have been dedicated to a monotonic clock
-      sequence counter (seq).
+   Source:
+      UUID version 1 and 6 both utilize a Gregorian epoch timestamp
+      while UUIDv7 utilizes a Unix Epoch timestamp.  If other timestamp
+      sources or a custom timestamp epoch are required UUIDv8 SHOULD be
+      leveraged.
 
-   *  The 2 Variant bits remain unchanged (var).
-
-   *  Finally the remaining 62 bits in the subsec_seq_node section are
-      layout is filled out with random data to pad the length and
-      provide guaranteed uniqueness (rand).
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                            unixts                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |unixts |         msec          |  ver  |          seq          |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |var|                         rand                              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                             rand                              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Figure 3: UUIDv7 Field and Bit Layout - Encoding Example (Millisecond
-                                 Precision)
+   Sub-second Precision and Accuracy:
+      Many levels of precision exist for timestamps: milliseconds,
+      microseconds, nanoseconds, and beyond.  Additionally fractional
+      representations of sub-second precision may be desired to mix
+      various levels of precision in a time-ordered manner.  With UUID
+      version 1 and 6, 100-nanoseconds of precision are present while
+      UUIDv7 features fixed millisecond level of precision within the
+      Unix epoch.  If additional levels of precision are required UUIDv8
+      SHOULD be utilized.
 
+   Length:
+      The length of a given timestamp directly impacts how long a given
+      UUID will be valid.  Care should be given to ensure that the
+      proper length is selected for a given timestamp.  UUID version 1
+      and 6 utilize a 60 bit timestamp and UUIDv7 features a 48 bit
+      timestamp.
 
 
 
-
-Peabody & Davis           Expires 5 August 2022                [Page 13]
+Peabody & Davis         Expires 1 September 2022               [Page 13]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   In Figure 4 the UUIDv7 has been created with Microsecond precision
-   with the available sub-second precision bits.
+   Fuzzing:
+      Implementations MAY fuzz a timestamp.  Some examples included
+      security considerations around providing a real clock value within
+      a UUID or to correct inaccurate clocks.  This specification makes
+      no requirement or guarantee about how close the clock value needs
+      to be to actual time.
 
-   Examining Figure 4 one can observe:
+   Padding:
+      When timestamp padding is required, implementations MUST pad the
+      most significant bits (left-most) bits with zeros.  An example is
+      padding the most significant, left-most bits of a 32 bit unix
+      timestamp with zero's to fill out the 48 bit timestamp in UUIDv7.
 
-   *  The first 36 bits have been dedicated to the Unix Timestamp
-      (unixts)
+   Truncating:
+      Similarly, when timestamps need to be truncated: the lower, least
+      significant bits MUST be used.  An example would be truncating a
+      64 bit unix timestamp to the least significant, right-most 48 bits
+      for UUIDv7.
 
-   *  All 12 bits of scenario subsec_a is fully dedicated to providing
-      sub-second encoding for the Microsecond precision (usec).
+5.2.  Monotonicity and Counters
 
-   *  The 4 Version bits remain unchanged (ver).
+   Monotonicity is the backbone of time-based sortable UUIDs.  Naturally
+   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.
 
-   *  All 12 bits of subsec_b have been dedicated to providing sub-
-      second encoding for the Microsecond precision (usec).
+   Additionally, care MUST be taken to ensure UUIDs generated in batches
+   are also monotonic.  That is, if one-thousand UUIDs are generated for
+   the same timestamp; there is sufficient logic for organizing the
+   creation of order of those one-thousand UUIDs.  For batch UUID
+   creation implements MAY utilize a monotonic counter which SHOULD
+   increment for each UUID created during a given timestamp.
 
-   *  The 2 Variant bits remain unchanged (var).
+   For single-node UUID implementations that do not need to create
+   batches of UUIDs, the embedded timestamp within UUID version 1, 6,
+   and 7 can provide sufficient monotonicity guarantees by simply
+   ensuring that timestamp increments before creating a new UUID.  For
+   the topic of Distributed Nodes please refer to Section 5.3
 
-   *  A 14 bit monotonic clock sequence counter (seq) has been embedded
-      in the most significant position of subsec_seq_node
+   The following methods SHOULD be employed for single-node UUID
+   implementations that do require batch UUID creation.
 
-   *  Finally the remaining 48 bits in the subsec_seq_node section are
-      layout is filled out with random data to pad the length and
-      provide guaranteed uniqueness (rand).
 
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                            unixts                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |unixts |         usec          |  ver  |         usec          |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |var|             seq           |            rand               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                             rand                              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-   Figure 4: UUIDv7 Field and Bit Layout - Encoding Example (Microsecond
-                                 Precision)
 
-   In Figure 5 the UUIDv7 has been created with Nanosecond precision
-   with the available sub-second precision bits.
 
-   Examining Figure 5 one can observe:
 
-   *  The first 36 bits have been dedicated to the Unix Timestamp
-      (unixts)
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 14]
+Peabody & Davis         Expires 1 September 2022               [Page 14]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   *  All 12 bits of scenario subsec_a is fully dedicated to providing
-      sub-second encoding for the Nanosecond precision (nsec).
-
-   *  The 4 Version bits remain unchanged (ver).
-
-   *  All 12 bits of subsec_b have been dedicated to providing sub-
-      second encoding for the Nanosecond precision (nsec).
-
-   *  The 2 Variant bits remain unchanged (var).
-
-   *  The first 14 bit of the subsec_seq_node dedicated to providing
-      sub-second encoding for the Nanosecond precision (nsec).
-
-   *  The next 8 bits of subsec_seq_node dedicated a monotonic clock
-      sequence counter (seq).
-
-   *  Finally the remaining 40 bits in the subsec_seq_node section are
-      layout is filled out with random data to pad the length and
-      provide guaranteed uniqueness (rand).
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                            unixts                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |unixts |         nsec          |  ver  |         nsec          |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |var|             nsec          |      seq      |     rand      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                             rand                              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-          Figure 5: UUIDv7 Field and Bit Layout - Encoding Example
-                           (Nanosecond Precision)
-
-4.4.4.2.  UUIDv7 Decoding
-
-   When decoding or parsing a UUIDv7 value there are only two values to
-   be considered:
-
-   1.  The unix timestamp defined as unixts
-
-   2.  The sub-second precision values defined as subsec_a, subsec_b,
-       and subsec_seq_node
-
-   As detailed in Figure 2 the unix timestamp (unixts) is always the
-   first 36 bits of the UUIDv7 layout.
-
-
-
-
-Peabody & Davis           Expires 5 August 2022                [Page 15]
+   Fixed-Length Dedicated Counter Bits (Position A):
+      This references the practice of allocating 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.
+      Positioning of a fixed bit-length counter SHOULD be immediatly
+      after the embedded timestamp.  This promotes sortability and
+      allows random data generation for each counter increment.  UUIDs
+      utilizing this method should be created using UUIDv8.
+
+   Fixed-Length Dedicated Counter Bits (Position B):
+      An alternative approach to the previous method is to dedicate a
+      number of bits in the least significant position of the UUID.
+      With this alternative method, the random data MUST be frozen for a
+      given timestamp tick else sorting will be impacted.  UUIDs
+      utilizing this method should be created using UUIDv8.
+
+   Fixed-Length Dedicated Counter Seeding:
+      Implementations utilizing fixed-length counter bits SHOULD
+      initialize the counter at zero to ensure the full bit-space is
+      utilized and help avoid counter rollovers.
+
+   Fixed-Length Dedicated Counter Length
+      Care MUST be taken to select a counter bit-length that can
+      properly handle the level of timestamp precision in use.  For
+      example, millisecond precision SHOULD require a larger counter
+      than a timestamp with nanosecond precision.  General Guidance is
+      that the counter SHOULD be at least 12 bits and no more than a
+      maximum of 24 bits.
+
+   Fixed-Length Dedicated Counter Rollover Handling
+      Counter rollovers SHOULD be handled by the application to avoid
+      sorting issues.  The general guidance is that applications should
+      freeze the counter and wait for the timestamp to advance which
+      ensures monotonicity is not broken.
+
+   Monotonic Random:
+      With this method the random data is extended to also double as a
+      counter.  This monotonic random can be thought of as a "randomly
+      seeded counter" which MUST be incremented in the least significant
+      position for each UUID created on a given timestamp tick.  This is
+      similar to the Fixed-Length Dedicated Counter Bits (Position B)
+      method described in the previous bullets but does not suffer from
+      rollover issues, length problems, or wasted entropy bits plagued
+      by both fixed-length counter bit positions.  As such, UUIDv7
+      SHOULD utilize this method to handle batch UUID generation during
+      a single timestamp tick.
+
+
+
+
+
+Peabody & Davis         Expires 1 September 2022               [Page 15]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   Similarly as per Figure 2, the sub-second precision values lie within
-   subsec_a, subsec_b, and subsec_seq_node which are all interpreted as
-   sub-second information after skipping over the version (ver) and
-   (var) bits.  These concatenated sub-second information bits are
-   interpreted in a way where most to least significant bits represent a
-   further division by two.  This is the same normal place notation used
-   to express fractional numbers, except in binary.  For example, in
-   decimal ".1" means one tenth, and ".01" means one hundredth.  In this
-   subsec field, a 1 means one half, 01 means one quarter, 001 is one
-   eighth, etc.  This scheme can work for any number of bits up to the
-   maximum available, and keeps the most significant data leftmost in
-   the bit sequence.
+   Implementations MAY use the following logic to ensure UUIDs featuring
+   embedded counters are monotonic in nature:
+
+   1.  Compare the current timestamp against the previously stored
+       timestamp.
+   2.  If the current timestamp is equal to the previous timestamp;
+       increment desired counter logic.
+   3.  If the current timestamp is greater than the previous timestamp;
+       re-initialize the counter to the new timestamp and generate new
+       random bytes (if the bytes were frozen or being used as the seed
+       for a monotonic counter).
+
+   Implementations SHOULD check if the the currently generated UUID is
+   greater than the previously generated UUID.  If this is not the case
+   then any number of things could have occurred.  Such as, but not
+   limited to, clock rollbacks or counter rollovers.  Applications
+   SHOULD embed sufficient logic to catch these scenarios and correct
+   the problem ensuring the next UUID generated is greater than the
+   previous.
+
+   UUIDv1, and by extension UUIDv6, utilize a slightly different counter
+   in the form of "clock sequence" bits.  The usage of the clock
+   sequence will remain as defined in [RFC4122], Section 4.1.5.
+
+5.3.  Distributed UUID Generation
+
+   Some implementations MAY desire to utilize multi-node, clustered,
+   applications which involve two or more applications 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 nodes increase; so does
+   the likelihood of a collision.  This section will detail the
+   approaches that MAY be utilized by multi-node UUID implementations in
+   distributed environments.
+
+   Shared Knowledge System:
+      With this 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.  Utilization of shared knowledge schemes with central/global
+      registries is outside the scope of this specification.
+
+   Node IDs:
+      With this method, a nondescript pseudo-random Node ID value is
+      placed within the UUID layout.  This identifier ensures the 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
+
+
+
+Peabody & Davis         Expires 1 September 2022               [Page 16]
+
+Internet-Draft               new-uuid-format               February 2022
 
-   To perform the sub-second math, simply take the first (most
-   significant/leftmost) N bits of subsec and divide it by 2^N.  Take
-   for example:
 
-   1.  To parse the first 16 bits, extract that value as an integer and
-       divide it by 65536 (2 to the 16th).
+      different node id.  Implementations that choose to leverage an
+      embedded node id SHOULD utilize UUIDv8.  The node id SHOULD NOT be
+      an IEEE 802 MAC address as per Section 7.  The location and bit
+      length are up to implements and outside the scope of this
+      specification.  Furthermore, the creation and negotiation of a
+      node id among distributed nodes is also out of scope for this
+      specification.
 
-   2.  If these 16 bits are 0101 0101 0101 0101, then treating that as
-       an integer gives 0x5555 or 21845 in decimal, and dividing by
-       65536 gives 0.3333282
+   Utilization of either a shared knowledge scheme or Node ID are not
+   required for implementing UUIDs in this specification.  However
+   implementations SHOULD utilize one of the two aforementioned methods
+   if distributed UUID generation is a requirements.
 
-   This sub-second encoding scheme provides maximum interoperability
-   across systems where different levels of time precision are
-   required/feasible/available.  The timestamp value derived from a
-   UUIDv7 value SHOULD be "as close to the correct value as possible"
-   when parsed, even across disparate systems.
+5.4.  Collision Resistance
 
-   Take for example the starting point for our next two UUIDv7 parsing
-   scenarios:
+   Implementations SHOULD weigh the importance of a collision within
+   their application and take this into account when making a selections
+   around the total entropy (random) to dedicated to a UUID layout
+   versus the other components such as Section 5.1 and Section 5.2.
+   This is especially true for distributed node collision resistance as
+   defined by Section 5.3.
 
-   1.  System A produces a UUIDv7 with a microsecond-precise timestamp
-       value.
+   There are two example scenarios below which help illustrate the
+   varying seriousness of a collision within an application.
 
-   2.  System B is unaware of the precision encoded in the UUIDv7
-       timestamp by System A.
+   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.
 
-   Scenario 1:
+   High Impact:
+      A duplicate key causes an airplane to receive the wrong course
+      which puts people's lives at risk.  In this scenario there is no
+      margin for error.  Collisions MUST be avoided and failure is
+      unacceptable.  As such applications dealing with this type of
+      scenario MUST employ as much collision resistance as possible
+      within the given application context.
 
-   1.  System B parses the embedded timestamp with millisecond
-       precision.  (Less precision than the encoder)
+5.5.  Global and Local Uniqueness
 
-   2.  System B SHOULD return the correct millisecond value encoded by
-       system A (truncated to milliseconds).
+   UUIDs created by this specification MAY be used to provide local
+   uniqueness guarantees.  For example, ensuring UUIDs created within a
+   local application context are unique within a database MAY be
+   sufficient for some implementations where global uniqueness outside
+   of the application context, in other applications, or around the
+   world is not required.
 
-   Scenario 2:
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 16]
+Peabody & Davis         Expires 1 September 2022               [Page 17]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   1.  System B parses the timestamp with nanosecond precision.  (More
-       precision than the encoder)
-
-   2.  System B's value returned SHOULD have the same microsecond level
-       of precision provided by the encoder with the additional
-       precision down to nanosecond level being essentially random as
-       per the encoded random value at the end of the UUIDv7.
+   Although true global uniqueness is impossible to guarantee without
+   shared knowledge scheme; a shared knowledge scheme is not required by
+   UUID to provide uniqueness guarantees.  Implementations MAY implement
+   a shared knowledge scheme introduced in Section 5.3 as they see fit
+   to extend the uniqueness guaranteed this specification and [RFC4122].
 
-4.5.  UUIDv8 Layout and Bit Order
+5.6.  Unguessability
 
-   UUIDv8 offers variable-size timestamp, clock sequence, and node
-   values which allow for a highly customizable UUID that fits a given
-   application needs.
+   Implementations SHOULD utilize a cryptographically secure pseudo-
+   random number generator (CSPRNG) to provide values that are both
+   difficult to predict ("unguessable") and have a low likelihood of
+   collision ("unique").  CSPRNG ensures the best of Section 5.4 and
+   Section 7 are present in modern UUIDs.
 
-   UUIDv8 SHOULD only be utilized if an implementation cannot utilize
-   UUIDv1, UUIDv6, or UUIDv7.  Some situations in which UUIDv8 usage
-   could occur:
+5.7.  Sorting
 
-   *  An implementation would like to utilize a timestamp source not
-      defined by the current time-based UUIDs.
+   UUIDv6 and UUIDv7 are designed so that implementations that require
+   sorting (e.g. database indexes) SHOULD sort as opaque raw bytes,
+   without examining the contents at all.
 
-   *  An implementation would like to utilize a timestamp bit layout not
-      defined by the current time-based UUIDs.
+   Time ordered monotonic UUIDs benefit from greater index locality
+   because the new values are near each other in the index.  As a result
+   objects can much more easily be clustered together for better
+   performance.  The real-world differences in this approach of index
+   locality vs random data inserts can be quite large.
 
-   *  An implementation would like to avoid truncating a 64 bit Unix to
-      36 bits as defined by UUIDv7.
+5.8.  Storing UUIDs, Opacity
 
-   *  An implementation would like a specific level of precision within
-      the timestamp not offered by current time-based UUIDs.
+   For many applications, such as databases, storing UUIDs as the text
+   is unnecessarily verbose totaling 288 bits to convey the 128 bit UUID
+   value.  Due to the this, where possible, UUIDs SHOULD be stored
+   within database applications as the underlying 128 bit binary value.
 
-   *  An implementation would like to embed extra information within the
-      UUID node other than what is defined in this document.
+   *  8 bits for each of the 32 hex characters = 256 bits
+   *  8 bits for each of the 4 hyphens = 32 bits
 
-   *  An implementation has other application/language restrictions
-      which inhibit the usage of one of the current time-based UUIDs.
+   For other systems, UUIDs MAY be stored in binary form or as text, as
+   appropriate.  The trade offs to both approaches are as such:
 
-   Roughly speaking a properly formatted UUIDv8 SHOULD contain the
-   following sections adding up to a total of 128 bits.
+   *  Storing as binary requires less space and may result in faster
+      data access.
+   *  Storing as text requires more space but may require less
+      translation if the resulting text form is to be used after
+      retrieval and thus maybe simpler to implement.
 
-      - Timestamp Bits (Variable Length)
-      - Clock Sequence Bits (Variable Length)
-      - Node Bits (Variable Length)
-      - UUIDv8 Version Bits (4 bits)
-      - UUID Variant Bits (2 Bits)
+   UUIDs SHOULD be treated as opaque values and implementations SHOULD
+   NOT examine the bits in a UUID to whatever extent is possible.
 
-   The only explicitly defined bits are the Version and Variant leaving
-   122 bits for implementation specific time-based UUIDs.  To be clear:
-   UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 17]
+Peabody & Davis         Expires 1 September 2022               [Page 18]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   filled with random data.  UUIDv8's 128 bits (including the version
-   and variant) SHOULD contain at the minimum a timestamp of some format
-   in the most significant bit position followed directly by a clock
-   sequence counter and finally a node containing either random data or
-   implementation specific data.
-
-   A sample format in Figure 6 is used to further illustrate the point
-   for the 16-octet, 128 bit UUIDv8.
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                          timestamp_32                         |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |           timestamp_48        |  ver  |      time_or_seq      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |var|  seq_or_node  |          node                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                              node                             |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Where necessary, the version number may be extracted by first
+   verifying the variant field bits 64 and 65 contain 1 and 0
+   respectively, and then extract the version from bits 48 through 51.
+   UUID versions 7 and 8 can be identified by checking octet 8 for the
+   values 0xE7 or 0xE8 respectively.  The version number can then be
+   used to inspect the remainder of the UUID according to the
+   specification for that version.  See Section 4.1 for more information
+   on determining a UUID version based on the inspected variant bits.
 
-                   Figure 6: UUIDv8 Field and Bit Layout
+6.  IANA Considerations
 
-   timestamp_32:
-      The most significant 32 bits of the desired timestamp source.
-      Occupies bits 0 through 31 (octets 0-3).
+   This document has no IANA actions.
 
-   timestamp_48:
-      The next 16 bits of the timestamp source when a timestamp source
-      with at least 48 bits is used.  When a 32 bit timestamp source is
-      utilized, these bits are set to 0.  Occupies bits 32 through 47
+7.  Security Considerations
 
-   ver:
-      The 4 bit UUIDv8 version (1000).  Occupies bits 48 through 51.
+   MAC addresses pose inherent security risks and SHOULD not be used
+   within a UUID.  Instead CSPRNG data SHOULD selected from a source
+   with sufficient entropy to ensure guaranteed uniqueness among UUID
+   generation.  See Section 5.6 for more information.
 
-   time_or_seq:
-      If a 60 bit, or larger, timestamp is used these 12 bits are used
-      to fill out the remaining timestamp.  If a 32 or 48 bit timestamp
-      is leveraged a 12 bit clock sequence MAY be used.  Together ver
-      and time_or_seq occupy bits 48 through 63 (octets 6-7)
+   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 it's 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 then [RFC4122]
+   UUIDv4 SHOULD be utilized.
 
-   var:
-      2 bit UUID variant (10)
+8.  Acknowledgements
 
+   The authors gratefully acknowledge the contributions of 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, sergeyprokhorenko, LiosK As well as all of
+   those in the IETF community and on GitHub to who contributed to the
+   discussions which resulted in this document.
 
+9.  Normative References
 
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
 
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 18]
+Peabody & Davis         Expires 1 September 2022               [Page 19]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   seq_or_node:
-      If a 60 bit, or larger, timestamp source is leverages these 8 bits
-      SHOULD be allocated for an 8 bit clock sequence counter.  If a 32
-      or 48 bit timestamp source is used these 8 bits SHOULD be set to
-      random.
-
-   node:
-      In most implementations these bits will likely be set to pseudo-
-      random data.  However, implementations utilize the node as they
-      see fit.  Together var, seq_or_node, and node occupy Bits 64
-      through 127 (octets 8-15)
-
-4.5.1.  UUIDv8 Timestamp Usage
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <https://www.rfc-editor.org/info/rfc4122>.
 
-   UUIDv8's usage of timestamp relaxes both the timestamp source and
-   timestamp length.  Implementations are free to utilize any
-   monotonically stable timestamp source for UUIDv8.
+10.  Informative References
 
-   Some examples include:
+   [LexicalUUID]
+              Twitter, "A Scala client for Cassandra", commit f6da4e0,
+              November 2012,
+              <https://github.com/twitter-archive/cassie>.
 
-      - Custom Epoch
-      - NTP timestamp
-      - ISO 8601 timestamp
-      - Full, Non-truncated 64 bit Unix Epoch timestamp
+   [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>.
 
-   The relaxed nature UUIDv8 timestamps also works to future proof this
-   specification and allow implementations a method to create compliant
-   time-based UUIDs using timestamp source that might not yet be
-   defined.
+   [Flake]    Boundary, "Flake: A decentralized, k-ordered id generation
+              service in Erlang", Commit 15c933a, February 2017,
+              <https://github.com/boundary/flake>.
 
-   Timestamps come in many sizes and UUIDv8 defines three fields that
-   can easily used for the majority of timestamp lengths:
+   [ShardingID]
+              Instagram Engineering, "Sharding & IDs at Instagram",
+              December 2012, <https://instagram-engineering.com/
+              sharding-ids-at-instagram-1cf5a71e5a5c>.
 
-   *  32 bit timestamp: using timestamp_32 and setting timestamp_48 to
-      0s
+   [KSUID]    Segment, "K-Sortable Globally Unique IDs", Commit bf376a7,
+              July 2020, <https://github.com/segmentio/ksuid>.
 
-   *  48 bit timestamp: using timestamp_32 and timestamp_48 entirely
+   [Elasticflake]
+              Pearcy, P., "Sequential UUID / Flake ID generator pulled
+              out of elasticsearch common", Commit dd71c21, January
+              2015, <https://github.com/ppearcy/elasticflake>.
 
-   *  60 bit timestamp: using timestamp_32, timestamp_48, and
-      time_or_seq
+   [FlakeID]  Pawlak, T., "Flake ID Generator", Commit fcd6a2f, April
+              2020, <https://github.com/T-PWK/flake-idgen>.
 
-   *  64 bit timestamp: using timestamp_32, timestamp_48, and
-      time_or_seq and truncating the timestamp the 60 most significant
-      bits.
+   [Sonyflake]
+              Sony, "A distributed unique ID generator inspired by
+              Twitter's Snowflake", Commit 848d664, August 2020,
+              <https://github.com/sony/sonyflake>.
 
-   Although it is possible to create a timestamp larger than 64 bits in
-   size The usage and bit layout of that timestamp format is up to the
-   implementation.  When a timestamp exceeds the 64th bit (octet 7),
+   [orderedUuid]
+              Cabrera, IT., "Laravel: The mysterious "Ordered UUID"",
+              January 2020, <https://itnext.io/laravel-the-mysterious-
+              ordered-uuid-29e7500b4f8>.
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 19]
+Peabody & Davis         Expires 1 September 2022               [Page 20]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   extra care must be taken to ensure the Variant bits are properly
-   inserted at their respective location in the UUID.  Likewise, the
-   Version MUST always be implemented at the appropriate location.
-
-   Any timestamps that does not entirely fill the timestamp_32,
-   timestamp_48 or time_or_seq MUST set all leftover bits in the least
-   significant position of the respective field to 0.  For example a 36
-   bit timestamp source would fully utilize timestamp_32 and 4 bits of
-   timestamp_48.  The remaining 12 bits in timestamp_48 MUST be set to
-   0.
-
-   By using implementation-specific timestamp sources it is not
-   guaranteed that devices outside of the application context are able
-   to extract and parse the timestamp from UUIDv8 without some pre-
-   existing knowledge of the source timestamp used by the UUIDv8
-   implementation.
-
-4.5.2.  UUIDv8 Clock Sequence Usage
-
-   A clock sequence MUST be used with UUIDv8 as added sequencing
-   guarantees when multiple UUIDv8 will be created on the same clock
-   tick.  The amount of bits allocated to the clock sequence depends on
-   the precision of the timestamp source.  For example, a more accurate
-   timestamp source using nanosecond precision will require less clock
-   sequence bits than a timestamp source utilizing seconds for
-   precision.
+   [COMBGUID] Tallent, R., "Creating sequential GUIDs in C# for MSSQL or
+              PostgreSql", Commit 2759820, December 2020,
+              <https://github.com/richardtallent/RT.Comb>.
 
-   The UUIDv8 layout in Figure 6 generically defines two possible clock
-   sequence values that can leveraged:
+   [ULID]     Feerasta, A., "Universally Unique Lexicographically
+              Sortable Identifier", Commit d0c7170, May 2019,
+              <https://github.com/ulid/spec>.
 
-   *  12 bit clock sequence using time_or_seq for use when the timestamp
-      is less than 48 bits which allows for 4095 UUIDs per clock tick.
-   *  8 bit clock sequence using seq_or_node when the timestamp uses
-      more than 48 bits which allows for 255 UUIDs per clock tick.
+   [SID]      Chilton, A., "sid : generate sortable identifiers",
+              Commit 660e947, June 2019,
+              <https://github.com/chilts/sid>.
 
-   An implementation MAY use both time_or_seq and seq_or_node for clock
-   sequencing however it is highly unlikely that 20 bits of clock
-   sequence are needed for a given clock tick.  Furthermore, more bits
-   from the node MAY be used for clock sequencing in the event that 8
-   bits is not sufficient.
+   [pushID]   Google, "The 2^120 Ways to Ensure Unique Identifiers",
+              February 2015, <https://firebase.googleblog.com/2015/02/
+              the-2120-ways-to-ensure-unique_68.html>.
 
+   [XID]      Poitrey, O., "Globally Unique ID Generator",
+              Commit efa678f, October 2020, <https://github.com/rs/xid>.
 
+   [ObjectID] MongoDB, "ObjectId - MongoDB Manual",
+              <https://docs.mongodb.com/manual/reference/method/
+              ObjectId/>.
 
+   [CUID]     Elliott, E., "Collision-resistant ids optimized for
+              horizontal scaling and performance.", Commit 215b27b,
+              October 2020, <https://github.com/ericelliott/cuid>.
 
+   [IEEE754]  IEEE, "Collision-resistant ids optimized for horizontal
+              scaling and performance.", Series 754-2019, July 2019,
+              <https://standards.ieee.org/ieee/754/6210/>.
 
+Appendix A.  Example Code
 
+A.1.  Creating a UUIDv6 Value
 
+   This section details a function in C which converts from a UUID
+   version 1 to version 6:
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 20]
-
-Internet-Draft               new-uuid-format               February 2022
 
 
-   The clock sequence MUST start at zero and increment monotonically for
-   each new UUIDv8 created on by the application on the same timestamp.
-   When the timestamp increments the clock sequence MUST be reset to
-   zero.  The clock sequence MUST NOT rollover or reset to zero unless
-   the timestamp has incremented.  Care MUST be given to ensure that an
-   adequate sized clock sequence is selected for a given application
-   based on expected timestamp precision and expected UUIDv8 generation
-   rates.
 
-4.5.3.  UUIDv8 Node Usage
 
-   The UUIDv8 Node MAY contain any set of data an implementation desires
-   however the node MUST NOT be set to all 0s which does not ensure
-   global uniqueness.  In most scenarios the node will be filled with
-   pseudo-random data.
 
-   The UUIDv8 layout in Figure 6 defines 2 sizes of Node depending on
-   the timestamp size:
 
-   *  62 bit node encompassing seq_or_node and node Used when a
-      timestamp of 48 bits or less is leveraged.
-   *  54 bit node when all 60 bits of the timestamp are in use and the
-      seq_or_node is used as clock sequencing.
 
-   An implementation MAY choose to allocate bits from the node to the
-   timestamp, clock sequence or application-specific embedded field.  It
-   is recommended that implementation utilize a node of at least 48 bits
-   to ensure global uniqueness can be guaranteed.
 
-4.5.4.  UUIDv8 Basic Creation Algorithm
 
-   The entire usage of UUIDv8 is meant to be variable and allow as much
-   customization as possible to meet specific application/language
-   requirements.  As such any UUIDv8 implementations will likely vary
-   among applications.
 
-   The following algorithm is a generic implementation using Figure 6
-   and the recommendations outlined in this specification.
+Peabody & Davis         Expires 1 September 2022               [Page 21]
+
+Internet-Draft               new-uuid-format               February 2022
 
-   *32 bit timestamp, 12 bit sequence counter, 62 bit node:*
 
-   1.   From a system-wide shared stable store (e.g., a file) or global
-        variable, read the UUID generator state: the values of the
-        timestamp and clock sequence used to generate the last UUID.
+   #include <stdio.h>
+   #include <stdint.h>
+   #include <inttypes.h>
+   #include <arpa/inet.h>
+   #include <uuid/uuid.h>
 
-   2.   Obtain the current time from the selected clock source as 32
-        bits.
+   /* Converts UUID version 1 to version 6 in place. */
+   void uuidv1tov6(uuid_t u) {
 
+     uint64_t ut;
+     unsigned char *up = (unsigned char *)u;
 
+     // load ut with the first 64 bits of the UUID
+     ut = ((uint64_t)ntohl(*((uint32_t*)up))) << 32;
+     ut |= ((uint64_t)ntohl(*((uint32_t*)&up[4])));
 
+     // dance the bit-shift...
+     ut =
+       ((ut >> 32) & 0x0FFF) | // 12 least significant bits
+       (0x6000) | // version number
+       ((ut >> 28) & 0x0000000FFFFF0000) | // next 20 bits
+       ((ut << 20) & 0x000FFFF000000000) | // next 16 bits
+       (ut << 52); // 12 most significant bits
 
-Peabody & Davis           Expires 5 August 2022                [Page 21]
-
-Internet-Draft               new-uuid-format               February 2022
+     // store back in UUID
+     *((uint32_t*)up) = htonl((uint32_t)(ut >> 32));
+     *((uint32_t*)&up[4]) = htonl((uint32_t)(ut));
 
+   }
 
-   3.   Set the 32 bit field timestamp_32 to the 32 bits from the
-        timestamp
+                       Figure 6: UUIDv6 Function in C
 
-   4.   Set 16 bit timestamp_48 to all 0s
+A.2.  Creating a UUIDv7 Value
 
-   5.   Set the version to 8 (1000)
 
-   6.   If the state was unavailable (e.g., non-existent or corrupted)
-        or the timestamp is greater than the current timestamp; set the
-        12 bit clock sequence value (time_or_seq) to 0
 
-   7.   If the state was available, but the saved timestamp is less than
-        or equal to the current timestamp, increment the clock sequence
-        value (time_or_seq).
 
-   8.   Set the variant to binary 10
 
-   9.   Generate 62 random bits and fill in 8 bits for seq_or_node and
-        54 bits for the node.
 
-   10.  Format by concatenating the 128 bits as: timestamp_32|timestamp_
-        48|version|time_or_seq|variant|seq_or_node|node
 
-   11.  Save the state (current timestamp and clock sequence) back to
-        the stable store
 
-   *48 bit timestamp, 12 bit sequence counter, 62 bit node:*
 
-   1.  From a system-wide shared stable store (e.g., a file) or global
-       variable, read the UUID generator state: the values of the
-       timestamp and clock sequence used to generate the last UUID.
 
-   2.  Obtain the current time from the selected clock source as 32
-       bits.
 
-   3.  Set the 32 bit field timestamp_32 to the 32 most significant bits
-       from the timestamp
 
-   4.  Set 16 bit timestamp_48 to the 16 least significant bits from the
-       timestamp
 
-   5.  The rest of the steps are the same as the previous example.
 
-   *60 bit timestamp, 8 bit sequence counter, 54 bit node:*
 
-   1.   From a system-wide shared stable store (e.g., a file) or global
-        variable, read the UUID generator state: the values of the
-        timestamp and clock sequence used to generate the last UUID.
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 22]
+Peabody & Davis         Expires 1 September 2022               [Page 22]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   2.   Obtain the current time from the selected clock source as 32
-        bits.
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <time.h>
 
-   3.   Set the 32 bit field timestamp_32 to the 32 bits from the
-        timestamp
+// ...
 
-   4.   Set 16 bit timestamp_48 to the 16 middle bits from the timestamp
+// csprng data source
+FILE *rndf;
+rndf = fopen("/dev/urandom", "r");
+if (rndf == 0) {
+        printf("fopen /dev/urandom error\n");
+        return 1;
+}
 
-   5.   Set the version to 8 (1000)
+// ...
 
-   6.   Set 12 bit time_or_seq to the 12 least significant bits from the
-        timestamp
+// generate one UUIDv7
+uint8_t u[16];
+struct timespec ts;
+int ret;
 
-   7.   Set the variant to 10
+ret = clock_gettime(CLOCK_REALTIME, &ts);
+if (ret != 0) {
+        printf("clock_gettime error: %d\n", ret);
+        return 1;
+}
 
-   8.   If the state was unavailable (e.g., non-existent or corrupted)
-        or the timestamp is greater than the current timestamp; set the
-        12 bit clock sequence value (seq_or_node) to 0
+uint64_t tms;
 
-   9.   If the state was available, but the saved timestamp is less than
-        or equal to the current timestamp, increment the clock sequence
-        value (seq_or_node).
+tms = ((uint64_t)ts.tv_sec) * 1000;
+tms += ((uint64_t)ts.tv_nsec) / 1000000;
 
-   10.  Generate 54 random bits and fill in the node
+printf("tms: %lld\n", tms);
 
-   11.  Format by concatenating the 128 bits as: timestamp_32|timestamp_
-        48|version|time_or_seq|variant|seq_or_node|node
+memset(u, 0, 16);
 
-   12.  Save the state (current timestamp and clock sequence) back to
-        the stable store
+fread(&u[6], 10, 1, rndf); // fill everything after the timestamp with random bytes
 
-   *64 bit timestamp, 8 bit sequence counter, 54 bit node:*
+*((uint64_t*)(u)) |= htonll(tms << 16); // shift time into first 48 bits and OR into place
 
-   1.  The same steps as the 60 bit timestamp can be utilized if the 64
-       bit timestamp is truncated to 60 bits.
+u[8] = 0xE7; // set var-ver field
 
-   2.  Implementations MAY chose to truncate the most or least
-       significant bits but it is recommended to utilize the most
-       significant 60 bits and lose 4 bits of precision in the
-       nanoseconds or microseconds position.
+                    Figure 7: UUIDv7 Function in C
 
-   *General algorithm for generation of UUIDv8 not defined here:*
 
-   1.  From a system-wide shared stable store (e.g., a file) or global
-       variable, read the UUID generator state: the values of the
-       timestamp and clock sequence used to generate the last UUID.
 
 
 
 
-
-Peabody & Davis           Expires 5 August 2022                [Page 23]
+Peabody & Davis         Expires 1 September 2022               [Page 23]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   2.  Obtain the current time from the selected clock source as desired
-       bit total
+A.3.  Creating a UUIDv7 Value
 
-   3.  Set total amount of bits for timestamp as required in the most
-       significant positions of the 128 bit UUID
+   UUIDv8 will vary greatly from implementation to implementation.  A
+   good candidate use case for UUIDv8 is to embed exotic timestamps like
+   the one found in this example which employs approximately 0.25
+   milliseconds and approximately 5 microseconds per timestamp tick as a
+   48 bit value.
 
-   4.  Care MUST be taken to ensure that the UUID Version and UUID
-       Variant are in the correct bit positions.
+   #include <stdint.h>
+   #include <stdio.h>
+   #include <time.h>
 
-       UUID Version: Bits 48 through 51
+   int main() {
+     struct timespec tp;
+     clock_gettime(CLOCK_REALTIME, &tp);
+     uint64_t timestamp = (uint64_t)tp.tv_sec << 12;
 
-       UUID Variant: Bits 64 and 65
+     // compute 12-bit (~0.25 msec precision) fraction from nsecs
+     timestamp |= ((uint64_t)tp.tv_nsec << 12) / 1000000000;
 
-   5.  If the state was unavailable (e.g., non-existent or corrupted) or
-       the timestamp is greater than the current timestamp; set the
-       desired clock sequence value to 0
+     printf("%08llx-%04llx\n", timestamp >> 16, timestamp & 0xFFFF);
+     return 0;
+   }
 
-   6.  If the state was available, but the saved timestamp is less than
-       or equal to the current timestamp, increment the clock sequence
-       value.
+                       Figure 8: UUID8 Function in C
 
-   7.  Set the remaining bits to the node as pseudo-random data
+Appendix B.  Test Vectors
 
-   8.  Format by concatenating the 128 bits together
+   Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit
+   timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February
+   22, 2022 2:22:22.000000 PM GMT-05:00
 
-   9.  Save the state (current timestamp and clock sequence) back to the
-       stable store
+   Both UUIDv1 and UUIDv6 utilize the same values in clk_seq_hi_res,
+   clock_seq_low, and node.  All of which have been generated with
+   random data.
 
-5.  Encoding and Storage
 
-   The existing UUID hex and dash format of 8-4-4-4-12 is retained for
-   both backwards compatibility and human readability.
 
-   For many applications such as databases this format is unnecessarily
-   verbose totaling 288 bits.
 
-   *  8 bits for each of the 32 hex characters = 256 bits
-   *  8 bits for each of the 4 hyphens = 32 bits
 
-   Where possible UUIDs SHOULD be stored within database applications as
-   the underlying 128 bit binary value.
 
 
 
@@ -1341,192 +1340,151 @@ Internet-Draft               new-uuid-format               February 2022
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 24]
+
+Peabody & Davis         Expires 1 September 2022               [Page 24]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-6.  Global Uniqueness
-
-   UUIDs created by this specification offer the same guarantees for
-   global uniqueness as those found in [RFC4122].  Furthermore, the
-   time-based UUIDs defined in this specification are geared towards
-   database applications but MAY be used for a wide variety of use-
-   cases.  Just as global uniqueness is guaranteed, UUIDs are guaranteed
-   to be unique within an application context within the enterprise
-   domain.
-
-7.  Distributed UUID Generation
-
-   Some implementations might desire to utilize multi-node, clustered,
-   applications which involve 2 or more applications independently
-   generating UUIDs that will be stored in a common location.  UUIDs
-   already feature sufficient entropy to ensure that the chances of
-   collision are low.  However, implementations MAY dedicate a portion
-   of the node's most significant random bits to a pseudo-random
-   machineID which helps identify UUIDs created by a given node.  This
-   works to add an extra layer of collision avoidance.
-
-   This machine ID MUST be placed in the UUID after the timestamp and
-   sequence counter bits.  This position is selected to ensure that the
-   sorting by timestamp and clock sequence is still possible.  The
-   machineID MUST NOT be an IEEE 802 MAC address.  The creation and
-   negotiation of the machineID among distributed nodes is out of scope
-   for this specification.
-
-8.  IANA Considerations
+# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
+gregorian_100_ns = (unix_64_bit_nanoseconds / 100) + gregorian_unix_offset
 
-   This document has no IANA actions.
+# 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.
+# gregorian_unix_offset = 0x01b21dd213814000 or 122192928000000000
 
-9.  Security Considerations
+# Unix 64 bit Nanosecond Timestamp:
+# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
+# unix_64_bit_nanoseconds = 0x16D6320C3D4DCC00 or 1645557742000000000
 
-   MAC addresses pose inherent security risks and MUST not be used for
-   node generation.  As such they have been strictly forbidden from
-   time-based UUIDs within this specification.  Instead pseudo-random
-   bits SHOULD selected from a source with sufficient entropy to ensure
-   guaranteed uniqueness among UUID generation.
+# Work:
+# gregorian_100_ns = (1645557742000000000 / 100) + 122192928000000000
+# (138648505420000000 - 122192928000000000) * 100 = unix_64_bit_nanoseconds
 
-   Timestamps embedded in the UUID do pose a very small attack surface.
-   The timestamp in conjunction with the clock sequence does signal the
-   order of creation for a given UUID and it's 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 then [RFC4122]
-   UUIDv4 SHOULD be utilized.
-
-
-
-
-Peabody & Davis           Expires 5 August 2022                [Page 25]
-
-Internet-Draft               new-uuid-format               February 2022
+# Final:
+# gregorian_100_ns = 0x1EC9414C232AB00 or 138648505420000000
 
+# Original: 000111101100100101000001010011000010001100101010101100000000
+# UUIDv1:   11000010001100101010101100000000|1001010000010100|0001|000111101100
+# UUIDv6:   00011110110010010100000101001100|0010001100101010|0110|101100000000
 
-   The machineID portion of node, described in Section 7, does provide
-   small unique identifier which could be used to determine which
-   application is generating data but this machineID alone is not enough
-   to identify a node on the network without other corresponding data
-   points.  Furthermore the machineID, like the timestamp+sequence, does
-   not provide any context about the data the corresponds to the UUID or
-   the current state of the application as a whole.
+             Figure 9: Test Vector Timestamp Pseudo-code
 
-10.  Acknowledgements
+B.1.  Example of a UUIDv6 Value
 
-   The authors gratefully acknowledge the contributions of Ben Campbell,
-   Ben Ramsey, Fabio Lima, Gonzalo Salgueiro, Martin Thomson, Murray S.
-   Kucherawy, Rick van Rein, Rob Wilton, Sean Leonard, Theodore Y.
-   Ts'o.  As well as all of those in and outside the IETF community to
-   who contributed to the discussions which resulted in this document.
-
-11.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
-              DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/info/rfc2119>.
-
-   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
-              Unique IDentifier (UUID) URN Namespace", RFC 4122,
-              DOI 10.17487/RFC4122, July 2005,
-              <https://www.rfc-editor.org/info/rfc4122>.
+   ----------------------------------------------
+   field                 bits    value_hex
+   ----------------------------------------------
+   time_low              32      0xC232AB00
+   time_mid              16      0x9414
+   time_hi_and_version   16      0x11EC
+   clk_seq_hi_res         8      0xB3
+   clock_seq_low          8      0xC8
+   node                  48      0x9E6BDECED846
+   ----------------------------------------------
+   total                128
+   ----------------------------------------------
+   final_hex: C232AB00-9414-11EC-B3C8-9E6BDECED846
 
-12.  Informative References
+                   Figure 10: UUIDv1 Example Test Vector
 
-   [LexicalUUID]
-              Twitter, "A Scala client for Cassandra", commit f6da4e0,
-              November 2012,
-              <https://github.com/twitter-archive/cassie>.
 
-   [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>.
 
-   [Flake]    Boundary, "Flake: A decentralized, k-ordered id generation
-              service in Erlang", Commit 15c933a, February 2017,
-              <https://github.com/boundary/flake>.
 
 
 
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 26]
+Peabody & Davis         Expires 1 September 2022               [Page 25]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   [ShardingID]
-              Instagram Engineering, "Sharding & IDs at Instagram",
-              December 2012, <https://instagram-engineering.com/
-              sharding-ids-at-instagram-1cf5a71e5a5c>.
+   -----------------------------------------------
+   field                 bits    value_hex
+   -----------------------------------------------
+   time_high              32      0x1EC9414C
+   time_mid               16      0x232A
+   time_low_and_version   16      0x6B00
+   clk_seq_hi_res          8      0xB3
+   clock_seq_low           8      0xC8
+   node                   48      0x9E6BDECED846
+   -----------------------------------------------
+   total                 128
+   -----------------------------------------------
+   final_hex: 1EC9414C-232A-6B00-B3C8-9E6BDECED846
 
-   [KSUID]    Segment, "K-Sortable Globally Unique IDs", Commit bf376a7,
-              July 2020, <https://github.com/segmentio/ksuid>.
+                   Figure 11: UUIDv6 Example Test Vector
 
-   [Elasticflake]
-              Pearcy, P., "Sequential UUID / Flake ID generator pulled
-              out of elasticsearch common", Commit dd71c21, January
-              2015, <https://github.com/ppearcy/elasticflake>.
+B.2.  Example of a UUIDv7 Value
 
-   [FlakeID]  Pawlak, T., "Flake ID Generator", Commit fcd6a2f, April
-              2020, <https://github.com/T-PWK/flake-idgen>.
+   This example UUIDv7 test vector utilizes a well-known 32-bit unix
+   epoch with additional millisecond precision to fill the first 48 bits
 
-   [Sonyflake]
-              Sony, "A distributed unique ID generator inspired by
-              Twitter's Snowflake", Commit 848d664, August 2020,
-              <https://github.com/sony/sonyflake>.
+   rand_a and rand_b are filled with random data.
 
-   [orderedUuid]
-              Cabrera, IT., "Laravel: The mysterious "Ordered UUID"",
-              January 2020, <https://itnext.io/laravel-the-mysterious-
-              ordered-uuid-29e7500b4f8>.
+   The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00
+   represented as 0x17F21CFD130 or 1645539742000
 
-   [COMBGUID] Tallent, R., "Creating sequential GUIDs in C# for MSSQL or
-              PostgreSql", Commit 2759820, December 2020,
-              <https://github.com/richardtallent/RT.Comb>.
+   -------------------------------
+   field      bits    value
+   -------------------------------
+   unix_ts_ms   48    0x017F21CFD130
+   rand_a       16    0xF8B8
+   var_ver       8    0xE7
+   rand_b       56    0xD6A139DC9535C5
+   -------------------------------
+   total        128
+   -------------------------------
+   final: 017F21CF-D130-F8B8-E7D6-A139DC9535C5
 
-   [ULID]     Feerasta, A., "Universally Unique Lexicographically
-              Sortable Identifier", Commit d0c7170, May 2019,
-              <https://github.com/ulid/spec>.
+                   Figure 12: UUIDv7 Example Test Vector
 
-   [SID]      Chilton, A., "sid : generate sortable identifiers",
-              Commit 660e947, June 2019,
-              <https://github.com/chilts/sid>.
+B.3.  Example of a UUIDv8 Value
 
-   [pushID]   Google, "The 2^120 Ways to Ensure Unique Identifiers",
-              February 2015, <https://firebase.googleblog.com/2015/02/
-              the-2120-ways-to-ensure-unique_68.html>.
+   This example UUIDv8 test vector utilizes a well-known 64-bit unix
+   epoch with nanosecond precision to fill the first 64 bits through
+   ver_var.
 
-   [XID]      Poitrey, O., "Globally Unique ID Generator",
-              Commit efa678f, October 2020, <https://github.com/rs/xid>.
+   The final 56 bits are filled with random data.
 
-   [ObjectID] MongoDB, "ObjectId - MongoDB Manual",
-              <https://docs.mongodb.com/manual/reference/method/
-              ObjectId/>.
 
 
 
-Peabody & Davis           Expires 5 August 2022                [Page 27]
+Peabody & Davis         Expires 1 September 2022               [Page 26]
 
 Internet-Draft               new-uuid-format               February 2022
 
 
-   [CUID]     Elliott, E., "Collision-resistant ids optimized for
-              horizontal scaling and performance.", Commit 215b27b,
-              October 2020, <https://github.com/ericelliott/cuid>.
+   Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00
+   represented as 0x16D6320C3D4DCC00 or 1645557742000000000
+
+   It should be noted that this example is just to illustrate one
+   scenario for UUIDv8.  Test vectors will likely be implementation
+   specific and vary greatly from this simple example.
+
+   -------------------------------
+   field      bits    value
+   -------------------------------
+   custom_a     64    0x16D6320C3D4DCC00
+   var_ver       8    0xE8
+   custom_b     56    0x3C2D06302FC417
+   -------------------------------
+   total        128
+   -------------------------------
+   final: 16D6320C-3D4D-CC00-E83C-2D06302FC417
+
+                   Figure 13: UUIDv8 Example Test Vector
 
 Authors' Addresses
 
    Brad G. Peabody
-
    Email: brad@peabody.io
 
 
    Kyzer R. Davis
-
    Email: kydavis@cisco.com
 
 
@@ -1551,18 +1509,4 @@ Authors' Addresses
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Peabody & Davis           Expires 5 August 2022                [Page 28]
+Peabody & Davis         Expires 1 September 2022               [Page 27]
diff --git a/draft-peabody-dispatch-new-uuid-format-03.xml b/draft-peabody-dispatch-new-uuid-format-03.xml
index b3a4269..9997f08 100644
--- a/draft-peabody-dispatch-new-uuid-format-03.xml
+++ b/draft-peabody-dispatch-new-uuid-format-03.xml
@@ -2,7 +2,7 @@
 <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
 <!-- OPTIONS, known as processing instructions (PIs) go here. -->
 <!-- For a complete list and description of PIs,
-     please see http://xml.resource.org/authoring/README.html. -->
+please see http://xml.resource.org/authoring/README.html. -->
 <!-- Below are generally applicable PIs that most I-Ds might want to use. -->
 <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
 <!-- control the table of contents (ToC): -->
@@ -12,120 +12,101 @@
 <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
 <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
 <!-- control vertical white space: 
-     (using these PIs as follows is recommended by the RFC Editor) -->
+(using these PIs as follows is recommended by the RFC Editor) -->
 <!-- end of popular PIs -->
-<!--
-    <rfc version="3" category="std" updates="4122" submissionType="IETF" consensus="true" ipr="trust200902"
-    docName="draft-peabody-dispatch-new-uuid-format-02">
--->
 <rfc version="3" category="std" updates="4122" submissionType="IETF" consensus="true" ipr="trust200902" docName="draft-peabody-dispatch-new-uuid-format-02">
-  <front>
-    <title abbrev="new-uuid-format">New UUID Formats</title>
-    <seriesInfo name="Internet-Draft" value="draft-peabody-dispatch-new-uuid-format-02" stream="IETF"/>
-    <author fullname="Brad G. Peabody" initials="BGP" surname="Peabody">
-<!-- <organization/> -->
-      <address>
-        <!-- postal><street/><city/><region/><code/><country/></postal -->
-<!-- <phone/> -->
-<!-- <facsimile/> -->
-      <email>brad@peabody.io</email>
-<!-- <uri/> -->
-      </address>
-    </author>
-	<author fullname="Kyzer R. Davis" initials="K" surname="Davis">
-      <address>
-      <email>kydavis@cisco.com</email>
-      </address>
-    </author>
-    <date year="2022" />
-      <area>ART</area>
-      <workgroup>dispatch</workgroup>
-      <keyword>uuid</keyword>
-<!-- <keyword/> -->
-<!-- <keyword/> -->
-<!-- <keyword/> -->
-    <abstract>
-        <t>
-            This document presents new time-based UUID formats which are suited for use as a database key.
-        </t>
-        <t>
-            A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
-			This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. 
-			In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces.
-			None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way.
-			This document is a proposal to update <xref target="RFC4122"/> with three new UUID versions that address these concerns, each with different trade-offs.
-        </t>
-    </abstract>
-  </front>
-  <middle>
-    <section title="Introduction">
-      <t>
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
-        this document are to be interpreted as described in
-        <xref target="RFC2119"/>.
-      </t>
-    </section>
-    <section anchor="Background" title="Background">
-        <t>
-            A lot of things have changed in the time since UUIDs were originally created.
-            Modern applications have a need to use (and many have already implemented) UUIDs
-            as database primary keys.
-        </t>
-        <t>
-            The motivation for using UUIDs as database keys stems primarily from the fact that applications
-            are increasingly distributed in nature. Simplistic "auto increment" schemes
-            with integers in sequence do not work well in a distributed system since the effort required to
-            synchronize such numbers across a network can easily become a burden.  
-            The fact that UUIDs can be used to create unique and reasonably short values in 
-			distributed systems without requiring synchronization makes them a good candidate 
-			for use as a database key in such environments.
-        </t>
-        <t>
-            However some properties of <xref target="RFC4122"/> UUIDs are not well suited to this task.
-			First, most of the existing UUID versions such as UUIDv4 have poor database index locality.
-			Meaning new values created in succession are not close to each other in the index and thus require 
-            inserts to be performed at random locations. The negative performance effects of which on 
-            common structures used for this (B-tree and its variants) can be dramatic. As such newly inserted 
-            values SHOULD be time-ordered to address this.
-        </t>
-        <t>
-			While it is true that UUIDv1 does contain an embedded timestamp
-			and can be time-ordered; UUIDv1 has other issues. It is possible to sort 
-            Version 1 UUIDs by time but it is a laborious task. The process requires breaking the bytes of the UUID 
-			into various pieces, re-ordering the bits, and then determining the order from the reconstructed timestamp. This 
-			is not efficient in very large systems. Implementations would be simplified with a sort order where the
-			UUID can simply be treated as an opaque sequence of bytes and ordered as such.
-        </t>
-        <t>
-            After the embedded timestamp, the remaining 64 bits are in essence used to provide uniqueness both on a global scale and
-			within a given timestamp tick. The clock sequence value ensures that when multiple UUIDs are 
-			generated for the same timestamp value are given a monotonic sequence value. This explicit sequencing 
-			helps further facilitate sorting. The remaining random bits ensure collisions are minimal.
-        </t>
-		<t>
-			Furthermore, UUIDv1 utilizes a non-standard timestamp epoch derived from the Gregorian Calendar. More 
-			specifically, the Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 
-			00:00:00.00, 15 October 1582. Implementations and many languages may find it easier to implement the widely adopted and well known 
-			Unix Epoch, a custom epoch, or another timestamp source with various levels of timestamp precision required by the application.
-        </t>
-		<t>
-            Lastly, privacy and network security issues arise from using a MAC address in the node field of Version 1 UUIDs.
-            Exposed MAC addresses can be used as an attack surface to locate machines and reveal various other
-            information about such machines (minimally manufacturer, potentially other details). Instead 
-			"cryptographically secure" pseudo-random number generators (CSPRNGs) or pseudo-random number generators (PRNG) 
-			SHOULD be used within an application context to provide uniqueness and unguessability.
-        </t>
-		<t>
-			Due to the shortcomings of UUIDv1 and UUIDv4 details so far, 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 lead 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, timestamp type, timestamp format, timestamp accuracy, node format/components, collision handling and multi-timestamp tick generation sequencing.
-		</t>
-		   <ol spacing="compact">
+	<front>
+		<title abbrev="new-uuid-format">New UUID Formats</title>
+		<seriesInfo name="Internet-Draft" value="draft-peabody-dispatch-new-uuid-format-02" stream="IETF"/>
+		<author fullname="Brad G. Peabody" initials="BGP" surname="Peabody">
+			<address>
+				<email>brad@peabody.io</email>
+			</address>
+		</author>
+		<author fullname="Kyzer R. Davis" initials="K" surname="Davis">
+			<address>
+				<email>kydavis@cisco.com</email>
+			</address>
+		</author>
+		<date year="2022" />
+		<area>ART</area>
+		<workgroup>dispatch</workgroup>
+		<keyword>uuid</keyword>
+		<abstract>
+			<t>
+				This document presents three new Universally Unique Identifier (UUID) formats.
+			</t>
+			<t>
+				A common case for modern applications is to create a unique identifier for use as a primary key in a database table.
+				This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. 
+				In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces.
+				None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way.
+				This document is a proposal to update <xref target="RFC4122"/> with three new UUID versions that address these concerns, each with different trade-offs.
+			</t>
+		</abstract>
+	</front>
+	<middle>
+		<section anchor="Background" title="Introduction">
+
+			<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 primary keys, file names, machine
+				or system names, identifiers for transactions or other objects or processes.
+			</t>
+
+			<t>
+				A specific use case for UUIDs which has gained popularity is as database primary keys.
+				The motivation for this stems primarily from the fact that applications
+				are increasingly distributed in nature. Simplistic "auto increment" schemes
+				with integers in sequence do not work well in a distributed system since the effort required to
+				synchronize such numbers across a network can easily become a burden.  
+				The fact that UUIDs can be used to create unique and reasonably short values in 
+				distributed systems without requiring synchronization makes them a good candidate 
+				for use as a database key in such environments.
+			</t>
+
+			<t>
+				UUID versions 1 through 5 lack certain desirable characteristics in some circumstances:
+			</t>
+			<ol>
+				<li><t>Non-time-ordered UUID versions such as UUIDv4 have poor database index locality.
+					Meaning new values created in succession are not close to each other in the index and thus require 
+					inserts to be performed at random locations. The negative performance effects of which on 
+					common structures used for this (B-tree and its variants) can be dramatic.
+				</t></li>	
+				<li><t>
+					The 100-nanosecond, Gregorian epoch used in UUIDv1 timestamps is uncommon and difficult to represent accurately using a standard number format such as <xref target="IEEE754"/>.
+				</t></li>
+				<li><t>
+					Introspection/parsing is required to order by time sequence; as opposed to being able to perform a simple byte-by-byte comparison.
+				</t></li>
+
+				<li><t>
+					Privacy and network security issues arise from using a MAC address in the node field of Version 1 UUIDs.
+					Exposed MAC addresses can be used as an attack surface to locate machines and reveal various other
+					information about such machines (minimally manufacturer, potentially other details). Additionally, with the advent of virtual machines and containers, MAC address uniqueness is no longer guaranteed.
+				</t></li>
+				<li><t>
+					Many implementation details are specified in <xref target="RFC4122"/> but some of the decisions made involve trade offs that are neither possible to specify for all applications nor necessary to produce interoperable implementations.
+				</t></li>
+				<li><t>
+					The previous specification also does not distinguish between the requirements for generation of a UUID versus an application which simply stores one, which are different.
+				</t></li>
+			</ol>
+
+			<t>
+				Due to the aforementioned issue, 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 lead 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, timestamp type, timestamp format, timestamp accuracy, node format/components, collision handling and multi-timestamp tick generation sequencing.
+			</t>
+			<ol spacing="compact">
+				<li><t><xref target="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"/> by Boundary</t></li>	
@@ -136,7 +117,6 @@
 				<li><t><xref target="Sonyflake"/> by Sony</t></li>	
 				<li><t><xref target="orderedUuid"/> by IT. Cabrera</t></li>	
 				<li><t><xref target="COMBGUID"/> by R. Tallent</t></li>	
-				<li><t><xref target="ULID"/> by A. Feerasta</t></li>	
 				<li><t><xref target="SID"/> by A. Chilton</t></li>	
 				<li><t><xref target="pushID"/> by Google</t></li>	
 				<li><t><xref target="XID"/> by O. Poitrey</t></li>	
@@ -144,127 +124,183 @@
 				<li><t><xref target="CUID"/> by E. Elliott</t></li>	
 			</ol>
 
-		<t>
-			An inspection of these implementations details the following trends that help define this standard:
-		</t>
-			<ul spacing="compact" empty="true">
-				<li><t>- Timestamps MUST be k-sortable. That is, values within or close to the same timestamp are ordered properly by sorting algorithms.</t></li>
-				<li><t>- Timestamps SHOULD be big-endian with the most-significant bits of the time embedded as-is without reordering.</t></li>
-				<li><t>- Timestamps SHOULD utilize millisecond precision and Unix Epoch as timestamp source. Although,
-				  there is some variation to this among implementations depending on the application requirements.</t></li>			
-				<li><t>- The ID format SHOULD be Lexicographically sortable while in the textual representation.</t></li>	
-				<li><t>- IDs MUST ensure proper embedded sequencing to facilitate sorting when multiple UUIDs are created during a given timestamp.</t></li>			
-				<li><t>- IDs MUST NOT require unique network identifiers as part of achieving uniqueness.</t></li>
-				<li><t>- Distributed nodes MUST be able to create collision resistant Unique IDs 
-				  without consulting a centralized resource.</t></li>
-			</ul>
-    </section>
-    <section anchor="Changes" title="Summary of Changes">
-        <t>
-        In order to solve these challenges this specification introduces three new version identifiers assigned 
-		for time-based UUIDs.
-		</t>
-		<t>
-		The first, UUIDv6, aims to be the easiest to implement for applications which already
-		implement UUIDv1. The UUIDv6 specification keeps the original Gregorian timestamp source but does not reorder the timestamp bits as per the process  
-		utilized by UUIDv1. UUIDv6 also requires that pseudo-random data MUST be used in place of the MAC address.
-		The rest of the UUIDv1 format remains unchanged in UUIDv6. See <xref target="uuidv6layout"/>
-        </t>
-		<t>
-		Next, UUIDv7 introduces an entirely new time-based UUID bit layout utilizing a variable length timestamp sourced from the 
-		widely implemented and well known Unix Epoch timestamp source.
-        The timestamp is broken into a 36 bit integer sections part, and is followed by a field of variable length which
-        represents the sub-second timestamp portion, encoded so that each bit from most to least significant adds more precision. See <xref target="uuidv7layout"/>
-		</t>
-		<t>
-		Finally, UUIDv8 introduces a relaxed time-based UUID format that caters to application implementations
-		that cannot utilize UUIDv1, UUIDv6, or UUIDv7. UUIDv8 also future-proofs this specification by allowing 
-		time-based UUID formats from timestamp sources that are not yet be defined. The variable size timestamp offers
-		lots of flexibility to create an implementation specific RFC compliant time-based UUID while retaining the 
-		properties that make UUID great. See <xref target="uuidv8layout"/>
-        </t>
-		<section anchor="changelog" title="changelog">
-			<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t>
-			<t>draft-02</t>
-			<ul spacing="compact" empty="true">
-				<li><t>- Added Changelog</t></li>
-				<li><t>- Fixed misc. grammatical errors</t></li>
-				<li><t>- Fixed section numbering issue</t></li>
-				<li><t>- Fixed some UUIDvX reference issues</t></li>
-				<li><t>- Changed all instances of "motonic" to "monotonic"</t></li>
-				<li><t>- Changed all instances of "#-bit" to "# bit"</t></li>
-				<li><t>- Changed "proceeding" veriage to "after" in section 7</t></li>
-				<li><t>- Added details on how to pad 32 bit unix timestamp to 36 bits in UUIDv7</t></li>
-				<li><t>- Added details on how to truncate 64 bit unix timestamp to 36 bits in UUIDv7</t></li>
-				<li><t>- Added forward reference and bullet to UUIDv8 if truncating 64 bit Unix Epoch is not an option.</t></li>
-				<li><t>- Fixed bad reference to non-existent "time_or_node" in section 4.5.4</t></li>
-			</ul>
-			<t>draft-01</t>
-			<ul spacing="compact" empty="true">
-				<li><t>- Complete rewrite of entire document.</t></li>
-				<li><t>- The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards.</t></li>
-				<li><t>- Removed the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques.</t></li>
-				<li><t>- Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)</t></li>
-				<li><t>- Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes)</t></li>
-			</ul>
-		</section>
-    </section>
-    <section anchor="format" title="Format">
-        <t>
-		The UUID length of 16 octets (128 bits) remains unchanged. The textual representation of a UUID consisting of 36
-        hexadecimal and dash characters in the format 8-4-4-4-12 remains unchanged for human readability.
-        In addition the position of both the Version and Variant bits remain unchanged in the layout.
-        </t>
-		<section anchor="versions" title="Versions">
 			<t>
-			Table 1 defines the 4 bit version found in Bits 48 through 51 within a given UUID.
+				An inspection of these implementations and the issues described above has led to this document which attempts to adapt UUIDs to address these issues.
 			</t>
-			<table>
-			<name>UUID versions defined by this specification</name>
-			<thead>
-				<tr><td>Msb0</td><td>Msb1</td><td>Msb2</td><td>Msb3</td><td>Version</td><td>Description</td></tr>
-			</thead>
-			<tbody>
-				<tr><td>0</td><td>1</td><td>1</td><td>0</td><td>6</td><td>Reordered Gregorian time-based UUID</td></tr>
-				<tr><td>0</td><td>1</td><td>1</td><td>1</td><td>7</td><td>Variable length Unix Epoch time-based UUID</td></tr>
-				<tr><td>1</td><td>0</td><td>0</td><td>0</td><td>8</td><td>Custom time-based UUID</td></tr>
-			</tbody>
-			</table>
+
 		</section>
-        <section anchor="variant" title="Variant">
-			<t>
-			The variant bits utilized by UUIDs in this specification 
-			remains the same as <xref target="RFC4122" sectionFormat="comma" section="4.1.1"/>. 
-			</t>
-			<t>
-			The Table 2 lists the contents of the variant field, bits 64 and 65,
-			where the letter "x" indicates a "don't-care" value. Common hex values of 
-			8 (1000), 9 (1001), A (1010), and B (1011) frequent the text representation.
-			</t>
-			<table>
-			<name>UUID Variant defined by this specification</name>
-			<thead>
-				<tr><td>Msb0</td><td>Msb1</td><td>Msb2</td><td>Description</td></tr>
-			</thead>
-			<tbody>
-				<tr><td>1</td><td>0</td><td>x</td><td>The variant specified in this document.</td></tr>
-			</tbody>
-			</table>
-        </section>
-        <section anchor="uuidv6layout" title="UUIDv6 Layout and Bit Order">
-			<t>
-			UUIDv6 aims to be the easiest to implement by reusing most of the layout of bits
-			found in UUIDv1 but with changes to bit ordering for the timestamp.
-			Where UUIDv1 splits the timestamp bits into three distinct parts and orders them as
-			time_low, time_mid, time_high_and_version. UUIDv6 instead keeps the source bits
-			from the timestamp intact and changes the order to time_high, time_mid, and time_low.
-			Incidentally this will match the original 60 bit Gregorian timestamp source with 100-nanosecond precision defined in <xref target="RFC4122" sectionFormat="comma" section="4.1.4"/> 
-			The clock sequence bits remain unchanged from their usage and position in <xref target="RFC4122" sectionFormat="comma" section="4.1.5"/>.
-			The 48 bit node SHOULD be set to a pseudo-random value however implementations MAY choose retain the old MAC address behavior from <xref target="RFC4122" sectionFormat="comma" section="4.1.6"/> and <xref target="RFC4122" sectionFormat="comma" section="4.5"/>
-			</t>
+		<section title="Terminology">
+			<section anchor="requirements_language" title="Requirements Language">
+				<t>
+					The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
+				</t>
+			</section>
+			<section anchor="acronyms" title="Abbreviations">
+				<t>The following abbreviations are used in this document: </t>
+				<dl newline="false" spacing="normal" indent="14" pn="section-2.2-2">
+					<dt>UUID</dt><dd>Universally Unique Identifier <xref target="RFC4122"/></dd>
+					<dt>CSPRNG</dt><dd>Cryptographically Secure Pseudo-Random Number Generator</dd>
+					<dt>MAC</dt><dd>Media Access Control</dd>
+					<dt>MSB</dt><dd>Most Significant Bit</dd>
+				</dl>
+			</section>
+		</section>
+		<section anchor="Changes" title="Summary of Changes">
 			<t>
-			The format for the 16-octet, 128 bit UUIDv6 is shown in Figure 1
+				The following UUIDs are hereby introduced:
 			</t>
+
+			<ol spacing="compact">
+				<li><t>UUID version 6: A re-ordering of UUID version 1 so it is sortable as an opaque sequence of bytes.  Easy to implement given an existing UUIDv1 implementation. See <xref target="uuidv6"/></t></li>
+				<li><t>UUID version 7: An entirely new time-based UUID bit layout sourced from the widely implemented and well known Unix Epoch timestamp source. See <xref target="uuidv7"/></t></li>
+				<li><t>UUID version 8: A free-form UUID format which has no explicit requirements except maintaining backward compatibility. See <xref target="uuidv8"/></t></li>
+			</ol>
+
+			<section anchor="changelog" title="changelog">
+				<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t>
+				<t>draft-03</t>
+				<ul spacing="compact" empty="true">
+					<li><t>- Reworked the draft body to make the content more concise</t></li>
+					<li><t>- UUIDv6 section reworked to just the reorder of the timestamp</t></li>
+					<li><t>- UUIDv7 changed to simplify timestamp mechanism to just millisecond unix timestamp</t></li>
+					<li><t>- UUIDv8 relaxed to be custom in all elements except version and variant</t></li>
+					<li><t>- Changed UUIDv7 and UUIDv8 to use Variant 111.</t></li>
+					<li><t>- Added C code samples in Appendix.</t></li>
+					<li><t>- Added test vectors in Appendix.</t></li>
+					<li><t>- Version and Variant section combined into one section.</t></li>
+					<li><t>- Changed from pseudo-random number generators to cryptographically secure pseudo-random number generator (CSPRNG).</t></li>
+					<li><t>- Split Encoding and Storage section into more sections: Text Format and Storing UUIDs, Opacity</t></li>
+					<li><t>- Reworked Global Uniqueness under new section Global and Local Uniqueness</t></li>
+					<li><t>- Combined redundant topics from all UUIDs into sections such as Timestamp granularity, Monotonicity and Counters, Collision Resistance, Sorting, and Unguessability, etc.</t></li>
+					<li><t>- Node verbiage only used in UUIDv6 and v7 and v8 reference random instead</t></li>
+					<li><t>- Clock sequence verbiage changed simply to counter in any section other than UUIDv6</t></li>
+					<li><t>- Added Abbreviations section</t></li>
+					<li><t>- Updated IETF Draft XML Layout</t></li>
+				</ul>
+				<t>draft-02</t>
+				<ul spacing="compact" empty="true">
+					<li><t>- Added Changelog</t></li>
+					<li><t>- Fixed misc. grammatical errors</t></li>
+					<li><t>- Fixed section numbering issue</t></li>
+					<li><t>- Fixed some UUIDvX reference issues</t></li>
+					<li><t>- Changed all instances of "motonic" to "monotonic"</t></li>
+					<li><t>- Changed all instances of "#-bit" to "# bit"</t></li>
+					<li><t>- Changed "proceeding" verbiage to "after" in section 7</t></li>
+					<li><t>- Added details on how to pad 32 bit unix timestamp to 36 bits in UUIDv7</t></li>
+					<li><t>- Added details on how to truncate 64 bit unix timestamp to 36 bits in UUIDv7</t></li>
+					<li><t>- Added forward reference and bullet to UUIDv8 if truncating 64 bit Unix Epoch is not an option.</t></li>
+					<li><t>- Fixed bad reference to non-existent "time_or_node" in section 4.5.4</t></li>
+				</ul>
+				<t>draft-01</t>
+				<ul spacing="compact" empty="true">
+					<li><t>- Complete rewrite of entire document.</t></li>
+					<li><t>- The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards.</t></li>
+					<li><t>- Removed the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques.</t></li>
+					<li><t>- Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)</t></li>
+					<li><t>- Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes)</t></li>
+				</ul>
+			</section>
+		</section>
+		<section anchor="format" title="Format">
+			<t>The UUID format is 16 octets; some bits of the eight octet variant field specified below determine finer structure.</t>
+			<section anchor="variant_and_version_fields" title="Variant and Version Fields">
+				<t>
+				The variant bits utilized by UUIDs in this specification 
+				remain in the same octet as originally defined by <xref target="RFC4122" sectionFormat="comma" section="4.1.1"/>. 
+				</t>
+				<t>For UUIDv6 the version and variant field placement from <xref target="RFC4122"/> are unchanged and a new version (0110b [6]) has been added.				
+				</t>
+				<figure>
+					<name>UUIDv6 Version and Variant Examples</name>
+					<artwork><![CDATA[
+00000000-0000-6000-8000-000000000000
+00000000-0000-6000-9000-000000000000
+00000000-0000-6000-A000-000000000000
+00000000-0000-6000-B000-000000000000
+xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
+					]]></artwork>
+				</figure>
+				<dl newline="false">
+					<dt>M:</dt> <dd>Version (0110b [6])</dd>
+					<dt>N:</dt> <dd>Variant (1000b [8], 1001b [9], 1010b [A] or 1011b [B]) are all valid values</dd>
+				</dl>
+				<t>
+					For UUID versions 7 and 8, the variant field has been incremented and the version field has been moved to the same octet as the variant. Since the bits of the variant remain in the same place as described in <xref target="RFC4122"/> but utilized the previously reserved value 111, this allows a UUID to simply define octet 8 as var_ver, and the values 0xE7 and 0xE8 indicate UUID versions 7 and 8 respectively.
+				</t>
+				<figure>
+					<name>UUIDv7 Version and Variant Examples</name>
+					<artwork><![CDATA[
+00000000-0000-0000-E700-000000000000
+xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+
+00000000-0000-0000-E800-000000000000
+xxxxxxxx-xxxx-xxxx-NMxx-xxxxxxxxxxxx
+					]]></artwork>
+				</figure>
+				<dl newline="false">
+					<dt>N:</dt> <dd>Variant (1110b [E])</dd>
+					<dt>M:</dt> <dd>Version (0111b [7] or 1000 [8])</dd>
+				</dl>
+								
+				<t>
+				While this specification makes use of the unused variant bits of 111 defined in <xref target="RFC4122" sectionFormat="comma" section="4.1.1"/>; the placement of the version within the same octet as the variant leaves room for a future variant.
+				</t>
+				<t>
+				UUID Version 7 and 8 specified by this document MUST set the first 3 bits of octet 8 to 111 and the fourth bit to 0. The 4 bit version MUST follow the variant to fill out the final bits of octet 8.
+				</t>
+				<t>
+				Future specifications that wish to utilize variant 111 for a different version position (or any other bit layout position) MUST set the first 3 bits of octet 8 to 111 and then the fourth bit to 1.
+				</t>
+				<t>
+				As such the tables below detail the three variants and versions described in this document where the letter "x" indicates a "don't-care" value.
+				</t>
+				<table>
+				<name>UUID Variant defined by this specification</name>
+				<thead>
+					<tr><td>Msb0</td><td>Msb1</td><td>Msb2</td><td>Msb3</td><td>Description</td></tr>
+				</thead>
+				<tbody>
+					<tr><td>1</td><td>0</td><td>x</td><td>x</td><td>The variant specified by <xref target="RFC4122"/>. Hex characters 8, 9, A, B.</td></tr>
+					<tr><td>1</td><td>1</td><td>1</td><td>0</td><td>The variant specified in this document. Hex character E,</td></tr>
+					<tr><td>1</td><td>1</td><td>1</td><td>1</td><td>Reserved for future definition. Hex Character F.</td></tr>
+				</tbody>
+				</table>
+
+				<table>
+				<name>UUID versions defined by this specification</name>
+				<thead>
+					<tr><td>Msb0</td><td>Msb1</td><td>Msb2</td><td>Msb3</td><td>Version</td><td>Description</td></tr>
+				</thead>
+				<tbody>
+					<tr><td>0</td><td>1</td><td>1</td><td>0</td><td>6</td><td>Reordered Gregorian time-based UUID</td></tr>
+					<tr><td>0</td><td>1</td><td>1</td><td>1</td><td>7</td><td>Unix Epoch time-based UUID</td></tr>
+					<tr><td>1</td><td>0</td><td>0</td><td>0</td><td>8</td><td>Custom UUID</td></tr>
+				</tbody>
+				</table>
+				
+			</section>
+			<section anchor="uuidv6" title="UUID Version 6">
+				<t>
+					UUID version 6 is a field-compatible version of UUIDv1, reordered for improved DB locality. 
+					It is expected that UUIDv6 will primarily be used in contexts where there are existing v1 UUIDs.
+					Systems that do not involve legacy UUIDv1 SHOULD consider using 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 timestamp value as specified for UUIDv1 in <xref target="RFC4122" sectionFormat="comma" section="4.1.4"/>,
+					for UUIDv6, the first 48 most significant bits are stored
+					first, followed by the 4 bit version (same position), followed by the remaining 12 bits of the original 60 bit timestamp.
+				</t>
+				<t>
+					The clock sequence bits remain unchanged from their usage and position in <xref target="RFC4122" sectionFormat="comma" section="4.1.5"/>.
+				</t>
+				<t>
+					The 48 bit node SHOULD be set to a pseudo-random value however implementations MAY choose retain the old MAC address behavior from <xref target="RFC4122" sectionFormat="comma" section="4.1.6"/> and <xref target="RFC4122" sectionFormat="comma" section="4.5"/>. For more information on MAC address usage within UUIDs see the <xref target="Security"/>
+				</t>
+				<t>
+					The format for the 16-byte, 128 bit UUIDv6 is shown in Figure 1
+				</t>
 <figure>
 <name>UUIDv6 Field and Bit Layout</name>
 <artwork>
@@ -303,43 +339,11 @@
         <dt>node:</dt> <dd>48 bit spatially unique identifier
             Occupies bits 80 through 127 (octets 10-15)</dd>
 		</dl>
-            <section anchor="uuidv6pseudo" title="UUIDv6 Basic Creation Algorithm">
-				<t>
-				The following implementation algorithm is based on <xref target="RFC4122"/>
-				but with changes specific to UUIDv6:
-				</t>
-				<ol>
-					<li><t>From a system-wide shared stable store (e.g., a file) or global variable, read the
-					  UUID generator state: the values of the timestamp and clock sequence
-					  used to generate the last UUID.</t></li>
-					<li><t>Obtain the current time as a 60 bit count of 100-nanosecond intervals
-					  since 00:00:00.00, 15 October 1582.</t></li>
-					<li><t>Set the time_low field to the 12 least significant bits
-					  of the starting 60 bit timestamp.</t></li>
-					<li><t>Truncate the timestamp to the 48 most significant bits
-					  in order to create time_high_and_time_mid.</t></li>
-					<li><t>Set the time_high field to the 32 most significant bits of the truncated timestamp.</t></li>
-					<li><t>Set the time_mid field to the 16 least significant bits of the truncated timestamp.</t></li>
-					<li><t>Create the 16 bit time_low_and_version by concatenating the 4 bit UUIDv6 version
-					  with the 12 bit time_low.</t></li>
-					<li><t>If the state was unavailable (e.g., non-existent or corrupted)
-					  or the timestamp is greater than the current timestamp generate
-					  a random 14 bit clock sequence value.</t></li>
-					<li><t>If the state was available, but the saved timestamp is less than or equal to the current
-					  timestamp, increment the clock sequence value.</t></li>
-					<li><t>Complete the 16 bit clock sequence high, low and reserved creation
-					  by concatenating the clock sequence onto UUID variant bits which take
-					  the most significant position in the 16 bit value.</t></li>
-					<li><t>Generate a 48 bit pseudo-random node.</t></li>
-					<li><t>Format by concatenating the 128 bits from each parts:
-					  time_high|time_mid|time_low_and_version|variant_clk_seq|node</t></li>
-					<li><t>Save the state (current timestamp and clock sequence)
-					  back to the stable store</t></li>
-				</ol>  	
-				<t>
-				The steps for splitting time_high_and_time_mid into time_high and time_mid are optional
-				since the 48 bits of time_high and time_mid will remain in the same order as time_high_and_time_mid
-				during the final concatenation. This extra step of splitting into the most significant
+		
+						<t>
+				With UUIDv6 the steps for splitting the timestamp into time_high and time_mid are optional
+				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.
 				In which the following logic can be applied to reshuffle the bits with minimal modifications.
 				</t>
@@ -354,824 +358,743 @@
 					<tr><td>time_high</td><td>12</td><td>time_low</td></tr>
 				</tbody>
 				</table>
-            </section>
-        </section>
+			</section>
+			<section anchor="uuidv7" title="UUID Version 7">
+				<t>
+					UUID version 7 features a time-ordered value field derived from the widely implemented and well known Unix Epoch timestamp source, as well as improved entropy characteristics over versions 1 or 6.
+					Implementations SHOULD utilize UUID version 7 over UUID version 1 and 6 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           |             rand              |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    var_ver    |            rand_b                             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                            rand_b                             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+					]]></artwork>
 
-		<section anchor="uuidv7layout" title="UUIDv7 Layout and Bit Order">
-			<t>
-			The UUIDv7 format is designed to encode a Unix timestamp with arbitrary sub-second precision.
-			The key property provided by UUIDv7 is that timestamp values generated by one system and parsed by
-			another are guaranteed to have sub-second precision of either the generator or the parser,
-			whichever is less. Additionally, the system parsing the UUIDv7 value does not need to know which precision
-			was used during encoding in order to function correctly.
-			</t>
-			
-			<t>
-			The format for the 16-octet, 128 bit UUIDv7 is shown in Figure 2
-			</t>
-<figure>
-<name>UUIDv7 Field and Bit Layout</name>
-<artwork>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |       subsec_a        |  ver  |       subsec_b        |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|                   subsec_seq_node                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                       subsec_seq_node                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</artwork>
-</figure>
-		<dl newline="true">
-			<dt>unixts:</dt> <dd>36 bit big-endian unsigned Unix Timestamp value</dd>
-			<dt>subsec_a:</dt> <dd>12 bits allocated to sub-second precision values.</dd>
-			<dt>ver:</dt> <dd>The 4 bit UUIDv7 version (0111)</dd>
-			<dt>subsec_b:</dt> <dd>12 bits allocated to sub-second precision values.</dd>
-			<dt>var:</dt> <dd>2 bit UUID variant (10)</dd>
-			<dt>subsec_seq_node:</dt> <dd>The remaining 62 bits which MAY be allocated to any combination of additional sub-second precision, sequence counter, or pseudo-random data.</dd>
-		</dl>
+				</figure>
+
+				<dl newline="true">
+					<dt>unix_ts_ms:</dt> <dd>48 bit big-endian unsigned number of unix epoch timestamp as per <xref target="timestamp_granularity"/></dd>
+					<dt>rand_a:</dt> <dd>16 bits pseudo-random data to provide uniqueness as per <xref target="unguessability"/></dd>
+					<dt>var_ver:</dt> <dd>The 8 bit combined variant and version field with the value 0xE7 as defined by <xref target="variant_and_version_fields"/>.</dd>
+					<dt>rand_b:</dt> <dd>The final 56 bits of pseudo-random data to provide uniqueness as per <xref target="unguessability"/> and <xref target="monotonicity_counters"/>.</dd>
+				</dl>
 
-			<section anchor="uuidv7timestamp" title="UUIDv7 Timestamp Usage">
-				<t>UUIDv7 utilizes a 36 bit big-endian unsigned Unix Timestamp value (number of seconds since the epoch of 1 Jan 1970, leap seconds excluded so each hour is exactly 3600 seconds long). The 36 bit value was selected in order to provide more available time to the unix timestamp and avoid the Year 2038 problem by extending the maximum timestamp to the year 4147.</t>
-				<t>To achieve a 36 bit UUIDv7 timestamp, the lower 36 bits of a 64 bit unix time are extracted verbatim into UUIDv7</t>
-				<t>In the event that 32 bit Unix Timestamp are in use; four zeros MUST be appended at the start in the most significant (left-most) bits of the 32 bit Unix timestamp creating the 36 bit Unix timestamp. This ensures sorting compatibility with 64 bit unix timestamp which have been truncated to 36 bits.</t>
-				<t>Additional sub-second precision (millisecond, nanosecond, microsecond, etc) MAY be provided for encoding and decoding in the remaining bits in the layout.</t>
-				<t>UUIDv8 SHOULD be used in place of UUIDv7 if an application or implementation does not want to truncate a 64 bit Unix Epoch to the lower 36 bits.</t>
 			</section>
-			
-			<section anchor="uuidv7sequence" title="UUIDv7 Clock Sequence Usage">
+			<section anchor="uuidv8" title="UUID Version 8">
 				<t>
-				UUIDv7 SHOULD utilize a monotonic sequence counter to provide additional sequencing guarantees when multiple UUIDv7 values are created in the same UNIXTS and SUBSEC timestamp.
-				The amount of bits allocates to the sequence counter depend on the precision of the timestamp. For example, a more accurate timestamp source using nanosecond precision will require less clock sequence bits than a timestamp source utilizing seconds for precision.
-				For best sequencing results the sequence counter SHOULD be placed immediately after available sub-second bits.
+					UUID version 8 provides an RFC-compatible format for experimental or vendor-specific use cases.
+					The only requirement is that the variant and version bits MUST be set as defined in <xref target="variant_and_version_fields"/>. 
+					UUIDv8's uniqueness will be implementation-specific and should not be assumed.
 				</t>
 				<t>
-				The clock sequence MUST start at zero and increment monotonically
-				for each new UUIDv7 created on by the application on the same timestamp.
-				When the timestamp increments the clock sequence MUST be reset to zero.
-				The clock sequence MUST NOT rollover or reset to zero unless the timestamp
-				has incremented. Care MUST be given to ensure that an adequate sized
-				clock sequence is selected for a given application based on expected
-				timestamp precision and expected UUIDv7 generation rates.
+				UUIDv8 SHOULD only be utilized if an implementation cannot utilize another UUID in this document or <xref target="RFC4122"/>.
 				</t>
-			</section>
-			
-			<section anchor="uuidv7node" title="UUIDv7 Node Usage">
 				<t>
-				UUIDv7 implementations, even with very detailed sub-second precision and the optional sequence counter, MAY have leftover bits that will be identified as the Node for this section.
-				The UUIDv7 Node MAY contain any set of data an implementation desires however the node MUST NOT be set to all 0s which does not ensure global uniqueness. In most scenarios the node SHOULD be filled with pseudo-random data.
+				The only explicitly defined bits are the Version and Variant leaving 120 bits
+				for implementation specific time-based UUIDs. To be clear:
+				UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
+				filled with random data.
 				</t>
-			</section>
-
-			<section anchor="uuidv7encodingdecoding" title="UUIDv7 Encoding and Decoding">
 				<t>
-					The UUIDv7 bit layout for encoding and decoding are described separately in this document.
+				Some example situations in which UUIDv8 usage could occur:
 				</t>
-				<section anchor="uuidv7encoding" title="UUIDv7 Encoding">
-					<t>
-					 Since the UUIDv7 Unix timestamp is fixed at 36 bits in length the exact layout for encoding UUIDv7 depends on the precision (number of bits)
-					 used for the sub-second portion and the sizes of the optionally desired sequence counter and node bits.
-					</t>
-					<t>
-						Three examples of UUIDv7 encoding are given below as a general guidelines but implementations are not limited to just these three examples.
-					</t>
-					<t>
-						All of these fields are only used during encoding, and during decoding the system is unaware of the bit layout used for them and considers this information opaque.
-						As such, implementations generating these values can assign whatever lengths to each field it deems applicable, as long as it does not break decoding compatibility
-						(i.e. Unix timestamp (unixts), version (ver) and variant (var) have to stay where they are, and clock sequence counter (seq), random (random) or other implementation specific values must follow the sub-second encoding).
-					</t>
-					<t>
-						In Figure 3 the UUIDv7 has been created with millisecond precision with the available sub-second precision bits.
-					</t>
-					<t>
-						Examining Figure 3 one can observe: 
-					</t>
-					<ul>
-						<li><t>The first 36 bits have been dedicated to the Unix Timestamp (unixts)</t></li>
-						<li><t>All 12 bits of scenario subsec_a is fully dedicated to millisecond information (msec).</t></li>
-						<li><t>The 4 Version bits remain unchanged (ver).</t></li>
-						<li><t>All 12 bits of subsec_b have been dedicated to a monotonic clock sequence counter (seq).</t></li>
-						<li><t>The 2 Variant bits remain unchanged (var).</t></li>
-						<li><t>Finally the remaining 62 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).</t></li>
-					</ul>
-<figure>
-<name>UUIDv7 Field and Bit Layout - Encoding Example (Millisecond Precision)</name>
-<artwork>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         msec          |  ver  |          seq          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|                         rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</artwork>
-</figure>
-
-					<t>
-						In Figure 4 the UUIDv7 has been created with Microsecond precision with the available sub-second precision bits.
-					</t>
-					<t>
-						Examining Figure 4 one can observe: 
-					</t>
-					<ul>
-						<li><t>The first 36 bits have been dedicated to the Unix Timestamp (unixts)</t></li>
-						<li><t>All 12 bits of scenario subsec_a is fully dedicated to providing sub-second encoding for the Microsecond precision (usec).</t></li>
-						<li><t>The 4 Version bits remain unchanged (ver).</t></li>
-						<li><t>All 12 bits of subsec_b have been dedicated to providing sub-second encoding for the Microsecond precision (usec).</t></li>
-						<li><t>The 2 Variant bits remain unchanged (var).</t></li>
-						<li><t>A 14 bit monotonic clock sequence counter (seq) has been embedded in the most significant position of subsec_seq_node </t></li>
-						<li><t>Finally the remaining 48 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).</t></li>
-					</ul>
+				<ul>
+					<li><t>An implementation would like to embed extra information
+					  within the UUID other than what is defined in this document.</t></li>
+					<li><t>An implementation has other application/language restrictions which
+					  inhibit the use of one of the current UUIDs.</t></li>
+				</ul>
+				<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                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    var_ver    |           custom_b                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           custom_b                            |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+					]]></artwork>
 
-<figure>
-<name>UUIDv7 Field and Bit Layout - Encoding Example (Microsecond Precision)</name>
-<artwork>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         usec          |  ver  |         usec          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|             seq           |            rand               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</artwork>
-</figure>
-
-					<t>
-						In Figure 5 the UUIDv7 has been created with Nanosecond precision with the available sub-second precision bits.
-					</t>
-					<t>
-						Examining Figure 5 one can observe: 
-					</t>
-					<ul>
-						<li><t>The first 36 bits have been dedicated to the Unix Timestamp (unixts)</t></li>
-						<li><t>All 12 bits of scenario subsec_a is fully dedicated to providing sub-second encoding for the Nanosecond precision (nsec).</t></li>
-						<li><t>The 4 Version bits remain unchanged (ver).</t></li>
-						<li><t>All 12 bits of subsec_b have been dedicated to providing sub-second encoding for the Nanosecond precision (nsec).</t></li>
-						<li><t>The 2 Variant bits remain unchanged (var).</t></li>
-						<li><t>The first 14 bit of the subsec_seq_node dedicated to providing sub-second encoding for the Nanosecond precision (nsec).</t></li>
-						<li><t>The next 8 bits of subsec_seq_node dedicated a monotonic clock sequence counter (seq).</t></li>
-						<li><t>Finally the remaining 40 bits in the subsec_seq_node section are layout is filled out with random data to pad the length and provide guaranteed uniqueness (rand).</t></li>
-					</ul>
+				</figure>
+				<dl newline="true">
+					<dt>custom_a:</dt> <dd>The first 64 bits of the layout that can be filled as an implementation sees fit.</dd>
+					<dt>var_ver:</dt> <dd>The 8 bit combined variant and version field with the value 0xE8 as defined by <xref target="variant_and_version_fields"/>.</dd>
+					<dt>custom_b:</dt> <dd>The final 56 bits of the layout immediatly following the var_var field to be filled as an implementation sees fit.</dd>
+				</dl>
+			</section>			
+		</section>
 
-<figure>
-<name>UUIDv7 Field and Bit Layout - Encoding Example (Nanosecond Precision)</name>
-<artwork>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                            unixts                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |unixts |         nsec          |  ver  |         nsec          |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|             nsec          |      seq      |     rand      |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                             rand                              |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</artwork>
-</figure>
+		<section anchor="uuid_best_practices" title="UUID Best Practices">
+				<t>
+					The minimum requirements for generating UUIDs are 
+					described in this document for each version.
+					Everything else is an implementation detail and 
+					up to the implementer to decide what is appropriate for a given 
+					implementation. That being said, various relevant factors are covered
+					below to help guide an implementer through the different trade-offs among differing UUID implementations.
+				</t>
 
+			<section anchor="timestamp_granularity" title="Timestamp Granularity">
+				<t>
+					UUID timestamp source, precision and length was the topic of great debate while creating this specification. As such choosing the right timestamp for your application is a very important topic. This section will detail some of the most common points on this topic.
+				</t>
+				<dl newline="true">
+					<dt>Reliability:</dt>
+						<dd>Implementations SHOULD use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing. Care SHOULD be taken to ensure the timestamp does not move backwards which will impact UUID sorting.</dd>
+					<dt>Source:</dt>
+						<dd>UUID version 1 and 6 both utilize a Gregorian epoch timestamp while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp sources or a custom timestamp epoch are required UUIDv8 SHOULD be leveraged.</dd>
+					<dt>Sub-second Precision and Accuracy:</dt>
+						<dd>Many levels of precision exist for timestamps: milliseconds, microseconds, nanoseconds, and beyond. Additionally fractional representations of sub-second precision may be desired to mix various levels of precision in a time-ordered manner. With UUID version 1 and 6, 100-nanoseconds of precision are present while UUIDv7 features fixed millisecond level of precision within the Unix epoch. If additional levels of precision are required UUIDv8 SHOULD be utilized.</dd>
+					<dt>Length:</dt>
+						<dd>The length of a given timestamp directly impacts how long a given UUID will be valid. Care should be given to ensure that the proper length is selected for a given timestamp. UUID version 1 and 6 utilize a 60 bit timestamp and UUIDv7 features a 48 bit timestamp.</dd>
+					<dt>Fuzzing:</dt>
+						<dd>Implementations MAY fuzz a timestamp. Some examples included security considerations around providing a real clock value within a UUID or to correct inaccurate clocks. This specification makes no requirement or guarantee about how close the clock value needs to be to actual time.</dd>
+					<dt>Padding:</dt>
+						<dd>When timestamp padding is required, implementations MUST pad the most significant bits (left-most) bits with zeros. An example is padding the most significant, left-most bits of a 32 bit unix timestamp with zero's to fill out the 48 bit timestamp in UUIDv7.</dd>
+					<dt>Truncating:</dt>
+						<dd>Similarly, when timestamps need to be truncated: the lower, least significant bits MUST be used. An example would be truncating a 64 bit unix timestamp to the least significant, right-most 48 bits for UUIDv7.</dd>
+				</dl>
 			</section>
-			<section anchor="uuidv7decoding" title="UUIDv7 Decoding">
+			<section anchor="monotonicity_counters" title="Monotonicity and Counters">
 				<t>
-					When decoding or parsing a UUIDv7 value there are only two values to be considered:
+					Monotonicity is the backbone of time-based sortable UUIDs. Naturally 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>
-				<ol>
-					<li><t>The unix timestamp defined as unixts</t></li>
-					<li><t>The sub-second precision values defined as subsec_a, subsec_b, and subsec_seq_node</t></li>
-				</ol>
-				<t>As detailed in Figure 2 the unix timestamp (unixts) is always the first 36 bits of the UUIDv7 layout.</t>
 				<t>
-					Similarly as per Figure 2, the sub-second precision values lie within subsec_a, subsec_b, and subsec_seq_node which are all interpreted as sub-second information after skipping over the version (ver) and (var) bits.  
-					These concatenated sub-second information bits are interpreted in a way where most to least significant bits represent a further division by two.
-					This is the same normal place notation used to express fractional numbers, except in binary. For example, in decimal ".1" means one tenth, and ".01" means one hundredth.
-					In this subsec field, a 1 means one half, 01 means one quarter, 001 is one eighth, etc.
-					This scheme can work for any number of bits up to the maximum available, and keeps the most significant data leftmost in the bit sequence.
+					Additionally, care MUST be taken to ensure UUIDs generated in batches are also monotonic. That is, if one-thousand UUIDs are generated for the same timestamp; there is sufficient logic for organizing the creation of order of those one-thousand UUIDs.
+					For batch UUID creation implements MAY utilize a monotonic counter which SHOULD increment for each UUID created during a given timestamp. 
 				</t>
 				<t>
-					To perform the sub-second math, simply take the first (most significant/leftmost) N bits of subsec and divide it by 2^N. Take for example:
+					For single-node UUID implementations that do not need to create batches of UUIDs, the embedded timestamp within UUID version 1, 6, and 7 can provide sufficient monotonicity guarantees by simply ensuring that timestamp increments before creating a new UUID. For the topic of Distributed Nodes please refer to <xref target="distributed_shared_knowledge"/>
 				</t>
-				<ol>
-						<li><t>To parse the first 16 bits, extract that value as an integer and divide it by 65536 (2 to the 16th).</t></li>
-						<li><t>If these 16 bits are 0101 0101 0101 0101, then treating that as an integer gives 0x5555 or 21845 in decimal, and dividing by 65536 gives 0.3333282</t></li>
-				</ol>		
 				<t>
-				This sub-second encoding scheme provides maximum interoperability across systems where different levels of time precision are required/feasible/available.
-				The timestamp value derived from a UUIDv7 value SHOULD be "as close to the correct value as possible" when parsed, even across disparate systems. 
+					The following methods SHOULD be employed for single-node UUID implementations that do require batch UUID creation.
 				</t>
+				<dl newline="true">
+					<dt>Fixed-Length Dedicated Counter Bits (Position A):</dt> 
+						<dd>
+						This references the practice of allocating 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.
+						Positioning of a fixed bit-length counter SHOULD be immediatly after the embedded timestamp. This promotes sortability and allows random data generation for each counter increment. UUIDs utilizing this method should be created using UUIDv8.
+						</dd>
+					<dt>Fixed-Length Dedicated Counter Bits (Position B):</dt> 
+						<dd>
+						An alternative approach to the previous method is to dedicate a number of bits in the least significant position of the UUID. With this alternative method, the random data MUST be frozen for a given timestamp tick else sorting will be impacted. UUIDs utilizing this method should be created using UUIDv8.
+						</dd>
+					<dt>Fixed-Length Dedicated Counter Seeding:</dt> 
+						<dd>
+						Implementations utilizing fixed-length counter bits SHOULD initialize the counter at zero to ensure the full bit-space is utilized and help avoid counter rollovers.
+						</dd>
+					<dt>Fixed-Length Dedicated Counter Length</dt>
+						<dd>Care MUST be taken to select a counter bit-length that can properly handle the level of timestamp precision in use. For example, millisecond precision SHOULD require a larger counter than a timestamp with nanosecond precision. General Guidance is that the counter SHOULD be at least 12 bits and no more than a maximum of 24 bits.</dd>
+					<dt>Fixed-Length Dedicated Counter Rollover Handling</dt>
+						<dd>
+						Counter rollovers SHOULD be handled by the application to avoid sorting issues. The general guidance is that applications should freeze the counter and wait for the timestamp to advance which ensures monotonicity is not broken.
+						</dd>
+					<dt>Monotonic Random:</dt> 
+						<dd>
+						With this method the random data is extended to also double as a counter. This monotonic random can be thought of as a "randomly seeded counter" which MUST be incremented in the least significant position for each UUID created on a given timestamp tick. This is similar to the Fixed-Length Dedicated Counter Bits (Position B) method described in the previous bullets but does not suffer from rollover issues, length problems, or wasted entropy bits plagued by both fixed-length counter bit positions. As such, UUIDv7 SHOULD utilize this method to handle batch UUID generation during a single timestamp tick.
+						</dd>
+				</dl>
 				<t>
-				Take for example the starting point for our next two UUIDv7 parsing scenarios:
+					Implementations MAY use the following logic to ensure UUIDs featuring embedded counters are monotonic in nature:
 				</t>
-				<ol>
-					<li>System A produces a UUIDv7 with a microsecond-precise timestamp value.</li>
-					<li>System B is unaware of the precision encoded in the UUIDv7 timestamp by System A.</li>
+				<ol spacing="compact">
+					<li><t>Compare the current timestamp against the previously stored timestamp.</t></li>
+					<li>
+						<t>If the current timestamp is equal to the previous timestamp; increment desired counter logic.</t>
+					</li>
+					<li><t>If the current timestamp is greater than the previous timestamp; re-initialize the counter 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></li>
 				</ol>
 				<t>
-				Scenario 1:
+					Implementations SHOULD check if the the currently generated UUID is greater than the previously generated UUID. If this is not the case then any number of things could have occurred. Such as, but not limited to, clock rollbacks or counter rollovers. Applications SHOULD embed sufficient logic to catch these scenarios and correct the problem ensuring the next UUID generated is greater than the previous.
+				</t>		
+				<t>
+					UUIDv1, and by extension UUIDv6, utilize a slightly different counter in the form of "clock sequence" bits. The usage of the clock sequence will remain as defined in <xref target="RFC4122" sectionFormat="comma" section="4.1.5"/>.
 				</t>
-				<ol>
-					<li>System B parses the embedded timestamp with millisecond precision. (Less precision than the encoder)</li>
-					<li>System B SHOULD return the correct millisecond value encoded by system A (truncated to milliseconds).</li>
-				</ol>
+			</section>
+			<section anchor="distributed_shared_knowledge" title="Distributed UUID Generation">
 				<t>
-				Scenario 2:
+				Some implementations MAY desire to utilize multi-node, clustered, applications which involve two or more 
+				applications 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 nodes increase; so does the likelihood of a collision. 
+				This section will detail the approaches that MAY be utilized by multi-node UUID implementations in distributed environments.
+				</t>
+				<dl newline="true">
+					<dt>Shared Knowledge System:</dt> 
+						<dd>With this 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. Utilization of shared knowledge schemes with central/global registries is outside the scope of this specification.</dd>
+					<dt>Node IDs:</dt> 
+						<dd>With this method, a nondescript pseudo-random Node ID value is placed within the UUID layout. This identifier ensures the 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 SHOULD utilize UUIDv8. The node id SHOULD NOT be an IEEE 802 MAC address as per <xref target="Security"/>. The location and bit length are up to implements and outside the scope of this specification. Furthermore, the creation and negotiation of a node id among distributed nodes is also out of scope for this specification.</dd>
+				</dl>
+				<t>
+					Utilization of either a shared knowledge scheme or Node ID are not required for implementing UUIDs in this specification. However implementations SHOULD utilize one of the two aforementioned methods if distributed UUID generation is a requirements.
+				</t>
+			</section>
+			<section anchor="collision_resistance" title="Collision Resistance">
+				<t>
+					Implementations SHOULD weigh the importance of a collision within their application and take this into account when making a selections around the total entropy (random) to dedicated to a UUID layout versus the other components such as <xref target="timestamp_granularity"/> and <xref target="monotonicity_counters"/>. 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 help illustrate the varying seriousness of a collision within an application.
+				</t>
+				<dl newline="true">
+					<dt>Low Impact</dt> 
+						<dd>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.</dd>
+					<dt>High Impact:</dt> 
+						<dd> A duplicate key causes an airplane to receive the wrong course which puts people's lives at risk. In this scenario there is no margin for error. Collisions MUST be avoided and failure is unacceptable. As such applications dealing with this type of scenario MUST employ as much collision resistance as possible within the given application context.</dd>
+				</dl>
+			</section>
+			<section anchor="global_local_uniqueness" title="Global and Local Uniqueness">
+				<t>
+					UUIDs created by this specification MAY be used to provide local uniqueness guarantees. 
+					For example, ensuring UUIDs created within a local application context are unique within a database MAY 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 shared knowledge scheme; a shared knowledge scheme is not required by UUID to provide uniqueness guarantees.
+					Implementations MAY implement a shared knowledge scheme introduced in <xref target="distributed_shared_knowledge"/> as they see fit to extend the uniqueness guaranteed this specification and <xref target="RFC4122"/>.
+				</t>
+			</section>
+			<section anchor="unguessability" title="Unguessability">
+				<t>
+					Implementations SHOULD utilize a cryptographically secure pseudo-random number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique").
+					CSPRNG ensures the best of <xref target="collision_resistance"/> and <xref target="Security"/> are present in modern UUIDs.
+				</t>
+			</section>
+			<section anchor="sorting" title="Sorting">
+				<t>
+					UUIDv6 and UUIDv7 are designed so that implementations that require sorting (e.g. database indexes) SHOULD sort as opaque raw bytes, without examining the contents at all.
+				</t>
+				<t>
+					Time ordered monotonic UUIDs benefit from greater index locality because the new values are near each other in the index. 
+					As a result objects can much more easily be clustered together for better performance.  
+					The real-world differences in this approach of index locality vs random data inserts can be quite large.
+				</t>
+			</section>
+			<section anchor="storing_uuids_opacity" title="Storing UUIDs, Opacity">
+				<t>
+				For many applications, such as databases, storing UUIDs as the text is unnecessarily verbose totaling 288 bits to convey the 128 bit UUID value.
+				Due to the this, where possible, UUIDs SHOULD be stored within database applications as the underlying 128 bit binary value. 
+				</t>
+				<ul spacing="compact">
+					<li><t>8 bits for each of the 32 hex characters = 256 bits</t></li>
+					<li><t>8 bits for each of the 4 hyphens = 32 bits</t></li>
+				</ul>
+				<t>
+					
+					For other systems, UUIDs MAY be stored in binary form or as text, as appropriate. 
+					The trade offs to both approaches are as such:				
+				</t>
+				<ul spacing="compact">
+					<li><t>Storing as binary requires less space and may result in faster data access.</t></li>
+					<li><t>Storing as text requires more space but may require less translation if the resulting text form is to be used after retrieval and thus maybe simpler to implement. </t></li>
+				</ul>
+				<t>
+					UUIDs SHOULD be treated as opaque values and implementations SHOULD NOT examine the bits in a UUID to whatever extent is possible.
+				</t>
+				<t>
+					Where necessary, the version number may be extracted by first verifying the variant field bits 64 and 65 contain 1 and 0 respectively, and then extract the version from bits 48 through 51.
+					UUID versions 7 and 8 can be identified by checking octet 8 for the values 0xE7 or 0xE8 respectively.
+					The version number can then be used to inspect the remainder of the UUID according to the specification for that version.
+					See <xref target="variant_and_version_fields"/> for more information on determining a UUID version based on the inspected variant bits.
 				</t>
-				<ol>
-					<li>System B parses the timestamp with nanosecond precision. (More precision than the encoder)</li>
-					<li>System B's value returned SHOULD have the same microsecond level of precision provided by the encoder with the additional precision down to nanosecond level being essentially random as per the encoded random value at the end of the UUIDv7.</li>
-				</ol>
-
 			</section>
 		</section>
-	</section>
-        <section anchor="uuidv8layout" title="UUIDv8 Layout and Bit Order">
-		<t>
-        UUIDv8 offers variable-size timestamp, clock sequence, and node values
-        which allow for a highly customizable UUID that fits a given application needs.
-		</t>
-		<t>
-        UUIDv8 SHOULD only be utilized if an implementation cannot utilize UUIDv1, UUIDv6, or UUIDv7.
-        Some situations in which UUIDv8 usage could occur:
-		</t>
-		<ul>
-            <li><t>An implementation would like to utilize a timestamp source
-              not defined by the current time-based UUIDs.</t></li>
-            <li><t>An implementation would like to utilize a timestamp bit layout
-              not defined by the current time-based UUIDs.</t></li>
-			<li><t>An implementation would like to avoid truncating a 64 bit Unix to 36 bits as defined by UUIDv7.</t></li>
-            <li><t>An implementation would like a specific level of precision
-              within the timestamp not offered by current time-based UUIDs.</t></li>
-            <li><t>An implementation would like to embed extra information
-              within the UUID node other than what is defined in this document.</t></li>
-            <li><t>An implementation has other application/language restrictions which
-              inhibit the usage of one of the current time-based UUIDs.</t></li>
-		</ul>
-		<t>
-        Roughly speaking a properly formatted UUIDv8 SHOULD contain
-        the following sections adding up to a total of 128 bits.
-		</t>
-		<ul spacing="compact" empty="true">
-            <li><t>- Timestamp Bits (Variable Length)</t></li>
-            <li><t>- Clock Sequence Bits (Variable Length)</t></li>
-            <li><t>- Node Bits (Variable Length)</t></li>
-            <li><t>- UUIDv8 Version Bits (4 bits)</t></li>
-            <li><t>- UUID Variant Bits (2 Bits)</t></li>
-		</ul>
-		<t>
-        The only explicitly defined bits are the Version and Variant leaving 122 bits
-        for implementation specific time-based UUIDs. To be clear:
-        UUIDv8 is not a replacement for UUIDv4 where all 122 extra bits are
-        filled with random data. UUIDv8's 128 bits (including the version and variant)
-        SHOULD contain at the minimum a timestamp of some format in the most
-        significant bit position followed directly by a clock sequence counter
-        and finally a node containing either random data or implementation specific data.
-		</t>
-		<t>
-        A sample format in Figure 6 is used to further illustrate the point
-        for the 16-octet, 128 bit UUIDv8.
-		</t>
-<figure>
-<name>UUIDv8 Field and Bit Layout</name>
-<artwork>
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                          timestamp_32                         |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |           timestamp_48        |  ver  |      time_or_seq      |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |var|  seq_or_node  |          node                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                              node                             |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-</artwork></figure>
-		<dl newline="true">
-        <dt>timestamp_32:</dt> <dd>The most significant 32 bits of the desired timestamp source.
-            Occupies bits 0 through 31 (octets 0-3).</dd>
-        <dt>timestamp_48:</dt> <dd>The next 16 bits of the timestamp source when a timestamp
-            source with at least 48 bits is used. When a 32 bit timestamp source
-            is utilized, these bits are set to 0. Occupies bits 32 through 47</dd>
-        <dt>ver:</dt> <dd>The 4 bit UUIDv8 version (1000). Occupies bits 48 through 51.</dd>
-        <dt>time_or_seq:</dt> <dd>If a 60 bit, or larger, timestamp is used these 12 bits are used to
-            fill out the remaining timestamp. If a 32 or 48 bit timestamp
-            is leveraged a 12 bit clock sequence MAY be used. 
-			Together ver and time_or_seq occupy bits 48 through 63 (octets 6-7)</dd>
-        <dt>var:</dt> <dd>2 bit UUID variant (10)</dd>
-        <dt>seq_or_node:</dt> <dd>If a 60 bit, or larger, timestamp source is leverages these 8 bits
-            SHOULD be allocated for an 8 bit clock sequence counter. If
-            a 32 or 48 bit timestamp source is used these 8 bits SHOULD be set to random.</dd>
-        <dt>node:</dt> <dd>In most implementations these bits will likely be set to
-            pseudo-random data. However, implementations utilize the node as they see fit.
-            Together var, seq_or_node, and node occupy Bits 64 through 127 (octets 8-15)</dd>
-		</dl>
-            <section anchor="uuidv8timestamp" title="UUIDv8 Timestamp Usage">
-			<t>
-            UUIDv8's usage of timestamp relaxes both the timestamp source
-            and timestamp length. Implementations are free to utilize
-            any monotonically stable timestamp source for UUIDv8.
-			</t>
-			<t>
-            Some examples include:
-			</t>
-			<ul spacing="compact"  empty="true">
-                <li><t>- Custom Epoch</t></li>
-                <li><t>- NTP timestamp</t></li>
-                <li><t>- ISO 8601 timestamp</t></li>
-                <li><t>- Full, Non-truncated 64 bit Unix Epoch timestamp</t></li>
-			</ul>
-			<t>
-            The relaxed nature UUIDv8 timestamps also works to future proof
-            this specification and allow implementations a method to create
-            compliant time-based UUIDs using timestamp source that might not yet be defined.
-			</t>
-			<t>
-            Timestamps come in many sizes and UUIDv8 defines three fields
-            that can easily used for the majority of timestamp lengths:
-			</t>
-			<ul>
-                <li><t>32 bit timestamp: using timestamp_32 and setting timestamp_48 to 0s</t></li>
-                <li><t>48 bit timestamp: using timestamp_32 and timestamp_48 entirely</t></li>
-                <li><t>60 bit timestamp: using timestamp_32, timestamp_48, and time_or_seq</t></li>
-                <li><t>64 bit timestamp: using timestamp_32, timestamp_48, and time_or_seq
-                  and truncating the timestamp the 60 most significant bits.</t></li>
-			</ul>
-			<t>
-            Although it is possible to create a timestamp larger than 64 bits in size
-            The usage and bit layout of that timestamp format is up to the implementation.
-            When a timestamp exceeds the 64th bit (octet 7), extra care must be taken to
-            ensure the Variant bits are properly inserted at their respective location
-            in the UUID. Likewise, the Version MUST always be implemented at the appropriate
-            location.
-			</t>
-			<t>
-            Any timestamps that does not entirely fill the timestamp_32, timestamp_48
-            or time_or_seq MUST set all leftover bits in the least significant position
-            of the respective field to 0. For example a 36 bit timestamp source would
-            fully utilize timestamp_32 and 4 bits of timestamp_48.
-            The remaining 12 bits in timestamp_48 MUST be set to 0.
-			</t>
-			<t>
-            By using implementation-specific timestamp sources it is not
-            guaranteed that devices outside of the application context are able to
-            extract and parse the timestamp from UUIDv8 without some pre-existing
-            knowledge of the source timestamp used by the UUIDv8 implementation.
-			</t>
-            </section>
-            <section anchor="uuidv8sequence" title="UUIDv8 Clock Sequence Usage">
-			<t>
-            A clock sequence MUST be used with UUIDv8 as added sequencing guarantees
-            when multiple UUIDv8 will be created on the same clock tick.
-            The amount of bits allocated to the clock sequence depends on the
-            precision of the timestamp source. For example, a more accurate timestamp source using
-            nanosecond precision will require less clock sequence bits than a timestamp
-            source utilizing seconds for precision.
-			</t>
-			<t>
-            The UUIDv8 layout in Figure 6 generically defines two possible
-            clock sequence values that can leveraged:
-			</t>
-			<ul spacing="compact">
-                <li><t>12 bit clock sequence using time_or_seq for use when the timestamp
-                  is less than 48 bits which allows for 4095 UUIDs per clock tick.</t></li>
-                <li><t>8 bit clock sequence using seq_or_node when the timestamp uses
-                  more than 48 bits which allows for 255 UUIDs per clock tick.</t></li>
-			</ul>
-			<t>
-            An implementation MAY use both time_or_seq and seq_or_node for clock sequencing
-            however it is highly unlikely that 20 bits of clock sequence are needed
-            for a given clock tick. Furthermore, more bits from the node MAY be used
-            for clock sequencing in the event that 8 bits is not sufficient.
-			</t>
-			<t>
-            The clock sequence MUST start at zero and increment monotonically
-            for each new UUIDv8 created on by the application on the same timestamp.
-            When the timestamp increments the clock sequence MUST be reset to zero.
-            The clock sequence MUST NOT rollover or reset to zero unless the timestamp
-            has incremented. Care MUST be given to ensure that an adequate sized
-            clock sequence is selected for a given application based on expected
-            timestamp precision and expected UUIDv8 generation rates.
-			</t>
-            </section>
-            <section anchor="uuidv8node" title="UUIDv8 Node Usage">
-			<t>
-            The UUIDv8 Node MAY contain any set of data an implementation desires however
-            the node MUST NOT be set to all 0s which does not ensure global uniqueness.
-            In most scenarios the node will be filled with pseudo-random data.
-			</t>
-			<t>
-            The UUIDv8 layout in Figure 6 defines 2 sizes of Node
-            depending on the timestamp size:
-			</t>
-			<ul spacing="compact">
-                <li><t>62 bit node encompassing seq_or_node and node
-                  Used when a timestamp of 48 bits or less is leveraged.</t></li>
-                <li><t>54 bit node when all 60 bits of the timestamp are
-                  in use and the seq_or_node is used as clock sequencing.</t></li>
-			</ul>
-			<t>
-            An implementation MAY choose to allocate bits from the node to the timestamp,
-            clock sequence or application-specific embedded field.
-            It is recommended that implementation utilize a node of at least 48 bits to
-            ensure global uniqueness can be guaranteed.
-			</t>
-            </section>
-            <section anchor="uuidv8pseudo" title="UUIDv8 Basic Creation Algorithm">
-			<t>
-            The entire usage of UUIDv8 is meant to be variable
-            and allow as much customization as possible to meet
-            specific application/language requirements.
-            As such any UUIDv8 implementations will likely vary among applications.
-			</t>
-			<t>
-            The following algorithm is a generic implementation using Figure 6
-            and the recommendations outlined in this specification.
-			</t>
-			<t>
-            <strong>32 bit timestamp, 12 bit sequence counter, 62 bit node:</strong>
-			</t>
-			<ol>
-				<li><t>From a system-wide shared stable store (e.g., a file) or global variable,
-				  read the UUID generator state: the values of the timestamp
-				  and clock sequence used to generate the last UUID.</t></li>
-				<li><t>Obtain the current time from the selected clock source as 32 bits.</t></li>
-				<li><t>Set the 32 bit field timestamp_32 to the 32 bits from the timestamp</t></li>
-				<li><t>Set 16 bit timestamp_48 to all 0s</t></li>
-				<li><t>Set the version to 8 (1000)</t></li>
-				<li><t>If the state was unavailable (e.g., non-existent or corrupted) or
-				  the timestamp is greater than the current timestamp;
-				  set the 12 bit clock sequence value (time_or_seq) to 0</t></li>
-				<li><t>If the state was available, but the saved timestamp is less than
-				  or equal to the current timestamp, increment the clock sequence
-				  value (time_or_seq).</t></li>
-				<li><t>Set the variant to binary 10</t></li>
-				<li><t>Generate 62 random bits and fill in 8 bits for seq_or_node and
-				  54 bits for the node.</t></li>
-				<li><t>Format by concatenating the 128 bits as:
-				  timestamp_32|timestamp_48|version|time_or_seq|variant|seq_or_node|node</t></li>
-				<li><t>Save the state (current timestamp and clock sequence)
-				  back to the stable store</t></li>
-			</ol>
-			<t>
-            <strong>48 bit timestamp, 12 bit sequence counter, 62 bit node:</strong>
-			</t>
-			<ol>
-				<li><t>From a system-wide shared stable store (e.g., a file) or global variable,
-				  read the UUID generator state: the values of the timestamp
-				  and clock sequence used to generate the last UUID.</t></li>
-				<li><t>Obtain the current time from the selected clock source as 32 bits.</t></li>
-				<li><t>Set the 32 bit field timestamp_32 to the 32 most significant bits
-				  from the timestamp</t></li>
-				<li><t>Set 16 bit timestamp_48 to the 16 least significant bits
-				  from the timestamp</t></li>
-				<li><t>The rest of the steps are the same as the previous example.</t></li>
-			</ol>
-			<t>
-            <strong>60 bit timestamp, 8 bit sequence counter, 54 bit node:</strong>
+		<section anchor="IANA" title="IANA Considerations">
+			<t>This document has no IANA actions.</t>
+		</section>
+
+		<section anchor="Security" title="Security Considerations">
+			<t> 
+				MAC addresses pose inherent security risks and SHOULD not be used within a UUID. 
+				Instead CSPRNG data SHOULD selected from a source with sufficient entropy to ensure guaranteed
+				uniqueness among UUID generation. See <xref target="unguessability"/> for more information. 
 			</t>
-			<ol>
-				<li><t>From a system-wide shared stable store (e.g., a file) or global variable,
-				  read the UUID generator state: the values of the timestamp
-				  and clock sequence used to generate the last UUID.</t></li>
-				<li><t>Obtain the current time from the selected clock source as 32 bits.</t></li>
-				<li><t>Set the 32 bit field timestamp_32 to the 32 bits from the timestamp</t></li>
-				<li><t>Set 16 bit timestamp_48 to the 16 middle bits from the timestamp</t></li>
-				<li><t>Set the version to 8 (1000)</t></li>
-				<li><t>Set 12 bit time_or_seq to the 12 least significant bits from the timestamp</t></li>
-				<li><t>Set the variant to 10</t></li>
-				<li><t>If the state was unavailable (e.g., non-existent or corrupted)
-				  or the timestamp is greater than the current timestamp;
-				  set the 12 bit clock sequence value (seq_or_node) to 0</t></li>
-				<li><t>If the state was available, but the saved timestamp is less than
-				  or equal to the current timestamp, increment the clock sequence
-				  value (seq_or_node).</t></li>
-				<li><t>Generate 54 random bits and fill in the node</t></li>
-				<li><t>Format by concatenating the 128 bits as:
-				  timestamp_32|timestamp_48|version|time_or_seq|variant|seq_or_node|node</t></li>
-				<li><t>Save the state (current timestamp and clock sequence) back to the stable store</t></li>
-			</ol>
 			<t>
-            <strong>64 bit timestamp, 8 bit sequence counter, 54 bit node:</strong>
+				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 it's 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 then <xref target="RFC4122"/> UUIDv4 SHOULD be utilized.
 			</t>
-			<ol>
-				<li><t>The same steps as the 60 bit timestamp can be utilized
-				  if the 64 bit timestamp is truncated to 60 bits.</t></li>
-				<li><t>Implementations MAY chose to truncate the most or least significant
-				  bits but it is recommended to utilize the most significant 60 bits
-				  and lose 4 bits of precision in the nanoseconds or microseconds position.</t></li>
-			</ol>
-			<t>
-            <strong>General algorithm for generation of UUIDv8 not defined here:</strong>
+		</section>
+
+		<section anchor="Acknowledgements" title="Acknowledgements">
+			<t>The authors gratefully acknowledge the contributions of 
+				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,
+				sergeyprokhorenko,
+				LiosK
+				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>
-			<ol>
-				<li><t>From a system-wide shared stable store (e.g., a file) or global variable,
-				  read the UUID generator state: the values of the timestamp
-				  and clock sequence used to generate the last UUID.</t></li>
-				<li><t>Obtain the current time from the selected clock source as desired bit total</t></li>
-				<li><t>Set total amount of bits for timestamp as required in the most significant
-				  positions of the 128 bit UUID</t></li>
-				<li><t>Care MUST be taken to ensure that the UUID Version and UUID Variant are in the correct bit positions.</t>
-				  <t>UUID Version: Bits 48 through 51</t>
-				  <t>UUID Variant: Bits 64 and 65</t></li>
-				<li><t>If the state was unavailable (e.g., non-existent or corrupted)
-				  or the timestamp is greater than the current timestamp;
-				  set the desired clock sequence value to 0</t></li>
-				<li><t>If the state was available, but the saved timestamp is less than
-				  or equal to the current timestamp, increment the clock sequence value.</t></li>
-				<li><t>Set the remaining bits to the node as pseudo-random data</t></li>
-				<li><t>Format by concatenating the 128 bits together</t></li>
-				<li><t>Save the state (current timestamp and clock sequence)
-				  back to the stable store</t></li>
-			</ol>  
-            </section>
-        </section>
-    </section>
-    <section anchor="encoding" title="Encoding and Storage">
-        <t>
-        The existing UUID hex and dash format of 8-4-4-4-12 is retained for both
-        backwards compatibility and human readability.
-		</t>
-		<t>
-        For many applications such as databases
-        this format is unnecessarily verbose totaling 288 bits.
-		</t>
-		<ul spacing="compact">
-			<li><t>8 bits for each of the 32 hex characters = 256 bits</t></li>
-			<li><t>8 bits for each of the 4 hyphens = 32 bits</t></li>
-		</ul>
-		<t>
-        Where possible UUIDs SHOULD be stored within
-        database applications as the underlying 128 bit binary value.
-        </t>
-    </section>
-    <section anchor="uniquness" title="Global Uniqueness">
-        <t>
-        UUIDs created by this specification offer the same guarantees for global uniqueness 
-		as those found in <xref target="RFC4122"/>. Furthermore, the time-based UUIDs defined in this specification 
-		are geared towards database applications but MAY be used for a wide variety of use-cases. 
-		Just as global uniqueness is guaranteed, UUIDs are guaranteed to be unique within an application 
-		context within the enterprise domain.
-        </t>
-	</section>
-    <section anchor="distributed" title="Distributed UUID Generation">
-        <t>
-        Some implementations might desire to utilize multi-node, clustered, applications which involve 2 or more 
-		applications independently generating UUIDs that will be stored in a common location. UUIDs already feature sufficient 
-		entropy to ensure that the chances of collision are low. However, implementations MAY dedicate a 
-		portion of the node's most significant random bits to a pseudo-random machineID which helps identify 
-		UUIDs created by a given node. This works to add an extra layer of collision avoidance.
-		</t>
-		<t>
-		This machine ID MUST be placed in the UUID after the timestamp and sequence counter bits. 
-		This position is selected to ensure that the sorting by timestamp and clock sequence is still possible. 
-		The machineID MUST NOT be an IEEE 802 MAC address. The creation and negotiation of the machineID 
-		among distributed nodes is out of scope for this specification.
-        </t>
-    </section>
-    <section anchor="IANA" title="IANA Considerations">
-        <t>This document has no IANA actions.</t>
-    </section>
-    <section anchor="Security" title="Security Considerations">
-        <t> 
-        MAC addresses pose inherent security risks and MUST not be used for node generation. 
-		As such they have been strictly forbidden from time-based UUIDs within this specification.
-		Instead pseudo-random bits SHOULD selected from a source with sufficient entropy to ensure guaranteed
-		uniqueness among UUID generation.
-        </t>
-        <t>
-        Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with 
-		the clock sequence does signal the order of creation for a given UUID and it's 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 then <xref target="RFC4122"/> UUIDv4 
-		SHOULD be utilized.
-        </t>
-        <t>
-        The machineID portion of node, described in <xref target="distributed"/>, does 
-		provide small unique identifier which could be used to determine which application is generating 
-		data but this machineID alone is not enough to identify a node on the network without other corresponding 
-		data points. Furthermore the machineID, like the timestamp+sequence, does not provide any context about 
-		the data the corresponds to the UUID or the current state of the application as a whole.
-        </t>
-    </section>
-    <section anchor="Acknowledgements" title="Acknowledgements">
-        <t>The authors gratefully acknowledge the contributions of 
-            Ben Campbell,
-            Ben Ramsey,
-            Fabio Lima,
-            Gonzalo Salgueiro, 
-            Martin Thomson,
-            Murray S. Kucherawy,
-            Rick van Rein,
-            Rob Wilton,
-            Sean Leonard,
-            Theodore Y. Ts'o.
-            As well as all of those in and outside the IETF community to who contributed to the discussions which resulted in this document.</t>
-    </section>
-  </middle>
-  <back>
-    <references title="Normative References">
-		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
-          <front>
-            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
-            <author initials="S." surname="Bradner" fullname="S. Bradner">
-              <organization showOnFrontPage="true"/>
-            </author>
-            <date year="1997" month="March"/>
-            <abstract>
-              <t indent="0">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="RFC4122" target="https://www.rfc-editor.org/info/rfc4122">
-			<front>
-			  <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
-			  <author initials="P." surname="Leach" fullname="P. Leach">
-			    <organization/>
-			  </author>
-			  <author initials="M." surname="Mealling" fullname="M. Mealling">
-				<organization/>
-			  </author>
-			  <author initials="R." surname="Salz" fullname="R. Salz">
-				<organization/>
-			  </author>
-			  <date year="2005" month="July"/>
-			  <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>
-			  </front>
-			  <seriesInfo name="RFC" value="4122"/>
-			  <seriesInfo name="DOI" value="10.17487/RFC4122"/>
-		</reference>
-    </references>
-	<references title="Informative References">
-	    <reference anchor="LexicalUUID" target="https://github.com/twitter-archive/cassie">
-			<front>
-				<title>A Scala client for Cassandra</title>
-				<author>
-					<organization showOnFrontPage="true">Twitter</organization>
-				</author>
-				<date month="November" year="2012" />
-			</front>
-			<seriesInfo name="commit" value="f6da4e0" />
-		</reference>
-		<reference anchor="Snowflake" target="https://github.com/twitter-archive/snowflake/releases/tag/snowflake-2010">
-			<front>
-				<title>Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.</title>
-				<author>
-					<organization showOnFrontPage="true">Twitter</organization>
-				</author>
-				<date month="May" year="2014" />
-			</front>
-			<seriesInfo name="Commit" value="b3f6a3c" />
-		</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 showOnFrontPage="true">Boundary</organization>
-				</author>
-				<date month="February" year="2017" />
-			</front>
-			<seriesInfo name="Commit" value="15c933a" />
-		</reference>
-		<reference anchor="ShardingID" target="https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c">
-			<front>
-				<title>Sharding &#038; IDs at Instagram</title>
-				<author>
-					<organization showOnFrontPage="true">Instagram Engineering</organization>
-				</author>
-				<date month="December" year="2012" />
-			</front>
-		</reference>
-		<reference anchor="KSUID" target="https://github.com/segmentio/ksuid">
-			<front>
-				<title>K-Sortable Globally Unique IDs</title>
-				<author>
-					<organization showOnFrontPage="true">Segment</organization>
-				</author>
-				<date month="July" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="bf376a7" />
-		</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 month="January" year="2015" />
-			</front>
-			<seriesInfo name="Commit" value="dd71c21" />
-		</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">
-					<organization />
-				</author>
-				<date month="April" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="fcd6a2f" />
-		</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 showOnFrontPage="true">Sony</organization>
-				</author>
-				<date month="August" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="848d664" />
-		</reference>
-		<reference anchor="orderedUuid" target="https://itnext.io/laravel-the-mysterious-ordered-uuid-29e7500b4f8">
-			<front>
-				<title>Laravel: The mysterious "Ordered UUID"</title>
-				<author initials="IT" surname="Cabrera" fullname="Italo Baeza Cabrera">
-					<organization />
-				</author>
-				<date month="January" year="2020" />
-			</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">
-					<organization />
-				</author>
-				<date month="December" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="2759820" />
-		</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">
-					<organization />
-				</author>
-				<date month="May" year="2019" />
-			</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">
-					<organization />
-				</author>
-				<date month="June" year="2019" />
-			</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>
-					<organization showOnFrontPage="true">Google</organization>
-				</author>
-				<date month="February" year="2015" />
-			</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">
-					<organization />
-				</author>
-				<date month="October" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="efa678f" />
-		</reference>
-		<reference anchor="ObjectID" target="https://docs.mongodb.com/manual/reference/method/ObjectId/">
-			<front>
-				<title>ObjectId - MongoDB Manual</title>
-				<author>
-					<organization showOnFrontPage="true">MongoDB</organization>
-				</author>
-			</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">
-					<organization />
+		</section>
+
+	</middle>
+
+	<back>
+		<references title="Normative References">
+			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
+				<front>
+					<title>Key words for use in RFCs to Indicate Requirement Levels</title>
+					<author initials="S." surname="Bradner" fullname="S. Bradner">
+						<organization showOnFrontPage="true"/>
+					</author>
+					<date year="1997" month="March"/>
+					<abstract>
+						<t indent="0">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" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
+			  <front>
+				<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
+				<author initials="B." surname="Leiba" fullname="B. Leiba">
+				  <organization showOnFrontPage="true"/>
 				</author>
-				<date month="October" year="2020" />
-			</front>
-			<seriesInfo name="Commit" value="215b27b" />
-		</reference>
-	</references>
-  </back>
-</rfc>
+				<date year="2017" month="May"/>
+				<abstract>
+				  <t indent="0">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"/>
+			</reference>
+			<reference anchor="RFC4122" target="https://www.rfc-editor.org/info/rfc4122">
+				<front>
+					<title>A Universally Unique IDentifier (UUID) URN Namespace</title>
+					<author initials="P." surname="Leach" fullname="P. Leach">
+						<organization/>
+					</author>
+					<author initials="M." surname="Mealling" fullname="M. Mealling">
+						<organization/>
+					</author>
+					<author initials="R." surname="Salz" fullname="R. Salz">
+						<organization/>
+					</author>
+					<date year="2005" month="July"/>
+					<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>
+				</front>
+				<seriesInfo name="RFC" value="4122"/>
+				<seriesInfo name="DOI" value="10.17487/RFC4122"/>
+			</reference>
+		</references>
+		<references title="Informative References">
+			<reference anchor="LexicalUUID" target="https://github.com/twitter-archive/cassie">
+				<front>
+					<title>A Scala client for Cassandra</title>
+					<author>
+						<organization showOnFrontPage="true">Twitter</organization>
+					</author>
+					<date month="November" year="2012" />
+				</front>
+				<seriesInfo name="commit" value="f6da4e0" />
+			</reference>
+			<reference anchor="Snowflake" target="https://github.com/twitter-archive/snowflake/releases/tag/snowflake-2010">
+				<front>
+					<title>Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.</title>
+					<author>
+						<organization showOnFrontPage="true">Twitter</organization>
+					</author>
+					<date month="May" year="2014" />
+				</front>
+				<seriesInfo name="Commit" value="b3f6a3c" />
+			</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 showOnFrontPage="true">Boundary</organization>
+					</author>
+					<date month="February" year="2017" />
+				</front>
+				<seriesInfo name="Commit" value="15c933a" />
+			</reference>
+			<reference anchor="ShardingID" target="https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c">
+				<front>
+					<title>Sharding &#038; IDs at Instagram</title>
+					<author>
+						<organization showOnFrontPage="true">Instagram Engineering</organization>
+					</author>
+					<date month="December" year="2012" />
+				</front>
+			</reference>
+			<reference anchor="KSUID" target="https://github.com/segmentio/ksuid">
+				<front>
+					<title>K-Sortable Globally Unique IDs</title>
+					<author>
+						<organization showOnFrontPage="true">Segment</organization>
+					</author>
+					<date month="July" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="bf376a7" />
+			</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 month="January" year="2015" />
+				</front>
+				<seriesInfo name="Commit" value="dd71c21" />
+			</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">
+						<organization />
+					</author>
+					<date month="April" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="fcd6a2f" />
+			</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 showOnFrontPage="true">Sony</organization>
+					</author>
+					<date month="August" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="848d664" />
+			</reference>
+			<reference anchor="orderedUuid" target="https://itnext.io/laravel-the-mysterious-ordered-uuid-29e7500b4f8">
+				<front>
+					<title>Laravel: The mysterious "Ordered UUID"</title>
+					<author initials="IT" surname="Cabrera" fullname="Italo Baeza Cabrera">
+						<organization />
+					</author>
+					<date month="January" year="2020" />
+				</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">
+						<organization />
+					</author>
+					<date month="December" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="2759820" />
+			</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">
+						<organization />
+					</author>
+					<date month="May" year="2019" />
+				</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">
+						<organization />
+					</author>
+					<date month="June" year="2019" />
+				</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>
+						<organization showOnFrontPage="true">Google</organization>
+					</author>
+					<date month="February" year="2015" />
+				</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">
+						<organization />
+					</author>
+					<date month="October" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="efa678f" />
+			</reference>
+			<reference anchor="ObjectID" target="https://docs.mongodb.com/manual/reference/method/ObjectId/">
+				<front>
+					<title>ObjectId - MongoDB Manual</title>
+					<author>
+						<organization showOnFrontPage="true">MongoDB</organization>
+					</author>
+				</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">
+						<organization />
+					</author>
+					<date month="October" year="2020" />
+				</front>
+				<seriesInfo name="Commit" value="215b27b" />
+			</reference>
+			<reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/6210/">
+				<front>
+					<title>Collision-resistant ids optimized for horizontal scaling and performance.</title>
+					<author>
+						<organization showOnFrontPage="true">IEEE</organization>
+					</author>
+					<date month="July" year="2019" />
+				</front>
+				<seriesInfo name="Series" value="754-2019" />
+			</reference>
+		</references>
+		<section anchor="example_code" title="Example Code">
+			<section anchor="creating_a_uuidv6_value" title="Creating a UUIDv6 Value">
+				<t>This section details a function in C which converts from a UUID version 1 to version 6:
+				</t>
+				<figure>
+					<name>UUIDv6 Function in C</name>
+					<artwork><![CDATA[
+#include <stdio.h>
+#include <stdint.h>
+#include <inttypes.h>
+#include <arpa/inet.h>
+#include <uuid/uuid.h>
+
+/* Converts UUID version 1 to version 6 in place. */
+void uuidv1tov6(uuid_t u) {
+
+  uint64_t ut;
+  unsigned char *up = (unsigned char *)u;
+
+  // load ut with the first 64 bits of the UUID
+  ut = ((uint64_t)ntohl(*((uint32_t*)up))) << 32;
+  ut |= ((uint64_t)ntohl(*((uint32_t*)&up[4])));
+
+  // dance the bit-shift...
+  ut = 
+    ((ut >> 32) & 0x0FFF) | // 12 least significant bits
+    (0x6000) | // version number
+    ((ut >> 28) & 0x0000000FFFFF0000) | // next 20 bits
+    ((ut << 20) & 0x000FFFF000000000) | // next 16 bits
+    (ut << 52); // 12 most significant bits
+
+  // store back in UUID
+  *((uint32_t*)up) = htonl((uint32_t)(ut >> 32));
+  *((uint32_t*)&up[4]) = htonl((uint32_t)(ut));
+
+}
+					]]></artwork>
+				</figure>
+			</section>
+			<section anchor="creating_a_uuidv7_value" title="Creating a UUIDv7 Value">
+				<figure>
+					<name>UUIDv7 Function in C</name>
+					<artwork><![CDATA[
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <time.h>
+
+// ...
+
+// csprng data source
+FILE *rndf;
+rndf = fopen("/dev/urandom", "r");
+if (rndf == 0) {
+	printf("fopen /dev/urandom error\n");
+	return 1;
+}
+
+// ...
+
+// generate one UUIDv7
+uint8_t u[16];
+struct timespec ts;
+int ret;
+
+ret = clock_gettime(CLOCK_REALTIME, &ts);
+if (ret != 0) {
+	printf("clock_gettime error: %d\n", ret);
+	return 1;
+}
+
+uint64_t tms;
+
+tms = ((uint64_t)ts.tv_sec) * 1000;
+tms += ((uint64_t)ts.tv_nsec) / 1000000;
+
+printf("tms: %lld\n", tms);
+
+memset(u, 0, 16);
+
+fread(&u[6], 10, 1, rndf); // fill everything after the timestamp with random bytes
+
+*((uint64_t*)(u)) |= htonll(tms << 16); // shift time into first 48 bits and OR into place
+
+u[8] = 0xE7; // set var-ver field
+					]]></artwork>
+				</figure>
+			</section>
+			<section anchor="creating_a_uuidv8_value" title="Creating a UUIDv7 Value">
+				<t>UUIDv8 will vary greatly from implementation to implementation. A good candidate use case for UUIDv8 is to embed exotic timestamps like the one found in this example which employs approximately 0.25 milliseconds and approximately 5 microseconds per timestamp tick as a 48 bit value.</t>
+				<figure>
+					<name>UUID8 Function in C</name>
+					<artwork><![CDATA[
+#include <stdint.h>
+#include <stdio.h>
+#include <time.h>
+
+int main() {
+  struct timespec tp;
+  clock_gettime(CLOCK_REALTIME, &tp);
+  uint64_t timestamp = (uint64_t)tp.tv_sec << 12;
+
+  // compute 12-bit (~0.25 msec precision) fraction from nsecs
+  timestamp |= ((uint64_t)tp.tv_nsec << 12) / 1000000000;
+
+  printf("%08llx-%04llx\n", timestamp >> 16, timestamp & 0xFFFF);
+  return 0;
+}
+					]]></artwork>
+				</figure>
+			</section>
+		</section>
+		<section anchor="test_vectors" title="Test Vectors">
+			<t>Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00</t>
+			<t>Both UUIDv1 and UUIDv6 utilize the same values in clk_seq_hi_res, clock_seq_low, and node. All of which have been generated with random data.</t>
+				<figure>
+					<name>Test Vector Timestamp Pseudo-code</name>
+					<artwork><![CDATA[
+# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
+gregorian_100_ns = (unix_64_bit_nanoseconds / 100) + gregorian_unix_offset
+
+# 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.
+# gregorian_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_nanoseconds = 0x16D6320C3D4DCC00 or 1645557742000000000
+
+# Work:
+# gregorian_100_ns = (1645557742000000000 / 100) + 122192928000000000
+# (138648505420000000 - 122192928000000000) * 100 = unix_64_bit_nanoseconds
+
+# Final:
+# gregorian_100_ns = 0x1EC9414C232AB00 or 138648505420000000
+
+# Original: 000111101100100101000001010011000010001100101010101100000000
+# UUIDv1:   11000010001100101010101100000000|1001010000010100|0001|000111101100
+# UUIDv6:   00011110110010010100000101001100|0010001100101010|0110|101100000000
+					]]></artwork>
+				</figure>			
+			<section anchor="uuidv6_example" title="Example of a UUIDv6 Value">
+				<figure>
+					<name>UUIDv1 Example Test Vector</name>
+					<artwork><![CDATA[
+----------------------------------------------
+field                 bits    value_hex       
+----------------------------------------------
+time_low              32      0xC232AB00      
+time_mid              16      0x9414          
+time_hi_and_version   16      0x11EC          
+clk_seq_hi_res         8      0xB3            
+clock_seq_low          8      0xC8            
+node                  48      0x9E6BDECED846  
+----------------------------------------------
+total                128
+----------------------------------------------
+final_hex: C232AB00-9414-11EC-B3C8-9E6BDECED846
+					]]></artwork>
+				</figure>
+				<figure>
+					<name>UUIDv6 Example Test Vector</name>
+					<artwork><![CDATA[
+-----------------------------------------------
+field                 bits    value_hex        
+-----------------------------------------------
+time_high              32      0x1EC9414C      
+time_mid               16      0x232A          
+time_low_and_version   16      0x6B00          
+clk_seq_hi_res          8      0xB3            
+clock_seq_low           8      0xC8            
+node                   48      0x9E6BDECED846  
+-----------------------------------------------
+total                 128
+-----------------------------------------------
+final_hex: 1EC9414C-232A-6B00-B3C8-9E6BDECED846
+					]]></artwork>
+				</figure>
+			</section>
+			<section anchor="uuidv7_example" title="Example of a UUIDv7 Value">
+				<t>This example UUIDv7 test vector utilizes a well-known 32-bit unix epoch with additional 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 represented as 0x17F21CFD130 or 1645539742000</t>
+				<figure>
+					<name>UUIDv7 Example Test Vector</name>
+					<artwork><![CDATA[
+-------------------------------
+field      bits    value
+-------------------------------
+unix_ts_ms   48    0x017F21CFD130
+rand_a       16    0xF8B8
+var_ver       8    0xE7
+rand_b       56    0xD6A139DC9535C5
+-------------------------------
+total        128               
+-------------------------------
+final: 017F21CF-D130-F8B8-E7D6-A139DC9535C5
+					]]></artwork>
+				</figure>
+			</section>
+			<section anchor="uuidv8_example" title="Example of a UUIDv8 Value">
+				<t>This example UUIDv8 test vector utilizes a well-known 64-bit unix epoch with nanosecond precision to fill the first 64 bits through ver_var.</t>
+				<t>The final 56 bits are filled with random data.</t>
+				<t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 represented as 0x16D6320C3D4DCC00 or 1645557742000000000</t>
+				<t>It should be noted that this example is just to illustrate one scenario for UUIDv8. Test vectors will likely be implementation specific and vary greatly from this simple example.</t>
+				<figure>
+					<name>UUIDv8 Example Test Vector</name>
+					<artwork><![CDATA[
+-------------------------------
+field      bits    value
+-------------------------------
+custom_a     64    0x16D6320C3D4DCC00
+var_ver       8    0xE8
+custom_b     56    0x3C2D06302FC417
+-------------------------------
+total        128               
+-------------------------------
+final: 16D6320C-3D4D-CC00-E83C-2D06302FC417
+					]]></artwork>
+				</figure>
+			</section>
+		</section>
+	</back>
+</rfc>
\ No newline at end of file
diff --git a/LATEST-OUTLINE.md b/editor-notes/LATEST-OUTLINE.md
similarity index 100%
rename from LATEST-OUTLINE.md
rename to editor-notes/LATEST-OUTLINE.md
diff --git a/LATEST.md b/editor-notes/LATEST.md
similarity index 100%
rename from LATEST.md
rename to editor-notes/LATEST.md