Diff: rfc9562.original.xml

	rfc9562.original.xml	rfc9562.xml

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.0.2	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	) -->	-ietf-uuidrev-rfc4122bis-14" number="9562" submissionType="IETF" category="std"
	<?rfc strict="yes"?>	consensus="true" obsoletes="4122" updates="" tocDepth="3" tocInclude="true" sort
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft	Refs="true" symRefs="true" xml:lang="en" version="3">
	-ietf-uuidrev-rfc4122bis-14" category="std" consensus="true" submissionType="IET
	F" obsoletes="4122" tocDepth="3" tocInclude="true" sortRefs="true" symRefs="true
	" version="3">
	<!-- xml2rfc v2v3 conversion 3.18.2 -->
	<front>	<front>

	<title abbrev="UUID">Universally Unique IDentifiers (UUID)</title>	<title abbrev="UUIDs">Universally Unique IDentifiers (UUIDs)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-uuidrev-rfc4122bis-14"/>	<seriesInfo name="RFC" value="9562"/>
	<author initials="K. R." surname="Davis" fullname="Kyzer R. Davis">	<author initials="K." surname="Davis" fullname="Kyzer R. Davis">
	<organization>Cisco Systems</organization>	<organization>Cisco Systems</organization>
	<address>	<address>
	<email>kydavis@cisco.com</email>	<email>kydavis@cisco.com</email>
	</address>	</address>
	</author>	</author>

	<author initials="B. G." surname="Peabody" fullname="Brad G. Peabody">	<author initials="B." surname="Peabody" fullname="Brad G. Peabody">
	<organization>Uncloud</organization>	<organization>Uncloud</organization>
	<address>	<address>
	<email>brad@peabody.io</email>	<email>brad@peabody.io</email>
	</address>	</address>
	</author>	</author>
	<author initials="P." surname="Leach" fullname="P. Leach">	<author initials="P." surname="Leach" fullname="P. Leach">
	<organization>University of Washington</organization>	<organization>University of Washington</organization>
	<address>	<address>
	<email>pjl7@uw.edu</email>	<email>pjl7@uw.edu</email>
	</address>	</address>
	</author>	</author>

	<date year="2023"/>	<date year="2024" month="May"/>
	<area>ART</area>	<area>art</area>
	<workgroup>uuidrev</workgroup>	<workgroup>uuidrev</workgroup>
	<keyword>uuid</keyword>	<keyword>uuid</keyword>

	<abstract>
	<?line 274?>


	<t>This specification defines the UUIDs (Universally Unique IDentifiers) and the	<abstract>
	UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Glob	<t>This specification defines UUIDs (Universally Unique IDentifiers)
	ally Unique IDentifiers).	(also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
	A UUID is 128 bits long and is intended to guarantee	Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended
	uniqueness across space and time. UUIDs were originally used in the	to
	Apollo Network Computing System and later in the Open Software	guarantee uniqueness across space and time. UUIDs were originally used
	Foundation's (OSF) Distributed Computing Environment (DCE), and then	in the Apollo Network Computing System (NCS), later in the Open Software
	in Microsoft Windows platforms.</t>	Foundation's (OSF's) Distributed Computing Environment (DCE), and then
	<t>This specification is derived from the DCE specification with the	in Microsoft Windows platforms.</t>
	kind permission of the OSF (now known as The Open Group).	<t>This specification is derived from the OSF DCE specification with the
	Information from earlier versions of the DCE specification have been	kind permission of the OSF (now known as "The Open Group"). Information
	incorporated into this document. This document obsoletes RFC4122.</t>	from earlier versions of the OSF DCE specification have been incorporated
		into this document. This document obsoletes RFC 4122.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<?line 288?>

	<section anchor="Background">	<section anchor="Background">
	<name>Introduction</name>	<name>Introduction</name>

	<t>This specification defines the UUIDs (Universally Unique IDentifiers) a	<t>This specification defines a Uniform Resource Name namespace for
	nd the UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs	Universally Unique IDentifiers (UUIDs) (also known as Globally
	(Globally Unique IDentifiers).	Unique IDentifiers (GUIDs)). A UUID is 128 bits long and
	A UUID is 128 bits long and requires no central	requires no central registration process.</t>
	registration process.</t>
	<t>The use of UUIDs is extremely pervasive in computing. They comprise	<t>The use of UUIDs is extremely pervasive in computing. They comprise

	the core identifier infrastructure for many operating systems	the core identifier infrastructure for many operating systems such as
	such as Microsoft Windows and applications such as the Mozilla Web browser and i	Microsoft Windows and applications such as the Mozilla Web browser;
	n	in many cases, they can become exposed in many non-standard ways.</t>
	many cases, become exposed in many non-standard ways.</t>
	<t>This specification attempts to standardize that practice as openly as	<t>This specification attempts to standardize that practice as openly as

	possible and in a way that attempts to benefit the entire Internet.	possible and in a way that attempts to benefit the entire Internet. The i
	The information here is meant to be a concise guide for those wishing	nformation
	to implement services using UUIDs either in combination with URNs <xref target="	here is meant to be a concise guide for those wishing to implement
	RFC8141"/> or otherwise.</t>	services using UUIDs either in combination with URNs <xref
	<t>There is an ITU-T Recommendation and an ISO/IEC Standard <xref target="	target="RFC8141"/> or otherwise.</t>
	X667"/> that are	<t>There is an ITU-T Recommendation and an ISO/IEC Standard <xref
	derived from <xref target="RFC4122"/>. Both sets of	target="X667"/> that are derived from <xref target="RFC4122"/>. Both
	specifications have been aligned and are fully technically	sets of specifications have been aligned and are fully technically
	compatible.	compatible. Nothing in this document should be construed to override
	Nothing in this document should be construed to override the DCE standards that	the DCE standards that defined UUIDs.</t>
	defined UUIDs.</t>
	</section>	</section>
	<section anchor="motivation">	<section anchor="motivation">
	<name>Motivation</name>	<name>Motivation</name>
	<t>One of the main reasons for using UUIDs is that no centralized	<t>One of the main reasons for using UUIDs is that no centralized

	authority is required to administer them (although two formats may leverage opti	authority is required to administer them (although two formats may
	onal	leverage optional IEEE 802 Node IDs, others do not). As a
	IEEE 802 node identifiers, others do not). As a result, generation	result, generation on demand can be completely automated and used for a
	on demand can be completely automated and used for a variety of	variety of purposes. The UUID generation algorithm described here
	purposes. The UUID generation algorithm described here supports very	supports very high allocation rates of 10 million per second per machine
	high allocation rates of 10 million per second per machine or more if	or more, if necessary, so that they could even be used as transaction
	necessary, so that they could even be used as transaction IDs.</t>	IDs.</t>
	<t>UUIDs are of a fixed size (128 bits), which is reasonably small	<t>UUIDs are of a fixed size (128 bits), which is reasonably small

	compared to other alternatives. This lends itself well to sorting,	compared to other alternatives. This lends itself well to sorting,
	ordering, and hashing of all sorts, storing in databases, simple	ordering, and hashing of all sorts; storing in databases; simple
	allocation, and ease of programming in general.</t>	allocation; and ease of programming in general.</t>
	<t>Since UUIDs are unique and persistent, they make excellent Uniform	<t>Since UUIDs are unique and persistent, they make excellent URNs.
	Resource Names. The unique ability to generate a new UUID without a	The unique ability to generate a new UUID without a
	registration process allows for UUIDs to be one of the URNs with the	registration process allows for UUIDs to be one of the URNs with the
	lowest minting cost.</t>	lowest minting cost.</t>
	<section anchor="update-motivation">	<section anchor="update-motivation">
	<name>Update Motivation</name>	<name>Update Motivation</name>

	<t>Many things have changed in the time since UUIDs were originally crea	<t>Many things have changed in the time since UUIDs were originally
	ted.	created. Modern applications have a need to create and utilize UUIDs
	Modern applications have a need to create and utilize UUIDs as the primary	as the primary identifier for a variety of different items in complex
	identifier for a variety of different items in complex computational systems,	computational systems, including but not limited to database keys,
	including but not limited to database keys, file names, machine or system	file names, machine or system names, and identifiers for event-driven
	names, and identifiers for event-driven transactions.</t>	transactions.</t>
	<t>One area in which UUIDs have gained popularity is database keys.	<t>One area in which UUIDs have gained popularity is database keys.

	This stems from the increasingly distributed nature of modern applications.	This stems from the increasingly distributed nature of modern
	In such cases, "auto increment" schemes often used by databases do not work	applications. In such cases, "auto-increment" schemes that are often
	well, as the effort required to coordinate sequential numeric identifiers across	used by databases do not work well: the effort required to
	a network can easily become a burden.	coordinate sequential numeric identifiers across a network can easily
	The fact that UUIDs can be used to create unique, reasonably short values	become a burden. The fact that UUIDs can be used to create unique,
	in distributed systems without requiring coordination makes them a good	reasonably short values in distributed systems without requiring
	alternative, but UUID versions 1-5, which were originally defined by <xref targe	coordination makes them a good alternative, but UUID versions 1-5,
	t="RFC4122"/>, lack certain other desirable characteristics:</t>	which were originally defined by <xref target="RFC4122"/>, lack
	<ol spacing="normal" type="1"><li>	certain other desirable characteristics, such as:</t>
	<t>Non-time-ordered UUID versions such as UUIDv4 (described in <xref	<ol spacing="normal" type="1">
	target="uuidv4"/>) have poor database index	<li>UUID versions that are not time ordered, such as UUIDv4 (described
	locality.	in
	This means that new values created in succession are not close to each other i	<xref target="uuidv4"/>), have poor database-index locality. This
	n	means that new values created in succession are not close to each
	the index and thus require inserts to be performed at random	other in the index; thus, they require inserts to be performed at
	locations.	random locations. The resulting negative performance effects on the
	The resulting negative performance effects on common structures used for	common structures used for this (B-tree and its variants) can be
	this (B-tree and its variants) can be dramatic.</t>	dramatic.</li>
	</li>	<li>The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps (desc
	<li>	ribed in
	<t>The 100-nanosecond Gregorian epoch used in UUIDv1 (described in <	<xref target="uuidv1"/>) is uncommon and difficult to
	xref target="uuidv1"/>) timestamps is uncommon	represent accurately using a standard number format such as that
	and difficult to represent accurately using a standard number format such	described in <xref target="IEEE754"/>.</li>
	as <xref target="IEEE754"/>.</t>	<li>Introspection/parsing is required to order by time sequence, as
	</li>	opposed to being able to perform a simple byte-by-byte comparison.
	<li>
	<t>Introspection/parsing is required to order by time sequence, as o
	pposed 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 addres
	s in the
	node field of UUID version 1.
	Exposed MAC addresses can be used as an attack surface to locate network inter
	faces
	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 of the implementation details specified in <xref target="RFC
	4122"/> involved trade
	offs that are neither possible to specify for all applications nor
	necessary to produce interoperable implementations.</t>
	</li>
	<li>
	<t><xref target="RFC4122"/> did not distinguish between the requirem
	ents for generating a UUID
	and those for simply storing one, although they are often different.</t>
	</li>	</li>

		<li>Privacy and network security issues arise from using a Media Acces
		s Control (MAC)
		address in the node field of UUIDv1. Exposed MAC addresses
		can be used as an attack surface to locate network interfaces and
		reveal various other information about such machines (minimally, the
		manufacturer and, potentially, other details). Additionally, with the
		advent of virtual machines and containers, uniqueness of the MAC addre
		ss is
		no longer guaranteed.</li>
		<li>Many of the implementation details specified in <xref
		target="RFC4122"/> involved trade-offs that are neither possible to
		specify for all applications nor necessary to produce interoperable
		implementations.</li>
		<li><xref target="RFC4122"/> did not distinguish between the
		requirements for generating a UUID and those for simply storing one,
		although they are often different. </li>
	</ol>	</ol>

	<t>Due to the aforementioned issues, many widely distributed database ap
	plications	<t>Due to the aforementioned issues, many widely distributed database
	and large application vendors have sought to solve the problem of creating	applications and large application vendors have sought to solve the
	a better	problem of creating a better time-based, sortable unique identifier
	time-based, sortable unique identifier for use as a database key. This has	for use as a database key. This has led to numerous implementations
	led to numerous implementations	over the past 10+ years solving the same problem in slightly different
	over the past 10+ years solving the same problem in slightly different ways.</t>	ways.</t>
	<t>While preparing this specification, the following 16 different implem	<t>While preparing this specification, the following 16 different
	entations	implementations were analyzed for trends in total ID length, bit
	were analyzed for trends in total ID length, bit layout, lexical formatting/enco	layout, lexical formatting and encoding, timestamp type, timestamp
	ding,	format, timestamp accuracy, node format and components, collision
	timestamp type, timestamp format, timestamp accuracy, node format/components,	handling, and multi-timestamp tick generation sequencing:</t>
	collision handling, and multi-timestamp tick generation sequencing:</t>
	<ol spacing="compact" type="1"><li>	<ol spacing="compact" type="1">
	<t><xref target="ULID"/> by A. Feerasta</t>	<li><xref target="ULID"/></li>
	</li>	<li><xref target="LexicalUUID"/></li>
	<li>	<li><xref target="Snowflake"/></li>
	<t><xref target="LexicalUUID"/> by Twitter</t>	<li><xref target="Flake"/></li>
	</li>	<li><xref target="ShardingID"/></li>
	<li>	<li><xref target="KSUID"/></li>
	<t><xref target="Snowflake"/> by Twitter</t>	<li><xref target="Elasticflake"/></li>
	</li>	<li><xref target="FlakeID"/></li>
	<li>	<li><xref target="Sonyflake"/></li>
	<t><xref target="Flake"/> by Boundary</t>	<li><xref target="orderedUuid"/></li>
	</li>	<li><xref target="COMBGUID"/></li>
	<li>	<li><xref target="SID"/></li>
	<t><xref target="ShardingID"/> by Instagram</t>	<li><xref target="pushID"/></li>
	</li>	<li><xref target="XID"/></li>
	<li>	<li><xref target="ObjectID"/></li>
	<t><xref target="KSUID"/> by Segment</t>	<li><xref target="CUID"/></li>
	</li>
	<li>
	<t><xref target="Elasticflake"/> by P. Pearcy</t>
	</li>
	<li>
	<t><xref target="FlakeID"/> by T. Pawlak</t>
	</li>
	<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="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>
	<li>
	<t><xref target="ObjectID"/> by MongoDB</t>
	</li>
	<li>
	<t><xref target="CUID"/> by E. Elliott</t>
	</li>
	</ol>	</ol>

	<t>An inspection of these implementations and the issues described above
	has	<t>An inspection of these implementations and the issues described
	led to this document which intends to adapt new UUIDs to address these issues.</	above has led to this document, in which new UUIDs are adapted to
	t>	address these issues.</t>
	<t>Further, <xref target="RFC4122"/> itself was in need an overhaul to a	<t>Further, <xref target="RFC4122"/> itself was in need of an overhaul t
	ddress a number of topics such as but not limited to the following:</t>	o
	<ol spacing="normal" type="1"><li>	address a number of topics such as, but not limited to, the
	<t>Miscellaneous erratas. Mostly around bit layout clarifications wh	following:</t>
	ich lead to inconsistent implementations.</t>
	</li>	<ol spacing="normal" type="1">
	<li>	<li>Implementation of miscellaneous errata reports. Mostly around
	<t>Decouple other UUID versions from UUIDv1 bit layout so that field	bit-layout clarifications, which lead to inconsistent
	s like "time_hi_and_version" do not need to be referenced within a non-time-base	implementations <xref target="Err1957"/>, <xref target="Err3546"/>,
	d UUID while also providing "UUIDv1 like" definition sections for UUIDv3, UUIDv4	<xref target="Err4975"/>, <xref target="Err4976"/>, <xref
	, and UUIDv5.</t>	target="Err5560"/>, etc.</li>
	</li>	<li>Decoupling other UUID versions from the UUIDv1 bit layout so that
	<li>	fields like "time_hi_and_version" do not need to be referenced
	<t>Provide implementation best practices around many real-world scen	within a UUID that is not time based while also providing
	arios and corner cases observed by existing and prototype implementations.</t>	definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and
	</li>	UUIDv5.</li>
	<li>	<li>Providing implementation best practices around many real-world
	<t>Update the document to address security best practices and consid	scenarios and corner cases observed by existing and prototype
	erations for the modern age as it pertains MAC addresses, hashing algorithms, se	implementations.</li>
	cure randomness, and other topics.</t>	<li>Addressing security best practices and
	</li>	considerations for the modern age as it pertains to MAC addresses,
	<li>	hashing algorithms, secure randomness, and other topics.</li>
	<t>Provide implementations a standard-based option for implementatio	<li>Providing implementations a standard-based option for
	n specific and/or experimental UUID designs.</t>	implementation-specific and/or experimental UUID designs.</li>
	</li>	<li>Providing more test vectors that illustrate real UUIDs created as
	<li>	per the specification.</li>
	<t>Provide more test vectors that illustrate real UUIDs created as p
	er the specification.</t>
	</li>
	</ol>	</ol>


	</section>	</section>
	</section>	</section>
	<section anchor="terminology">	<section anchor="terminology">
	<name>Terminology</name>	<name>Terminology</name>
	<section anchor="requirements_language">	<section anchor="requirements_language">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	nterpreted as	are to be interpreted as described in BCP 14 <xref
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
	only when, they	appear in all capitals, as shown here.</t>
	appear in all capitals, as shown here.</t>	</section>
	<?line -18?>

	</section>
	<section anchor="acronyms">	<section anchor="acronyms">
	<name>Abbreviations</name>	<name>Abbreviations</name>
	<t>The following abbreviations are used in this document:</t>	<t>The following abbreviations are used in this document:</t>

	<dl indent="14">	<dl newline="false" spacing="normal" indent="14">
	<dt>UUID</dt>	<dt>ABNF</dt> <dd>Augmented Backus-Naur Form</dd>
	<dd>	<dt>CSPRNG</dt> <dd>Cryptographically Secure Pseudorandom Number Genera
	<t>Universally Unique Identifier</t>	tor</dd>
	</dd>	<dt>DBMS</dt> <dd>Database Management System</dd>
	<dt>UUIDv1</dt>	<dt>IEEE</dt> <dd>Institute of Electrical and Electronics Engineers</dd
	<dd>	>
	<t>Universally Unique Identifier Version 1</t>	<dt>ITU</dt> <dd>International Telecommunication Union</dd>
	</dd>	<dt>MAC</dt> <dd>Media Access Control</dd>
	<dt>UUIDv2</dt>	<dt>MD5</dt> <dd>Message Digest 5</dd>
	<dd>	<dt>MSB</dt> <dd>Most Significant Bit</dd>
	<t>Universally Unique Identifier Version 2</t>	<dt>OID</dt> <dd>Object Identifier</dd>
	</dd>	<dt>SHA</dt> <dd>Secure Hash Algorithm</dd>
	<dt>UUIDv3</dt>	<dt>SHA-1</dt> <dd>Secure Hash Algorithm 1 (with message digest of 160
	<dd>	bits)</dd>
	<t>Universally Unique Identifier Version 3</t>	<dt>SHA-3</dt> <dd>Secure Hash Algorithm 3 (arbitrary size)</dd>
	</dd>	<dt>SHA-224</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	<dt>UUIDv4</dt>	f 224 bits</dd>
	<dd>	<dt>SHA-256</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	<t>Universally Unique Identifier Version 4</t>	f 256 bits</dd>
	</dd>	<dt>SHA-512</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	<dt>UUIDv5</dt>	f 512 bits</dd>
	<dd>	<dt>SHAKE</dt> <dd>Secure Hash Algorithm 3 based on the KECCAK algorith
	<t>Universally Unique Identifier Version 5</t>	m</dd>
	</dd>	<dt>URN</dt> <dd>Uniform Resource Names</dd>
	<dt>UUIDv6</dt>	<dt>UTC</dt> <dd>Coordinated Universal Time</dd>
	<dd>	<dt>UUID</dt> <dd>Universally Unique Identifier</dd>
	<t>Universally Unique Identifier Version 6</t>	<dt>UUIDv1</dt> <dd>Universally Unique Identifier version 1</dd>
	</dd>	<dt>UUIDv2</dt> <dd>Universally Unique Identifier version 2</dd>
	<dt>UUIDv7</dt>	<dt>UUIDv3</dt> <dd>Universally Unique Identifier version 3</dd>
	<dd>	<dt>UUIDv4</dt> <dd>Universally Unique Identifier version 4</dd>
	<t>Universally Unique Identifier Version 7</t>	<dt>UUIDv5</dt> <dd>Universally Unique Identifier version 5</dd>
	</dd>	<dt>UUIDv6</dt> <dd>Universally Unique Identifier version 6</dd>
	<dt>UUIDv8</dt>	<dt>UUIDv7</dt> <dd>Universally Unique Identifier version 7</dd>
	<dd>	<dt>UUIDv8</dt> <dd>Universally Unique Identifier version 8</dd>
	<t>Universally Unique Identifier Version 8</t>
	</dd>
	<dt>URN</dt>
	<dd>
	<t>Uniform Resource Names</t>
	</dd>
	<dt>ABNF</dt>
	<dd>
	<t>Augmented Backus-Naur Form</t>
	</dd>
	<dt>CSPRNG</dt>
	<dd>
	<t>Cryptographically Secure Pseudo-Random Number Generator</t>
	</dd>
	<dt>MAC</dt>
	<dd>
	<t>Media Access Control</t>
	</dd>
	<dt>MSB</dt>
	<dd>
	<t>Most Significant Bit</t>
	</dd>
	<dt>DBMS</dt>
	<dd>
	<t>Database Management System</t>
	</dd>
	<dt>IEEE</dt>
	<dd>
	<t>Institute of Electrical and Electronics Engineers, Inc.</t>
	</dd>
	<dt>ITU</dt>
	<dd>
	<t>International Telecommunication Union</t>
	</dd>
	<dt>MD5</dt>
	<dd>
	<t>Message Digest 5</t>
	</dd>
	<dt>SHA</dt>
	<dd>
	<t>Secure Hash Algorithm</t>
	</dd>
	<dt>SHA-1</dt>
	<dd>
	<t>Secure Hash Algorithm 1 with message digest of 160 bits</t>
	</dd>
	<dt>SHA-224</dt>
	<dd>
	<t>Secure Hash Algorithm 2 with message digest size of 224 bits</t>
	</dd>
	<dt>SHA-256</dt>
	<dd>
	<t>Secure Hash Algorithm 2 with message digest size of 256 bits</t>
	</dd>
	<dt>SHA-512</dt>
	<dd>
	<t>Secure Hash Algorithm 2 with message digest size of 512 bits</t>
	</dd>
	<dt>SHA-3</dt>
	<dd>
	<t>Secure Hash Algorithm 3</t>
	</dd>
	<dt>SHAKE</dt>
	<dd>
	<t>Secure Hash Algorithm 3 based on KECCAK algorithm</t>
	</dd>
	<dt>UTC</dt>
	<dd>
	<t>Coordinated Universal Time</t>
	</dd>
	<dt>OID</dt>
	<dd>
	<t>Object Identifier</t>
	</dd>
	</dl>	</dl>
	</section>	</section>

	<section anchor="changelog" removeInRFC="true">
	<name>Changelog</name>
	<t>draft-14</t>
	<ul spacing="compact">
	<li>
	<t>AD Review #2: IANA Subtype Modifications #170</t>
	</li>
	<li>
	<t>AD Review #2: Specify Values for Variant/Subtype Column #171</t>
	</li>
	<li>
	<t>AD Review #2: Grammar change at the end of 5.1 #172</t>
	</li>
	<li>
	<t>SHA and Integer Verbiage clarifications #174</t>
	</li>
	<li>
	<t>Disclaimer in nil/max that these do not fall into IETF variants #
	175</t>
	</li>
	<li>
	<t>Fix v1/v6 final UUID in test vector #176</t>
	</li>
	</ul>
	<t>draft-13</t>
	<ul spacing="compact">
	<li>
	<t>Request IANA Registry #144</t>
	</li>
	<li>
	<t>Describe allocation logic of Namespace ID #161</t>
	</li>
	<li>
	<t>Move citation of Namesapce ID up to first instance in v3/v5 #167<
	/t>
	</li>
	<li>
	<t>Further normalize Namespace verbiage #166</t>
	</li>
	<li>
	<t>Fix Timestamp of Time-Based UUIDv8 Example #164</t>
	</li>
	<li>
	<t>Change RFC8937 and RFC4086 to Informative References #163</t>
	</li>
	<li>
	<t>Discuss why v3/v5 are bad for Database Usage #155</t>
	</li>
	</ul>
	<t>draft-12</t>
	<ul spacing="compact">
	<li>
	<t>Typos #148 #156</t>
	</li>
	<li>
	<t>SECDIR Review #141</t>
	</li>
	<li>
	<t>SECDIR Review 2 #142</t>
	</li>
	<li>
	<t>OPSDIR Review #145</t>
	</li>
	<li>
	<t>INDIR Review 2 #140</t>
	</li>
	<li>
	<t>IESG Grammar #146</t>
	</li>
	<li>
	<t>Revise 16-bit MAC Node Usage #149</t>
	</li>
	<li>
	<t>Add MSB3 to Variant Table #153</t>
	</li>
	<li>
	<t>Additional Update Motivations #157</t>
	</li>
	<li>
	<t>Expand v8 Time-based Example to larger timestamp #159</t>
	</li>
	<li>
	<t>Fix Randomized Node value's mcast bit in Appendix #151</t>
	</li>
	<li>
	<t>Clarify "Name-Based" is the same as "Hash-Based" #154</t>
	</li>
	<li>
	<t>Move UUIDv8 Examples out of Test Vectors #150</t>
	</li>
	<li>
	<t>Simplify UUIDv8 Hash-based Example #147</t>
	</li>
	</ul>
	<t>draft-11</t>
	<ul spacing="compact">
	<li>
	<t>Normalize "name space" to "namespace" everywhere #137</t>
	</li>
	<li>
	<t>IANA Review: Verbiage to update RFC4122 references #134</t>
	</li>
	<li>
	<t>DNSDIR re-review: Better Define "a canonical sequence of octets"
	#136</t>
	</li>
	<li>
	<t>Crosspost: Typo in Approximate UUID timestamp calculations #135</
	t>
	</li>
	<li>
	<t>INTDIR Review #139</t>
	</li>
	</ul>
	<t>draft-10</t>
	<ul spacing="compact">
	<li>
	<t>ARTART Review and Feedback #130</t>
	</li>
	<li>
	<t>Clarify Hash Space IDs listed are not the only options #132</t>
	</li>
	<li>
	<t>Add example to timestamp fuzzing #133</t>
	</li>
	</ul>
	<t>draft-09</t>
	<ul spacing="compact">
	<li>
	<t>Late addition of IETF reference for CSPRNG guidance #123</t>
	</li>
	<li>
	<t>DNSDIR Review: Typos! #122</t>
	</li>
	<li>
	<t>DNSDIR Review: DNS Considerations Update #121</t>
	</li>
	<li>
	<t>Error in UUIDv8 Name-based Test Vector #129</t>
	</li>
	<li>
	<t>Improve consistency of layout field definitions #128</t>
	</li>
	</ul>
	<t>draft-08</t>
	<ul spacing="compact">
	<li>
	<t>Fix typos #113</t>
	</li>
	<li>
	<t>Fix errata 6225 (again) #117 #118</t>
	</li>
	<li>
	<t>AD Review: BCP 14 - <bcp14>SHOULD</bcp14> #114</t>
	</li>
	<li>
	<t>AD Review: Add proper references to v1 and v6 #116</t>
	</li>
	<li>
	<t>AD Review: Remove <bcp14>SHOULD</bcp14> in section 4 #120</t>
	</li>
	<li>
	<t>Discuss "front-loaded rollover counter" for 32-bit epoch with Pad
	ding method #115</t>
	</li>
	</ul>
	<t>draft-07</t>
	<ul spacing="compact">
	<li>
	<t>Even more grammar tweaks! #109</t>
	</li>
	<li>
	<t>Remove unnecessary "32 bit" in UUIDv7 example #108</t>
	</li>
	<li>
	<t>Change "fixed millisecond" -> "millisecond by default" relatin
	g to v7 #110</t>
	</li>
	<li>
	<t>Revert Max UUID Naming #107</t>
	</li>
	<li>
	<t>Author Changes</t>
	</li>
	</ul>
	<t>draft-06</t>
	<ul spacing="compact">
	<li>
	<t>More Grammar edits! #102</t>
	</li>
	<li>
	<t>Tweak v7 description to de-emphasize optional components #103</t>
	</li>
	<li>
	<t>Better Clarify Case in ABNF #104</t>
	</li>
	<li>
	<t>Verbiage change in 6.2 #105</t>
	</li>
	</ul>
	<t>draft-05</t>
	<ul spacing="compact">
	<li>
	<t>Changed Max UUID to Max UUID to better complement Latin Nil UUID
	verbiage. #95</t>
	</li>
	<li>
	<t>Align Method 3 text with the 12 bits limitation #96</t>
	</li>
	<li>
	<t>Make Version/version casing consistent across 5. UUID Layouts #97
	</t>
	</li>
	<li>
	<t>Cite MS COM GUID as little-endian #95</t>
	</li>
	</ul>
	<t>draft-04</t>
	<ul spacing="compact">
	<li>
	<t>Remove extra words #82, #88, and #93</t>
	</li>
	<li>
	<t>Punctuation and minor style fixes #84</t>
	</li>
	<li>
	<t>Change rounding mode of Method 4 Section 6.2 #90 (from #86)</t>
	</li>
	<li>
	<t>Add verbal description of v7 generation to 5.7. UUID Version 7 #9
	1</t>
	</li>
	<li>
	<t>Remove Re-randomize Until Monotonic (Method 3) from Monotonicity
	and Counters #92</t>
	</li>
	<li>
	<t>Fix ambiguous text around UUIDv6 clock sequence #89</t>
	</li>
	<li>
	<t>Move endianness statement from layout to format section #85</t>
	</li>
	<li>
	<t>Further modified abstract to separate URN topic from UUID definit
	ion #83</t>
	</li>
	<li>
	<t>Provided three more UUID format examples #83</t>
	</li>
	<li>
	<t>Added text further clarifying version construct is for the varian
	t in this doc #83</t>
	</li>
	<li>
	<t>Provided further clarification for local/global bit vs multicast
	bit #83</t>
	</li>
	</ul>
	<t>draft-03</t>
	<ul spacing="compact">
	<li>
	<t>Revised IANA Considerations #71</t>
	</li>
	<li>
	<t>Fix "integral numbers of octets" verbiage #67</t>
	</li>
	<li>
	<t>Transpose UUID Namespaces to match UUID Hashspaces #70</t>
	</li>
	<li>
	<t>Reference all Hash Algorithms. #69</t>
	</li>
	<li>
	<t>Normalize SHA abbreviation formats #66</t>
	</li>
	<li>
	<t>Add other Hash Abbreviations #65</t>
	</li>
	<li>
	<t>Remove URN from title #73</t>
	</li>
	<li>
	<t>Move Community Considerations to Introduction #68</t>
	</li>
	<li>
	<t>Move some Normative Reference to Informative #74</t>
	</li>
	<li>
	<t>Misc formatting changes to address IDNITS feedback</t>
	</li>
	<li>
	<t>Downgrade <bcp14>MUST NOT</bcp14> to <bcp14>SHOULD NOT</bcp14> fo
	r guessability of UUIDs #75</t>
	</li>
	<li>
	<t>Misc. text formatting, typo fixes #78</t>
	</li>
	<li>
	<t>Misc. text clarifications #79</t>
	</li>
	<li>
	<t>Misc. <bcp14>SHOULD</bcp14>/<bcp14>MUST</bcp14> adjustments #80</
	t>
	</li>
	<li>
	<t>Method 3 and 4 added to monotonic section #81</t>
	</li>
	</ul>
	<t>draft-02</t>
	<ul spacing="compact">
	<li>
	<t>Change md5_high in SHA-1 section to sha1_mid #59</t>
	</li>
	<li>
	<t>Describe Nil/Max UUID in variant table #16</t>
	</li>
	<li>
	<t>Further Clarify that non-descript node IDs are the preferred meth
	od in distributed UUID Generation #49</t>
	</li>
	<li>
	<t>Appendix B, consistent naming #55</t>
	</li>
	<li>
	<t>Remove duplicate ABNF from IANA considerations #56</t>
	</li>
	<li>
	<t>Monotonic Error Checking missing newline #57</t>
	</li>
	<li>
	<t>More Security Considerations Randomness #26</t>
	</li>
	<li>
	<t>SHA-256 UUID Generation #50</t>
	</li>
	<li>
	<t>Expand multiplexed fields within v1 and v6 bit definitions #43</t
	>
	</li>
	<li>
	<t>Clean up text in UUIDs that Do Not Identify the Host #61</t>
	</li>
	<li>
	<t>Revise UUID Generator States section #47</t>
	</li>
	<li>
	<t>Expand upon why unix epoch rollover is not a problem #44</t>
	</li>
	<li>
	<t>Delete Sample Code Appendix #62</t>
	</li>
	</ul>
	<t>draft-01</t>
	<ul spacing="compact">
	<li>
	<t>Mixed Case Spelling error #18</t>
	</li>
	<li>
	<t>Add "UUIDs that Do Not Identify the Host as well" reference to se
	curity considerations #19</t>
	</li>
	<li>
	<t>Out of Place Distributed node text #20</t>
	</li>
	<li>
	<t>v6 clock_seq and node usage ambiguity #21</t>
	</li>
	<li>
	<t>Figure 2 and 3 Fix Title #22</t>
	</li>
	<li>
	<t>Move Namespace Registration Template to IANA Considerations #23</
	t>
	</li>
	<li>
	<t>Verify ABNF formatting against RFC5234 #24</t>
	</li>
	<li>
	<t>Bump ABNF reference to RFC 5234 #25</t>
	</li>
	<li>
	<t>Modify v8 <bcp14>SHOULD NOT</bcp14> to <bcp14>MUST NOT</bcp14> #2
	7</t>
	</li>
	<li>
	<t>Remove "time-based" constraint from version 8 UUID #29</t>
	</li>
	<li>
	<t>Further clarify v7 field description #125 #30</t>
	</li>
	<li>
	<t>Typo: Section 4.2, Version Field, "UUID from in this" #33</t>
	</li>
	<li>
	<t>Create better ABNF to represent Hex Digit #39</t>
	</li>
	<li>
	<t>Break Binary form of UUID into two lines. #40</t>
	</li>
	<li>
	<t>Move octet text from section 4 to section 5 #41</t>
	</li>
	<li>
	<t>Add forward reference to UUIDv1 and UUIDv4 in Section 2 #42</t>
	</li>
	<li>
	<t>Erroneous reference to v1 in monotonicity #45</t>
	</li>
	<li>
	<t>Add Label for "Monotonic Error Checking" paragraph to frame the t
	opic #46</t>
	</li>
	<li>
	<t>Remove IEEE paragraph from "uuids that do not identify the host"
	#48</t>
	</li>
	<li>
	<t>Grammar Review #52</t>
	</li>
	</ul>
	<t>draft-00</t>
	<ul spacing="compact">
	<li>
	<t>Merge RFC4122 with draft-peabody-dispatch-new-uuid-format-04.md</
	t>
	</li>
	<li>
	<t>Change: Reference RFC1321 to RFC6151</t>
	</li>
	<li>
	<t>Change: Reference RFC2141 to RFC8141</t>
	</li>
	<li>
	<t>Change: Reference RFC2234 to RFC5234</t>
	</li>
	<li>
	<t>Change: Reference FIPS 180-1 to FIPS 180-4 for SHA-1</t>
	</li>
	<li>
	<t>Change: Converted UUIDv1 to match UUIDv6 section from Draft 04</t
	>
	</li>
	<li>
	<t>Change: Trimmed down the ABNF representation</t>
	</li>
	<li>
	<t>Change: http websites to https equivalent</t>
	</li>
	<li>
	<t>Errata: Bad Reference to RFC1750 \| 3641 #4</t>
	</li>
	<li>
	<t>Errata: Change MD5 website to example.com \| 3476 #6 (Also Fixes E
	rrata: Fix uuid_create_md5_from_name() \| 1352 #2)</t>
	</li>
	<li>
	<t>Errata: Typo in code comment \| 6665 #11</t>
	</li>
	<li>
	<t>Errata: Fix BAD OID acronym \| 6225 #9</t>
	</li>
	<li>
	<t>Errata: Incorrect Parenthesis usage Section 4.3 \| 184 #5</t>
	</li>
	<li>
	<t>Errata: Lexicographically Sorting Paragraph Fix \| 1428 #3</t>
	</li>
	<li>
	<t>Errata: Fix 4.1.3 reference to the correct bits \| 1957 #13</t>
	</li>
	<li>
	<t>Errata: Fix reference to variant in octet 8 \| 4975 #7</t>
	</li>
	<li>
	<t>Errata: Further clarify 3rd/last bit of Variant for spec \| 5560 #
	8</t>
	</li>
	<li>
	<t>Errata: Fix clock_seq_hi_and_reserved most-significant bit verbia
	ge \| 4976 #10</t>
	</li>
	<li>
	<t>Errata: Better Clarify network byte order when referencing most s
	ignificant bits \| 3546 #12</t>
	</li>
	<li>
	<t>Draft 05: B.2. Example of a UUIDv7 Value two "var" in table #120<
	/t>
	</li>
	<li>
	<t>Draft 05: <bcp14>MUST</bcp14> verbiage in Reliability of 6.1 #121
	</t>
	</li>
	<li>
	<t>Draft 05: Further discourage centralized registry for distributed
	UUID Generation.</t>
	</li>
	<li>
	<t>New: Further Clarity of exact octet and bit of var/ver in this sp
	ec</t>
	</li>
	<li>
	<t>New: Block diagram, bit layout, test vectors for UUIDv4</t>
	</li>
	<li>
	<t>New: Block diagram, bit layout, test vectors for UUIDv3</t>
	</li>
	<li>
	<t>New: Block diagram, bit layout, test vectors for UUIDv5</t>
	</li>
	<li>
	<t>New: Add MD5 Security Considerations reference, RFC6151</t>
	</li>
	<li>
	<t>New: Add SHA-1 Security Considerations reference, RFC6194</t>
	</li>
	</ul>
	</section>	</section>

	</section>
	<section anchor="format">	<section anchor="format">
	<name>UUID Format</name>	<name>UUID Format</name>

	<t>The UUID format is 16 octets (128 bits) in size; the variant bits in co	<t>The UUID format is 16 octets (128 bits) in size; the variant bits in
	njunction with the version	conjunction with the version bits described in the next sections
	bits described in the next sections determine finer structure. While discussing	determine finer structure. In terms of these UUID formats and layout, bit
	UUID formats and layout, bit definitions start at 0 and end at 127 while octet d	definitions start at 0 and end at 127, while octet definitions start at 0
	efinitions start at 0 and end at 15.</t>	and end at 15.</t>
	<t>In the absence of explicit application or presentation protocol	<t>In the absence of explicit application or presentation protocol

	specification to the contrary, each field is encoded with the Most	specification to the contrary, each field is encoded with the most
	Significant Byte first (known as network byte order).</t>	significant byte first (known as "network byte order").</t>
	<t>Saving UUIDs to binary format is done by sequencing all fields in big-e	<t>Saving UUIDs to binary format is done by sequencing all fields in
	ndian format.	big-endian format. However, there is a known caveat that Microsoft's
	However there is a known caveat that Microsoft's Component Object Model (COM) GU	Component Object Model (COM) GUIDs leverage little-endian when saving
	IDs leverage little-endian when saving GUIDs.	GUIDs. The discussion of this (see <xref target="MS_COM_GUID"/>) is outsi
	The discussion of this <xref target="MS_COM_GUID"/> is outside the scope of this	de
	specification.</t>	the scope of this specification.</t>
	<t>UUIDs <bcp14>MAY</bcp14> be represented as binary data or integers.	<t>UUIDs <bcp14>MAY</bcp14> be represented as binary data or integers.

	When in use with URNs or as text in applications, any given UUID should	When in use with URNs or as text in applications, any given UUID should
	be represented by the "hex-and-dash" string format consisting of multiple	be represented by the "hex-and-dash" string format consisting of
	groups of upper or lowercase alphanumeric hexadecimal characters separated by si	multiple groups of uppercase or lowercase alphanumeric hexadecimal
	ngle dashes/hyphens.	characters separated by single dashes/hyphens. When used with databases,
	When used with databases please refer to <xref target="database_considerations"/	please refer to <xref target="database_considerations"/>.</t>
	>.</t>	<t>The formal definition of the UUID string representation is provided by
	<t>The formal definition of the UUID string representation is provided by	the following ABNF <xref target="RFC5234"/>:</t>
	the following (ABNF) <xref target="RFC5234"/>.</t>
	<sourcecode type="abnf"><![CDATA[	<sourcecode type="abnf"><![CDATA[
	UUID = 4hexOctet "-"	UUID = 4hexOctet "-"
	2hexOctet "-"	2hexOctet "-"
	2hexOctet "-"	2hexOctet "-"
	2hexOctet "-"	2hexOctet "-"
	6hexOctet	6hexOctet
	hexOctet = HEXDIG HEXDIG	hexOctet = HEXDIG HEXDIG
	DIGIT = %x30-39	DIGIT = %x30-39
	HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"	HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
	]]></sourcecode>	]]></sourcecode>

	<t>Note that the alphabetic characters may be all uppercase, all lowercase , or mixed case, as per <xref section="2.3" sectionFormat="comma" target="RFC523 4"/>.	<t>Note that the alphabetic characters may be all uppercase, all lowercase , or mixed case, as per <xref section="2.3" sectionFormat="of" target="RFC5234"/ >.
	An example UUID using this textual representation from the above ABNF is shown i n <xref target="sampleStringUUID"/>.</t>	An example UUID using this textual representation from the above ABNF is shown i n <xref target="sampleStringUUID"/>.</t>


	<figure anchor="sampleStringUUID">	<figure anchor="sampleStringUUID">

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

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

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


	<figure anchor="sampleIntegerUUID">	<figure anchor="sampleIntegerUUID">

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


	<figure anchor="sampleURNUUID">	<figure anchor="sampleURNUUID">

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


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

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

		<li><xref target="X667"/> provides UUID format definitions for use of
		UUID with an OID.</li>
		<li><xref target="IBM_NCS"/> is a legacy implementation that produces a
		unique UUID format compatible with Variant 0xx of <xref
		target="table1"/>.</li>
	</ul>	</ul>


	<section anchor="variant_field">	<section anchor="variant_field">
	<name>Variant Field</name>	<name>Variant Field</name>
	<t>The variant field determines the layout of the UUID. That is, the	<t>The variant field determines the layout of the UUID. That is, the

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

	<th align="left">Msb0</th>	<th align="left">MSB0</th>
	<th align="left">Msb1</th>	<th align="left">MSB1</th>
	<th align="left">Msb2</th>	<th align="left">MSB2</th>
	<th align="left">Msb3</th>	<th align="left">MSB3</th>
	<th align="left">Variant</th>	<th align="left">Variant</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">1-7</td>	<td align="left">1-7</td>

	<td align="left">Reserved, NCS backward compatibility and includes	<td align="left">Reserved. Network Computing System (NCS) backward
	Nil UUID as per <xref target="niluuid"/>.</td>	compatibility, and
		includes Nil UUID as per <xref target="niluuid"/>.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">8-9,A-B</td>	<td align="left">8-9,A-B</td>
	<td align="left">The variant specified in this document.</td>	<td align="left">The variant specified in this document.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">C-D</td>	<td align="left">C-D</td>

	<td align="left">Reserved, Microsoft Corporation backward compatib ility.</td>	<td align="left">Reserved. Microsoft Corporation backward compatib ility.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">x</td>	<td align="left">x</td>
	<td align="left">E-F</td>	<td align="left">E-F</td>
	<td align="left">Reserved for future definition and includes Max U UID as per <xref target="maxuuid"/>.</td>	<td align="left">Reserved for future definition and includes Max U UID as per <xref target="maxuuid"/>.</td>
	</tr>	</tr>
	</tbody>	</tbody>

	skipping to change at line 975 ¶	skipping to change at line 403 ¶
	defined here is not guaranteed but is not likely to be an issue in	defined here is not guaranteed but is not likely to be an issue in
	practice.</t>	practice.</t>
	<t>Specifically for UUIDs in this document, bits 64 and 65 of the UUID ( bits 0 and 1 of octet 8) <bcp14>MUST</bcp14> be set to 1 and 0 as specified in r ow 2 of <xref target="table1"/>.	<t>Specifically for UUIDs in this document, bits 64 and 65 of the UUID ( bits 0 and 1 of octet 8) <bcp14>MUST</bcp14> be set to 1 and 0 as specified in r ow 2 of <xref target="table1"/>.
	Accordingly, all bit and field layouts avoid the use of these bits.</t>	Accordingly, all bit and field layouts avoid the use of these bits.</t>
	</section>	</section>
	<section anchor="version_field">	<section anchor="version_field">
	<name>Version Field</name>	<name>Version Field</name>
	<t>The version number is in the most significant 4 bits of octet 6	<t>The version number is in the most significant 4 bits of octet 6
	(bits 48 through 51 of the UUID).</t>	(bits 48 through 51 of the UUID).</t>
	<t><xref target="table2"/> lists all of the versions for this UUID varia nt 10xx specified in this document.</t>	<t><xref target="table2"/> lists all of the versions for this UUID varia nt 10xx specified in this document.</t>


	<table anchor="table2">	<table anchor="table2">

	<name>UUID variant 10xx versions defined by this specification</name>	<name>UUID Variant 10xx Versions Defined by This Specification</name>
	<thead>	<thead>
	<tr>	<tr>

	<th align="left">Msb0</th>	<th align="left">MSB0</th>
	<th align="left">Msb1</th>	<th align="left">MSB1</th>
	<th align="left">Msb2</th>	<th align="left">MSB2</th>
	<th align="left">Msb3</th>	<th align="left">MSB3</th>
	<th align="left">Version</th>	<th align="left">Version</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>

	<td align="left">Unused</td>	<td align="left">Unused.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">The Gregorian time-based UUID specified in this d ocument.</td>	<td align="left">The Gregorian time-based UUID specified in this d ocument.</td>
	</tr>	</tr>
	<tr>	<tr>

	skipping to change at line 1026 ¶	skipping to change at line 455 ¶
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">3</td>	<td align="left">3</td>
	<td align="left">The name-based version specified in this document that uses MD5 hashing.</td>	<td align="left">The name-based version specified in this document that uses MD5 hashing.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">4</td>	<td align="left">4</td>

	<td align="left">The randomly or pseudo-randomly generated version specified in this document.</td>	<td align="left">The randomly or pseudorandomly generated version specified in this document.</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">0</td>	<td align="left">0</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">5</td>	<td align="left">5</td>
	<td align="left">The name-based version specified in this document that uses SHA-1 hashing.</td>	<td align="left">The name-based version specified in this document that uses SHA-1 hashing.</td>
	</tr>	</tr>
	<tr>	<tr>

	skipping to change at line 1118 ¶	skipping to change at line 547 ¶
	<tr>	<tr>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">15</td>	<td align="left">15</td>
	<td align="left">Reserved for future definition.</td>	<td align="left">Reserved for future definition.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>


	<t>An example version/variant layout for UUIDv4 follows the table	<t>An example version/variant layout for UUIDv4 follows the table

	where M represents the version placement for the hexadecimal representation of 0	where "M" represents the version placement for the hexadecimal
	x4 (0b0100)	representation of 0x4 (0b0100) and the "N" represents the variant
	and the N represents the variant placement for one of the four possible hexadeci	placement for one of the four possible hexadecimal representation of
	mal representation of variant 10xx:	variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB
	0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011)</t>	(0b1011).</t>
	<figure>	<figure>
	<name>UUIDv4 Variant Examples</name>	<name>UUIDv4 Variant Examples</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	00000000-0000-4000-8000-000000000000	00000000-0000-4000-8000-000000000000
	00000000-0000-4000-9000-000000000000	00000000-0000-4000-9000-000000000000
	00000000-0000-4000-A000-000000000000	00000000-0000-4000-A000-000000000000
	00000000-0000-4000-B000-000000000000	00000000-0000-4000-B000-000000000000
	xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx	xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>It should be noted that the other remaining UUID variants found in <x ref target="table1"/> leverage different sub-typing/versioning mechanisms.	<t>It should be noted that the other remaining UUID variants found in <x ref target="table1"/> leverage different sub-typing or versioning mechanisms.
	The recording and definition of the remaining UUID variant and sub-typing combin ations are outside of the scope of this document.</t>	The recording and definition of the remaining UUID variant and sub-typing combin ations are outside of the scope of this document.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="layout">	<section anchor="layout">
	<name>UUID Layouts</name>	<name>UUID Layouts</name>

	<t>To minimize confusion about bit assignments within octets and among dif	<t>To minimize confusion about bit assignments within octets and among
	fering versions, the UUID record definition is provided as a grouping of fields	differing versions, the UUID record definition is provided as a grouping
	within a bit layout consisting of four octets per row.	of fields within a bit layout consisting of four octets per row. The
	The fields are presented with the most significant one first.</t>	fields are presented with the most significant one first.</t>
	<section anchor="uuidv1">	<section anchor="uuidv1">
	<name>UUID Version 1</name>	<name>UUID Version 1</name>

	<t>UUID version 1 is a time-based UUID featuring a 60 bit timestamp	<t>UUIDv1 is a time-based UUID featuring a 60-bit timestamp
	represented by Coordinated Universal Time (UTC) as a count of 100-	represented by Coordinated Universal Time (UTC) as a count of
	nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of	100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date
	Gregorian reform to the Christian calendar).</t>	of Gregorian reform to the Christian calendar).</t>
	<t>UUIDv1 also features a clock sequence field which is used to help avo	<t>UUIDv1 also features a clock sequence field that is used to help
	id	avoid duplicates that could arise when the clock is set backwards in
	duplicates that could arise when the clock is set backwards in time	time or if the Node ID changes.</t>
	or if the node ID changes.</t>	<t>The node field consists of an IEEE 802 MAC address, usually the
	<t>The node field consists of an IEEE 802 MAC	host address or a randomly derived value per Sections <xref
	address, usually the host address or a randomly derived value per <xref target="	target="unguessability" format="counter" /> and <xref
	unguessability"/> and <xref target="unidentifiable"/>.</t>	target="unidentifiable" format="counter"/>.</t>

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

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>time_low:</dt>	<dt>time_low:</dt>

	<dd>	<dd>The least significant 32 bits of the 60-bit starting
	<t>The least significant 32 bits of the 60 bit starting timestamp.	timestamp. Occupies bits 0 through 31 (octets 0-3).</dd>
	Occupies bits 0 through 31 (octets 0-3).</t>
	</dd>
	<dt>time_mid:</dt>	<dt>time_mid:</dt>

	<dd>	<dd>The middle 16 bits of the 60-bit starting timestamp. Occupies
	<t>The middle 16 bits of the 60 bit starting timestamp.	bits 32 through 47 (octets 4-5).</dd>
	Occupies bits 32 through 47 (octets 4-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0001 (1). Occupies bits 48
	"/>, set to 0b0001 (1).	through 51 of octet 6. </dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>time_high:</dt>	<dt>time_high:</dt>

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

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>clock_seq:</dt>	<dt>clock_seq:</dt>

	<dd>	<dd>The 14 bits containing the clock sequence. Occupies bits 66
	<t>The 14 bits containing the clock sequence.	through 79 (octets 8-9). </dd>
	Occupies bits 66 through 79 (octets 8-9).</t>
	</dd>
	<dt>node:</dt>	<dt>node:</dt>

	<dd>	<dd>48-bit spatially unique identifier. Occupies bits 80 through
	<t>48 bit spatially unique identifier.	127 (octets 10-15).</dd>
	Occupies bits 80 through 127 (octets 10-15).</t>
	</dd>
	</dl>	</dl>

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

	the clock sequence associated with the changed node ID were known, then	the clock sequence associated with the changed Node ID were known, then
	the clock sequence <bcp14>MAY</bcp14> be incremented, but that is unlikely.</t>	the clock sequence <bcp14>MAY</bcp14> be incremented, but that is unlikely.</t>
	<t>The clock sequence <bcp14>MUST</bcp14> be originally (i.e., once in t he lifetime of	<t>The clock sequence <bcp14>MUST</bcp14> be originally (i.e., once in t he lifetime of
	a system) initialized to a random number to minimize the correlation	a system) initialized to a random number to minimize the correlation

	across systems. This provides maximum protection against node	across systems. This provides maximum protection against Node
	identifiers that may move or switch from system to system rapidly.	IDs that may move or switch from system to system rapidly.
	The initial value <bcp14>MUST NOT</bcp14> be correlated to the node identifier.<	The initial value <bcp14>MUST NOT</bcp14> be correlated to the Node ID.</t>
	/t>
	<t>Notes about IEEE 802 derived nodes:</t>	<t>Notes about nodes derived from IEEE 802:</t>
	<ul spacing="compact">	<ul spacing="normal">
	<li>	<li>On systems with multiple IEEE 802 addresses, any available one
	<t>On systems with multiple IEEE 802 addresses, any available one <b	<bcp14>MAY</bcp14> be used.</li>
	cp14>MAY</bcp14> be used.</t>	<li>On systems with no IEEE address, a randomly or pseudorandomly
	</li>	generated value <bcp14>MUST</bcp14> be used; see Sections <xref
	<li>	target="unguessability" format="counter"/> and <xref
	<t>On systems with no IEEE address, a randomly or pseudo-randomly ge	target="unidentifiable" format="counter"/>.
	nerated value <bcp14>MUST</bcp14> be used; see <xref target="unguessability"/> a
	nd <xref target="unidentifiable"/>.</t>
	</li>
	<li>
	<t>On systems utilizing a 64 bit MAC address the least significant,
	right-most 48 bits <bcp14>MAY</bcp14> be used.</t>
	</li>
	<li>
	<t>On systems utilizing an IEEE 802.15.4 16 bit address <bcp14>SHOUL
	D</bcp14> instead utilize their 64 bit MAC address where least significant, righ
	t-most 48 bits <bcp14>MAY</bcp14> be used. An alternative is to generate 32 bits
	of random data and postfix at the end of the 16 bit MAC address to create a 48
	bit value.</t>
	</li>	</li>

		<li>On systems utilizing a 64-bit MAC address, the least significant,
		rightmost 48 bits <bcp14>MAY</bcp14> be used.</li>

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


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

	<t>UUID version 2 is known as DCE Security UUIDs <xref target="C309"/> a	<t>UUIDv2 is for DCE Security UUIDs (see <xref target="C309"/> and
	nd <xref target="C311"/>.	<xref target="C311"/>). As such, the definition of these UUIDs is
	As such, the definition of these UUIDs is outside the scope of this specificatio	outside the scope of this specification.</t>
	n.</t>
	</section>	</section>
	<section anchor="uuidv3">	<section anchor="uuidv3">
	<name>UUID Version 3</name>	<name>UUID Version 3</name>

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

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>md5_high:</dt>	<dt>md5_high:</dt>

	<dd>	<dd>The first 48 bits of the layout are filled with the most
	<t>The first 48 bits of the layout are filled	significant, leftmost 48 bits from the computed MD5 value. Occupies
	with the most significant, left-most 48 bits	bits 0 through 47 (octets 0-5).</dd>
	from the computed MD5 value. Occupies bits 0 through 47 (octets 0-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0011 (3). Occupies bits 48
	"/>, set to 0b0011 (3).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>md5_mid:</dt>	<dt>md5_mid:</dt>

	<dd>	<dd>12 more bits of the layout consisting of the least significant,
	<t>12 more bits of the layout consisting of the least significant,	rightmost 12 bits of 16 bits immediately following md5_high from
	right-most 12 bits of 16 bits immediately following md5_high	the computed MD5 value. Occupies bits 52 through 63 (octets 6-7).
	from the computed MD5 value.
	Occupies bits 52 through 63 (octets 6-7).</t>
	</dd>	</dd>
	<dt>var:</dt>	<dt>var:</dt>

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>md5_low:</dt>	<dt>md5_low:</dt>

	<dd>	<dd>The final 62 bits of the layout immediately following the var
	<t>The final 62 bits of the layout immediately following the var fie	field to be filled with the least significant, rightmost bits of
	ld to be	the final 64 bits from the computed MD5 value. Occupies bits 66
	filled with the least-significant, right-most bits of the final 64 bits	through 127 (octets 8-15)</dd>
	from the computed MD5 value. Occupies bits 66 through 127 (octets 8-15)</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="uuidv4">	<section anchor="uuidv4">
	<name>UUID Version 4</name>	<name>UUID Version 4</name>

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

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>random_a:</dt>	<dt>random_a:</dt>

	<dd>	<dd>The first 48 bits of the layout that can be filled with random
	<t>The first 48 bits of the layout that can be filled with random da	data as specified in <xref target="unguessability"/>. Occupies bits
	ta as specified in <xref target="unguessability"/>. Occupies bits 0 through 47 (	0 through 47 (octets 0-5).</dd>
	octets 0-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0100 (4). Occupies bits 48
	"/>, set to 0b0100 (4).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>random_b:</dt>	<dt>random_b:</dt>

	<dd>	<dd>12 more bits of the layout that can be filled random data as per
	<t>12 more bits of the layout that can be filled random data as per	<xref target="unguessability"/>. Occupies bits 52 through 63 (octets
	<xref target="unguessability"/>. Occupies bits 52 through 63 (octets 6-7).</t>	6-7).</dd>
	</dd>
	<dt>var:</dt>	<dt>var:</dt>

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>random_c:</dt>	<dt>random_c:</dt>

	<dd>	<dd>The final 62 bits of the layout immediately following the var
	<t>The final 62 bits of the layout immediately following the var fie	field to be filled with random data as per <xref
	ld to be	target="unguessability"/>. Occupies bits 66 through 127 (octets
	filled with random data as per <xref target="unguessability"/>. Occupies bits 66	8-15).</dd>
	through 127 (octets 8-15).</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="uuidv5">	<section anchor="uuidv5">
	<name>UUID Version 5</name>	<name>UUID Version 5</name>

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

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>sha1_high:</dt>	<dt>sha1_high:</dt>

	<dd>	<dd>The first 48 bits of the layout are filled with the most
	<t>The first 48 bits of the layout are filled	significant, leftmost 48 bits from the computed SHA-1 value.
	with the most significant, left-most 48 bits	Occupies bits 0 through 47 (octets 0-5). </dd>
	from the computed SHA-1 value.
	Occupies bits 0 through 47 (octets 0-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0101 (5). Occupies bits 48
	"/>, set to 0b0101 (5).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>sha1_mid:</dt>	<dt>sha1_mid:</dt>

	<dd>	<dd>12 more bits of the layout consisting of the least significant,
	<t>12 more bits of the layout consisting of the least significant,	rightmost 12 bits of 16 bits immediately following sha1_high from
	right-most 12 bits of 16 bits immediately following sha1_high	the computed SHA-1 value. Occupies bits 52 through 63 (octets 6-7).
	from the computed SHA-1 value.
	Occupies bits 52 through 63 (octets 6-7).</t>
	</dd>	</dd>
	<dt>var:</dt>	<dt>var:</dt>

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>sha1_low:</dt>	<dt>sha1_low:</dt>

	<dd>	<dd>The final 62 bits of the layout immediately following the var
	<t>The final 62 bits of the layout immediately following the var fie	field to be filled by skipping the two most significant, leftmost
	ld to be	bits of the remaining SHA-1 hash and then using the next 62 most
	filled by skipping the 2 most significant, left-most bits of the remaining SHA-1	significant, leftmost bits. Any leftover SHA-1 bits are discarded
	hash	and unused. Occupies bits 66 through 127 (octets 8-15).</dd>
	and then using the next 62 most significant, left-most bits.
	Any leftover SHA-1 bits are discarded and unused. Occupies bits 66 through 127 (
	octets 8-15).</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="uuidv6">	<section anchor="uuidv6">
	<name>UUID Version 6</name>	<name>UUID Version 6</name>

	<t>UUID version 6 is a field-compatible version of UUIDv1 <xref target="	<t>UUIDv6 is a field-compatible version of UUIDv1 (<xref
	uuidv1"/>, reordered for improved	target="uuidv1"/>), reordered for improved DB locality. It is expected
	DB locality.	that UUIDv6 will primarily be implemented in contexts where UUIDv1 is us
	It is expected that UUIDv6 will primarily be used in contexts where UUIDv1 is us	ed.
	ed.	Systems that do not involve legacy UUIDv1 <bcp14>SHOULD</bcp14> use
	Systems that do not involve legacy UUIDv1 <bcp14>SHOULD</bcp14> use UUIDv7 <xref	UUIDv7 (<xref target="uuidv7"/>) instead.</t>
	target="uuidv7"/> instead.</t>	<t>Instead of splitting the timestamp into the low, mid, and high
	<t>Instead of splitting the timestamp into the low, mid, and high sectio	sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes
	ns from	are stored from most to least significant. That is, given a 60-bit
	UUIDv1, UUIDv6 changes this sequence so timestamp bytes are stored from most	timestamp value as specified for UUIDv1 in <xref target="uuidv1"/>,
	to least significant.	for UUIDv6 the first 48 most significant bits are stored first,
	That is, given a 60 bit timestamp value as specified for UUIDv1 in <xref target=	followed by the 4-bit version (same position), followed by the
	"uuidv1"/>,	remaining 12 bits of the original 60-bit timestamp.</t>
	for UUIDv6, the first 48 most significant bits are stored	<t>The clock sequence and node bits remain unchanged from their
	first, followed by the 4 bit version (same position), followed by the remaining	position in <xref target="uuidv1"/>.</t>
	12 bits of the original 60 bit timestamp.</t>	<t>The clock sequence and node bits <bcp14>SHOULD</bcp14> be reset to
	<t>The clock sequence and node bits remain unchanged from their positio	a pseudorandom value for each new UUIDv6 generated; however,
	n in <xref target="uuidv1"/>.</t>	implementations <bcp14>MAY</bcp14> choose to retain the old clock
	<t>The clock sequence and node bits <bcp14>SHOULD</bcp14> be reset to a	sequence and MAC address behavior from <xref target="uuidv1"/>. For
	pseudo-random value for each new UUIDv6 generated; however, implementations <bcp	more information on MAC address usage within UUIDs, see the <xref
	14>MAY</bcp14> choose to retain the old clock sequence and MAC address behavior	target="Security"/>.</t>
	from <xref target="uuidv1"/>. For more information on MAC address usage within U	<t>The format for the 16-byte, 128-bit UUIDv6 is shown in <xref
	UIDs see the <xref target="Security"/>.</t>	target="v6layout"/>.</t>
	<t>The format for the 16-byte, 128 bit UUIDv6 is shown in <xref target="
	v6layout"/>.</t>
	<figure anchor="v6layout">	<figure anchor="v6layout">
	<name>UUIDv6 Field and Bit Layout</name>	<name>UUIDv6 Field and Bit Layout</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	0 1 2 3	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	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| time_high \|	\| time_high \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| time_mid \| ver \| time_low \|	\| time_mid \| ver \| time_low \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|var\| clock_seq \| node \|	\|var\| clock_seq \| node \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| node \|	\| node \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<dl newline="true">	<dl spacing="normal" newline="true">
	<dt>time_high:</dt>	<dt>time_high:</dt>

	<dd>	<dd>The most significant 32 bits of the 60-bit starting timestamp.
	<t>The most significant 32 bits of the 60 bit starting timestamp.	Occupies bits 0 through 31 (octets 0-3).</dd>
	Occupies bits 0 through 31 (octets 0-3).</t>
	</dd>
	<dt>time_mid:</dt>	<dt>time_mid:</dt>

	<dd>	<dd>The middle 16 bits of the 60-bit starting timestamp. Occupies
	<t>The middle 16 bits of the 60 bit starting timestamp.	bits 32 through 47 (octets 4-5).</dd>
	Occupies bits 32 through 47 (octets 4-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0110 (6). Occupies bits 48
	"/>, set to 0b0110 (6).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>time_low:</dt>	<dt>time_low:</dt>

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

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>clock_seq:</dt>	<dt>clock_seq:</dt>

	<dd>	<dd>The 14 bits containing the clock sequence. Occupies bits 66
	<t>The 14 bits containing the clock sequence.	through 79 (octets 8-9).</dd>
	Occupies bits 66 through 79 (octets 8-9).</t>
	</dd>
	<dt>node:</dt>	<dt>node:</dt>

	<dd>	<dd>48-bit spatially unique identifier. Occupies bits 80 through
	<t>48 bit spatially unique identifier.	127 (octets 10-15).</dd>
	Occupies bits 80 through 127 (octets 10-15).</t>
	</dd>
	</dl>	</dl>


	<t>With UUIDv6, the steps for splitting the timestamp into time_high and time_mid	<t>With UUIDv6, the steps for splitting the timestamp into time_high and time_mid
	are <bcp14>OPTIONAL</bcp14>	are <bcp14>OPTIONAL</bcp14>
	since the 48 bits of time_high and time_mid will remain in the same order.	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	An extra step of splitting the first 48 bits of the timestamp into the most
	significant	significant
	32 bits and least significant 16 bits proves useful when reusing an existing	32 bits and least significant 16 bits proves useful when reusing an existing
	UUIDv1 implementation.</t>	UUIDv1 implementation.</t>
	</section>	</section>
	<section anchor="uuidv7">	<section anchor="uuidv7">
	<name>UUID Version 7</name>	<name>UUID Version 7</name>

	<t>UUID version 7 features a time-ordered value field derived from the w	<t>UUIDv7 features a time-ordered value field derived from the widely
	idely	implemented and well-known Unix Epoch timestamp source, the number of millisecon
	implemented and well known Unix Epoch timestamp source, the number of millisecon	ds
	ds
	since midnight 1 Jan 1970 UTC, leap seconds excluded.	since midnight 1 Jan 1970 UTC, leap seconds excluded.

	UUIDv7 generally has improved entropy characteristics over UUIDv1 <xref target=" uuidv1"/> or UUIDv6 <xref target="uuidv6"/>.</t>	Generally, UUIDv7 has improved entropy characteristics over UUIDv1 (<xref target ="uuidv1"/>) or UUIDv6 (<xref target="uuidv6"/>).</t>
	<t>UUIDv7 values are created by allocating a Unix timestamp in milliseco nds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 gen erated to provide uniqueness as per <xref target="unguessability"/>. Alternative ly, implementations <bcp14>MAY</bcp14> fill the 74 bits, jointly, with a combina tion of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:</t>	<t>UUIDv7 values are created by allocating a Unix timestamp in milliseco nds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 gen erated to provide uniqueness as per <xref target="unguessability"/>. Alternative ly, implementations <bcp14>MAY</bcp14> fill the 74 bits, jointly, with a combina tion of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:</t>

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


	<t>Implementations <bcp14>SHOULD</bcp14> utilize UUIDv7 instead of UUIDv 1 and UUIDv6 if	<t>Implementations <bcp14>SHOULD</bcp14> utilize UUIDv7 instead of UUIDv 1 and UUIDv6 if
	possible.</t>	possible.</t>
	<figure>	<figure>
	<name>UUIDv7 Field and Bit Layout</name>	<name>UUIDv7 Field and Bit Layout</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	0 1 2 3	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	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| unix_ts_ms \| ver \| rand_a \|	\| unix_ts_ms \| ver \| rand_a \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|var\| rand_b \|	\|var\| rand_b \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| rand_b \|	\| rand_b \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>
	</figure>	</figure>

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

	<dd>	<dd>48-bit big-endian unsigned number of the Unix Epoch timestamp in
	<t>48 bit big-endian unsigned number of Unix epoch timestamp in mill	milliseconds as per <xref target="timestamp_considerations"/>.
	iseconds as	Occupies bits 0 through 47 (octets 0-5).</dd>
	per <xref target="timestamp_considerations"/>.
	Occupies bits 0 through 47 (octets 0-5).</t>
	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b0111 (7). Occupies bits 48
	"/>, set to 0b0111 (7).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>rand_a:</dt>	<dt>rand_a:</dt>

	<dd>	<dd>12 bits of pseudorandom data to provide uniqueness as per <xref
	<t>12 bits pseudo-random data to provide uniqueness as per <xref tar	target="unguessability"/> and/or optional constructs to guarantee
	get="unguessability"/>	additional monotonicity as per <xref
	and/or optional constructs to guarantee additional monotonicity as	target="monotonicity_counters"/>. Occupies bits 52 through 63
	per <xref target="monotonicity_counters"/>.	(octets 6-7).</dd>
	Occupies bits 52 through 63 (octets 6-7).</t>
	</dd>
	<dt>var:</dt>	<dt>var:</dt>

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>rand_b:</dt>	<dt>rand_b:</dt>

	<dd>	<dd>The final 62 bits of pseudorandom data to provide uniqueness as
	<t>The final 62 bits of pseudo-random data to provide uniqueness as	per <xref target="unguessability"/> and/or an optional counter to
	per <xref target="unguessability"/>	guarantee additional monotonicity as per <xref
	and/or an optional counter to guarantee additional monotonicity as per <xref tar	target="monotonicity_counters"/>. Occupies bits 66 through 127
	get="monotonicity_counters"/>.	(octets 8-15).</dd>
	Occupies bits 66 through 127 (octets 8-15).</t>
	</dd>
	</dl>	</dl>


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

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


	<ul spacing="normal">	<ul spacing="normal">

	<li>	<li>An implementation would like to embed extra information
	<t>An implementation would like to embed extra information	within the UUID other than what is defined in this document.</li>
	within the UUID other than what is defined in this document.</t>	<li>An implementation has other application and/or language
	</li>	restrictions that inhibit the use of one of the current UUIDs.</li>
	<li>
	<t>An implementation has other application/language restrictions whi
	ch
	inhibit the use of one of the current UUIDs.</t>
	</li>
	</ul>	</ul>

	<t>The appendix, <xref target="ill_examples"/>, provides two illustrativ
	e examples of custom UUIDv8 algorithms to address two example scenarios.</t>	<t><xref target="ill_examples"/> provides two illustrative examples of
		custom UUIDv8 algorithms to address two example scenarios.</t>
	<figure>	<figure>
	<name>UUIDv8 Field and Bit Layout</name>	<name>UUIDv8 Field and Bit Layout</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	0 1 2 3	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	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 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| custom_a \| ver \| custom_b \|	\| custom_a \| ver \| custom_b \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\|var\| custom_c \|	\|var\| custom_c \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| custom_c \|	\| custom_c \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>custom_a:</dt>	<dt>custom_a:</dt>

	<dd>	<dd>The first 48 bits of the layout that can be filled as an
	<t>The first 48 bits of the layout that can be filled as an implemen	implementation sees fit. Occupies bits 0 through 47 (octets 0-5).
	tation sees
	fit. Occupies bits 0 through 47 (octets 0-5).</t>
	</dd>	</dd>
	<dt>ver:</dt>	<dt>ver:</dt>

	<dd>	<dd>The 4-bit version field as defined by <xref
	<t>The 4 bit version field as defined by <xref target="version_field	target="version_field"/>, set to 0b1000 (8). Occupies bits 48
	"/>, set to 0b1000 (8).	through 51 of octet 6.</dd>
	Occupies bits 48 through 51 of octet 6.</t>
	</dd>
	<dt>custom_b:</dt>	<dt>custom_b:</dt>

	<dd>	<dd>12 more bits of the layout that can be filled as an
	<t>12 more bits of the layout that can be filled as an implementatio	implementation sees fit. Occupies bits 52 through 63 (octets 6-7).
	n sees fit.
	Occupies bits 52 through 63 (octets 6-7).</t>
	</dd>	</dd>
	<dt>var:</dt>	<dt>var:</dt>

	<dd>	<dd>The 2-bit variant field as defined by <xref
	<t>The 2 bit variant field as defined by <xref target="variant_field	target="variant_field"/>, set to 0b10. Occupies bits 64 and 65 of
	"/>, set to 0b10.	octet 8.</dd>
	Occupies bits 64 and 65 of octet 8.</t>
	</dd>
	<dt>custom_c:</dt>	<dt>custom_c:</dt>

	<dd>	<dd>The final 62 bits of the layout immediately following the var
	<t>The final 62 bits of the layout immediately following the var fie	field to be filled as an implementation sees fit. Occupies bits 66
	ld to be	through 127 (octets 8-15).</dd>
	filled as an implementation sees fit.
	Occupies bits 66 through 127 (octets 8-15).</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="niluuid">	<section anchor="niluuid">
	<name>Nil UUID</name>	<name>Nil UUID</name>

	<t>The nil UUID is special form of UUID that is specified to have all	<t>The Nil UUID is special form of UUID that is specified to have all
	128 bits set to zero.</t>	128 bits set to zero.</t>


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

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

	<t>The Max UUID is a special form of UUID that is specified to have all	<t>The Max UUID is a special form of UUID that is specified to have
	128 bits	all 128 bits set to 1. This UUID can be thought of as the inverse of
	set to 1. This UUID can be thought of as the inverse of Nil UUID defined	the Nil UUID defined in <xref target="niluuid"/>.</t>
	in <xref target="niluuid"/>.</t>
	<figure>	<figure>
	<name>Max UUID Format</name>	<name>Max UUID Format</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF	FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>A Max UUID value can be used as a sentinel value in situations where
	a 128 bit UUID is required but a concept such as "end of UUID list" needs to be	<t>A Max UUID value can be used as a sentinel value in situations
	expressed, and is reserved for such use as needed for implementation-specific si	where a 128-bit UUID is required, but a concept such as "end of UUID
	tuations.</t>	list" needs to be expressed and is reserved for such use as needed
	<t>Note that the Max UUID value falls within the range of the "yet to be	for implementation-specific situations.</t>
	defined" future UUID variant as per the last row of <xref target="table1"/> rat	<t>Note that the Max UUID value falls within the range of the "yet-to-be
	her than the variant defined by this document.</t>	defined" future UUID variant as per the last row of <xref
		target="table1"/> rather than the variant defined by this
		document.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="uuid_best_practices">	<section anchor="uuid_best_practices">
	<name>UUID Best Practices</name>	<name>UUID Best Practices</name>

	<t>The minimum requirements for generating UUIDs are	<t>The minimum requirements for generating UUIDs of each version are descr
	described in this document for each version.	ibed in this
	Everything else is an implementation detail and it is	document. Everything else is an implementation detail,
	up to the implementer to decide what is appropriate for a given	and it is up to the implementer to decide what is appropriate for a
	implementation. Various relevant factors are covered	given implementation. Various relevant factors are covered below to help
	below to help guide an implementer through the different trade-offs among	guide an implementer through the different trade-offs among differing
	differing UUID implementations.</t>	UUID implementations.</t>
	<section anchor="timestamp_considerations">	<section anchor="timestamp_considerations">
	<name>Timestamp Considerations</name>	<name>Timestamp Considerations</name>

	<t>UUID timestamp source, precision, and length was the topic of great d	<t>UUID timestamp source, precision, and length were topics of great
	ebate	debate while creating UUIDv7 for this specification. Choosing the
	while creating UUIDv7 for this specification. Choosing the right timestamp for	right timestamp for your application is very important. This
	your application is a very important topic. This section will detail some	section will detail some of the most common points on this issue.</t>
	of the most common points on this topic.</t>
	<dl newline="true">	<dl spacing="normal" newline="true">
	<dt>Reliability:</dt>	<dt>Reliability:</dt>

	<dd>	<dd>Implementations acquire the current timestamp from a reliable
	<t>Implementations acquire the current timestamp from a reliable sou	source to provide values that are time ordered and continually
	rce to	increasing. Care must be taken to ensure that timestamp changes
	provide values that are time-ordered and continually increasing.	from the environment or operating system are handled in a way that
	Care must be taken to ensure that timestamp changes from the environment	is consistent with implementation requirements. For example, if it
	or operating system are handled in a way that is consistent with implementation	is possible for the system clock to move backward due to either
	requirements.	manual adjustment or corrections from a time synchronization
	For example, if it is possible for the system clock to move backward due	protocol, implementations need to determine how to handle such
	to either manual adjustment or corrections from a time synchronization protocol,	cases. (See "Altering, Fuzzing, or Smearing" below.)</dd>
	implementations need to determine how to handle such cases. (See Altering, Fuzzi
	ng,
	or Smearing below.)</t>
	</dd>
	<dt>Source:</dt>	<dt>Source:</dt>

	<dd>	<dd>UUIDv1 and UUIDv6 both utilize a Gregorian Epoch timestamp,
	<t>UUID version 1 and 6 both utilize a Gregorian epoch timestamp whi	while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp
	le UUIDv7	sources or a custom timestamp Epoch are required, UUIDv8
	utilizes a Unix Epoch timestamp. If other timestamp sources or a custom timestam	<bcp14>MUST</bcp14> be used.</dd>
	p
	epoch are required, UUIDv8 <bcp14>MUST</bcp14> be used.</t>
	</dd>
	<dt>Sub-second Precision and Accuracy:</dt>	<dt>Sub-second Precision and Accuracy:</dt>

	<dd>	<dd>Many levels of precision exist for timestamps: milliseconds,
	<t>Many levels of precision exist for timestamps: milliseconds, micr	microseconds, nanoseconds, and beyond. Additionally, fractional
	oseconds,	representations of sub-second precision may be desired to mix
	nanoseconds, and beyond.	various levels of precision in a time-ordered manner. Furthermore,
	Additionally fractional representations of sub-second precision may be desired	system clocks themselves have an underlying granularity, which is
	to mix various levels of precision in a time-ordered manner.	frequently less than the precision offered by the operating system.
	Furthermore, system clocks themselves have an underlying granularity and	With UUIDv1 and UUIDv6, 100 nanoseconds of precision are present,
	it is frequently less than the precision offered by the operating system.	while UUIDv7 features a millisecond level of precision by default
	With UUID version 1 and 6, 100-nanoseconds of precision are present while	within the Unix Epoch that does not exceed the granularity capable
	UUIDv7 features millisecond level of precision by default within the Unix epoch	in most modern systems. For other levels of precision, UUIDv8 is
	that does not exceed the granularity capable in most modern systems.	available. Similar to <xref target="monotonicity_counters"/>, with
	For other levels of precision UUIDv8 is available.	UUIDv1 or UUIDv6, a high-resolution timestamp can be simulated by
	Similar to <xref target="monotonicity_counters"/>, with UUIDv1 or UUIDv6,	keeping a count of the number of UUIDs that have been generated with
	a high resolution timestamp can be simulated by keeping a count of	the same value of the system time and using that count to construct th
	the number of UUIDs that have been generated with the same value of	e low
	the system time, and using it to construct the low order bits of the	order bits of the timestamp. The count of the high-resolution
	timestamp. The count of the high resolution timestamp will range between zero a	timestamp will range between zero and the number of 100-nanosecond
	nd the number of	intervals per system-time interval.</dd>
	100-nanosecond intervals per system time interval.</t>
	</dd>
	<dt>Length:</dt>	<dt>Length:</dt>

	<dd>	<dd>The length of a given timestamp directly impacts how many
	<t>The length of a given timestamp directly impacts how many timesta	timestamp ticks can be contained in a UUID before the maximum value
	mp ticks can be contained in a UUID before the maximum	for the timestamp field is reached. Take care to ensure that the
	value for the timestamp field is reached.	proper length is selected for a given timestamp. UUIDv1 and
	Take care to ensure that the proper length is selected for a given	UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7 features
	timestamp.	a 48-bit timestamp valid until the year 10889 AD.</dd>
	UUID version 1 and 6 utilize a 60 bit timestamp valid until 5623 AD and UUIDv7 f
	eatures a 48
	bit timestamp valid until the year 10889 AD.</t>
	</dd>
	<dt>Altering, Fuzzing, or Smearing:</dt>	<dt>Altering, Fuzzing, or Smearing:</dt>

	<dd>	<dd>Implementations <bcp14>MAY</bcp14> alter the actual
	<t>Implementations <bcp14>MAY</bcp14> alter the actual timestamp. So	timestamp. Some examples include security considerations around
	me examples include security	providing a real-clock value within a UUID to 1) correct inaccurate
	considerations around providing a real clock value within a UUID, to correct	clocks, 2) handle leap seconds, or 3) obtain a millisecond value by
	inaccurate clocks, to handle leap seconds, or instead of dividing a number of mi	dividing by 1024 (or some other value) for performance reasons
	croseconds by 1000 to obtain a millisecond value; dividing by 1024 (or some othe	(instead of dividing a number of microseconds by 1000). This
	r value) for performance reasons. This specification makes no	specification makes no requirement or guarantee about how close the
	requirement or guarantee about how close the clock value needs to be to the actu	clock value needs to be to the actual time. If UUIDs do not need to
	al	be frequently generated, the UUIDv1 or UUIDv6 timestamp can simply
	time.	be the system time multiplied by the number of 100-nanosecond
	If UUIDs do not need to be frequently generated, the UUIDv1 or UUIDv6 timestamp	intervals per system-time interval.</dd>
	can
	simply be the system time multiplied by the number of 100-nanosecond
	intervals per system time interval.</t>
	</dd>
	<dt>Padding:</dt>	<dt>Padding:</dt>

	<dd>	<dd>When timestamp padding is required, implementations
	<t>When timestamp padding is required, implementations <bcp14>MUST</	<bcp14>MUST</bcp14> pad the most significant bits (leftmost)
	bcp14> pad the most significant	with data. An example for this padding data is to fill the most
	bits (left-most) bits with data. An example for this padding data is to fill the	significant, leftmost bits of a Unix timestamp with zeroes to
	most significant,	complete the 48-bit timestamp in UUIDv7. An alternative approach for
	left-most bits of a Unix timestamp with zeroes to complete the 48	padding data is to fill the most significant, leftmost bits with
	bit timestamp in UUIDv7. An alternative approach for padding data is to fill the	the number of 32-bit Unix timestamp rollovers after 2038-01-19.
	most significant, left-most bits with the number of 32 bit Unix timestamp roll-
	overs after 2038-01-19.</t>
	</dd>	</dd>
	<dt>Truncating:</dt>	<dt>Truncating:</dt>

	<dd>	<dd>When timestamps need to be truncated, the lower, least
	<t>When timestamps need to be truncated, the lower, least significan	significant bits <bcp14>MUST</bcp14> be used. An example would be
	t	truncating a 64-bit Unix timestamp to the least significant,
	bits <bcp14>MUST</bcp14> be used. An example would be truncating a 64 bit Unix t	rightmost 48 bits for UUIDv7.</dd>
	imestamp
	to the least significant, right-most 48 bits for UUIDv7.</t>
	</dd>
	<dt>Error Handling:</dt>	<dt>Error Handling:</dt>

	<dd>	<dd>If a system overruns the generator by requesting too many UUIDs
	<t>If a system overruns the generator by requesting too many UUIDs	within a single system-time interval, the UUID service can return an
	within a single system time interval, the UUID service can	error or stall the UUID generator until the system clock catches
	return an error, or stall the UUID generator until the system clock	up and <bcp14>MUST NOT</bcp14> knowingly return duplicate values
	catches up, and <bcp14>MUST NOT</bcp14> return knowingly duplicate values due to	due to a counter rollover. Note that if the processors overrun the
	a	UUID generation frequently, additional Node IDs can be
	counter rollover.	allocated to the system, which will permit higher speed allocation
	Note that if the processors overrun the UUID generation frequently,	by making multiple UUIDs potentially available for each timestamp
	additional node identifiers can be allocated to the system, which	value. Similar techniques are discussed in <xref
	will permit higher speed allocation by making multiple UUIDs	target="distributed_shared_knowledge"/>.</dd>
	potentially available for each time stamp value.
	Similar techniques are discussed in <xref target="distributed_shared_knowledge"/
	>.</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="monotonicity_counters">	<section anchor="monotonicity_counters">
	<name>Monotonicity and Counters</name>	<name>Monotonicity and Counters</name>

	<t>Monotonicity (each subsequent value being greater than the last) is t	<t>Monotonicity (each subsequent value being greater than the last) is
	he backbone of time-based sortable UUIDs. Normally, time-based	the backbone of time-based sortable UUIDs. Normally, time-based UUIDs
	UUIDs from this document will be monotonic due to an embedded timestamp; however	from this document will be monotonic due to an embedded timestamp;
	,	however, implementations can guarantee additional monotonicity via the
	implementations can guarantee additional monotonicity via the concepts covered	concepts covered in this section.</t>
	in this section.</t>	<t>Take care to ensure UUIDs generated in batches are also
	<t>Take care to ensure UUIDs generated in batches are	monotonic. That is, if one thousand UUIDs are generated for the same
	also monotonic. That is, if one thousand UUIDs are generated for the same	timestamp, there should be sufficient logic for organizing the
	timestamp, there should be sufficient logic for organizing the creation order of	creation order of those one thousand UUIDs. Batch UUID creation
	those one thousand UUIDs.	implementations <bcp14>MAY</bcp14> utilize a monotonic counter that
	Batch UUID creation implementations <bcp14>MAY</bcp14> utilize a monotonic count	increments for each UUID created during a given timestamp.</t>
	er that	<t>For single-node UUID implementations that do not need to create
	increments for each UUID created during a given timestamp.</t>	batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7
	<t>For single-node UUID implementations that do not need to create batch	can provide sufficient monotonicity guarantees by simply ensuring that
	es of	timestamp increments before creating a new UUID. Distributed nodes are
	UUIDs, the embedded timestamp within UUID version 6 and 7 can provide	discussed in <xref target="distributed_shared_knowledge"/>.</t>
	sufficient monotonicity guarantees by simply ensuring that timestamp increments	<t>Implementations <bcp14>SHOULD</bcp14> employ the following methods
	before creating a new UUID. Distributed nodes are discussed in	for single-node UUID implementations that require batch UUID creation
	<xref target="distributed_shared_knowledge"/>.</t>	or are otherwise concerned about monotonicity with high-frequency UUID
	<t>Implementations <bcp14>SHOULD</bcp14> employ the following methods fo	generation.</t>
	r single-node UUID implementations
	that require batch UUID creation, or are otherwise concerned about monotonicity	<dl spacing="normal" newline="true">
	with high frequency UUID generation.</t>	<dt>Fixed Bit-Length Dedicated Counter (Method 1):</dt>
	<dl newline="true">	<dd>Some implementations allocate a specific number of bits in the
	<dt>Fixed-Length Dedicated Counter Bits (Method 1):</dt>	UUID layout to the sole purpose of tallying the total number of
	<dd>	UUIDs created during a given UUID timestamp tick. If present, a fixed
	<t>Some implementations allocate a specific number of bits in the	bit-length counter <bcp14>MUST</bcp14> be positioned
	UUID layout to the sole purpose of tallying the total number of UUIDs created	immediately after the embedded timestamp. This promotes sortability
	during a given UUID timestamp tick.	and allows random data generation for each counter increment.
	A fixed bit-length counter, if present, <bcp14>MUST</bcp14> be positioned immedi	With
	ately after the	this method, the rand_a section (or a subset of its leftmost bits)
	embedded timestamp. This promotes sortability and allows random data generation	of UUIDv7 is used as a fixed bit-length dedicated counter that is
	for each counter increment.	incremented for every UUID generation. The trailing random bits
	With this method, the rand_a section (or a subset of its left-most bits) of UUID	generated for each new UUID in rand_b can help produce unguessable
	v7	UUIDs. In the event that more counter bits are required, the most
	is used as fixed-length dedicated counter bits that are incremented for	significant (leftmost) bits of rand_b <bcp14>MAY</bcp14> be used as
	every UUID generation.	additional counter bits.</dd>
	The trailing random bits generated for each new UUID in rand_b can help produce
	unguessable UUIDs. In the event more counter bits are required, the most signifi
	cant
	(left-most) bits of rand_b <bcp14>MAY</bcp14> be used as additional counter bits
	.</t>
	</dd>
	<dt>Monotonic Random (Method 2):</dt>	<dt>Monotonic Random (Method 2):</dt>

	<dd>	<dd>With this method, the random data is extended to also function
	<t>With this method, the random data is extended to also function as	as a counter. This monotonic value can be thought of as a "randomly
	a counter.	seeded counter" that <bcp14>MUST</bcp14> be incremented in the
	This monotonic value can be thought of as a "randomly seeded counter" which	least significant position for each UUID created on a given
	<bcp14>MUST</bcp14> be incremented in the least significant position for each UU	timestamp tick. UUIDv7's rand_b section <bcp14>SHOULD</bcp14> be
	ID created	utilized with this method to handle batch UUID generation during a
	on a given timestamp tick.	single timestamp tick. The increment value for every UUID
	UUIDv7's rand_b section <bcp14>SHOULD</bcp14> be utilized with this method to ha	generation is a random integer of any desired length larger than
	ndle batch	zero. It ensures that the UUIDs retain the required level of
	UUID generation during a single timestamp tick.	unguessability provided by the underlying entropy. The increment
	The increment value for every UUID generation is a random integer	value <bcp14>MAY</bcp14> be 1 when the number of UUIDs generated in
	of any desired length larger than zero. It ensures the UUIDs retain the required	a particular period of time is important and guessability is not an
	level of unguessability provided by the underlying entropy.	issue. However, incrementing the counter by 1 <bcp14>SHOULD
	The increment value <bcp14>MAY</bcp14> be 1 when the number of UUIDs generated i	NOT</bcp14> be used by implementations that favor unguessability, as
	n a particular	the resulting values are easily guessable.</dd>
	period of time is important and guessability is not an issue. However, increment	<dt>Replace Leftmost Random Bits with Increased Clock Precision (Metho
	ing the counter by 1	d 3):</dt>
	<bcp14>SHOULD NOT</bcp14> be used by implementations that favor unguessability,	<dd><t>For UUIDv7, which has millisecond timestamp precision, it is
	as the resulting	possible to use additional clock precision available on the system
	values are easily guessable.</t>	to substitute for up to 12 random bits immediately following the
	</dd>	timestamp. This can provide values that are time ordered with
	<dt>Replace Left-Most Random Bits with Increased Clock Precision (Meth	sub-millisecond precision, using however many bits are appropriate
	od 3):</dt>	in the implementation environment. With this method, the additional
	<dd>	time precision bits <bcp14>MUST</bcp14> follow the timestamp as the
	<t>For UUIDv7, which has millisecond timestamp precision, it is poss	next available bit in the rand_a field for UUIDv7.</t>
	ible	<t>To calculate this value, start with the portion of the timestamp
	to use additional clock precision available on the system to substitute	expressed as a fraction of the clock's tick value (fraction of a
	for up to 12 random bits immediately following the timestamp. This can provide	millisecond for UUIDv7). Compute the count of possible values that
	values that are time-ordered with sub-millisecond precision, using	can be represented in the available bit space, 4096 for the UUIDv7
	however many bits are appropriate in the implementation environment.	rand_a field. Using floating point or scaled integer arithmetic,
	With this method, the additional time precision bits <bcp14>MUST</bcp14> follow	multiply this fraction of a millisecond value by 4096 and round down
	the	(toward zero) to an integer result to arrive at a number between 0
	timestamp as the next available bit, in the rand_a field for UUIDv7.	and the maximum allowed for the indicated bits, which sorts
	</t>	monotonically based on time. Each increasing fractional value will
	<t>To calculate this value, start with the portion of the timestamp	result in an increasing bit field value to the precision available
	expressed as a fraction of clock's tick value (fraction of a millisecond	with these bits.</t>
	for UUIDv7). Compute the count of possible values that can be represented in	<t>For example, let's assume a system timestamp of 1 Jan 2023
	the available bit space, 4096 for the UUIDv7 rand_a field.	12:34:56.1234567. Taking the precision greater than 1 ms gives us a
	Using floating point or scaled integer arithmetic, multiply this fraction of a m	value of 0.4567, as a fraction of a millisecond. If we wish to
	illisecond	encode this as 12 bits, we can take the count of possible values
	value by 4096 and round down (toward zero) to an integer result to arrive at a n	that fit in those bits (4096 or 2<sup>12</sup>), multiply it by our
	umber	millisecond fraction value of 0.4567, and truncate the result to an
	between 0 and the maximum allowed for the indicated bits	integer, which gives an integer value of 1870. Expressed as
	which sorts monotonically based on time. Each increasing fractional	hexadecimal, it is 0x74E or the binary bits 0b011101001110. One can
	value will result in an increasing bit field value, to the	then use those 12 bits as the most significant (leftmost) portion of
	precision available with these bits.</t>	the random section of the UUID (e.g., the rand_a field in UUIDv7).
	<t>For example, let's assume a system timestamp of 1 Jan 2023 12:34:	This works for any desired bit length that fits into a UUID, and
	56.1234567.	applications can decide the appropriate length based on available
	Taking the precision greater than 1ms gives us a value of 0.4567, as a	clock precision; for UUIDv7, it is limited to 12 bits at maximum to
	fraction of a millisecond. If we wish to encode this as 12 bits, we can	reserve sufficient space for random bits.</t>
	take the count of possible values that fit in those bits (4096, or 2 to the 12th	<t>The main benefit to encoding additional timestamp precision is
	power)	that it utilizes additional time precision already available in the
	and multiply it by our millisecond fraction value of 0.4567 and truncate the res	system clock to provide values that are more likely to be unique; thus
	ult to	, it may simplify certain implementations. This technique can
	an integer, which gives an integer value of 1870. Expressed as hexadecimal it is	also be used in conjunction with one of the other methods, where
	0x74E, or the binary bits 0b011101001110. One can then use those 12 bits	this additional time precision would immediately follow the
	as the most significant (left-most) portion of the random section of the UUID	timestamp. Then, if any bits are to be used as a clock sequence,
	(e.g., the rand_a field in UUIDv7).	they would follow next.</t></dd>
	This works for any desired bit length that fits into a UUID, and applications
	can decide the appropriate length based on available clock precision, but for
	UUIDv7, it is limited to 12 bits at maximum to reserve sufficient space for
	random bits.</t>
	<t>The main benefit to encoding additional timestamp precision
	is that it utilizes additional time precision already available in the system cl
	ock
	to provide values that are more likely to be unique, and thus may simplify
	certain implementations. This technique can also be used in conjunction with one
	of the other methods, where this additional time precision would immediately
	follow the timestamp, and then if any bits are to be used as clock sequence
	they would follow next.</t>
	</dd>
	</dl>	</dl>

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

		<dt>Fixed Bit-Length Dedicated Counter Length:</dt>
		<dd>Select a counter bit-length that can properly handle the level
		of timestamp precision in use. For example, millisecond precision
		generally requires a larger counter than a timestamp with nanosecond
		precision. General guidance is that the counter
		<bcp14>SHOULD</bcp14> be at least 12 bits but no longer than 42
		bits. Care must be taken to ensure that the counter length selected
		leaves room for sufficient entropy in the random portion of the UUID
		after the counter. This entropy helps improve the unguessability
		characteristics of UUIDs created within the batch.</dd>
	</dl>	</dl>


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

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>Counter Rollover Guards:</dt>	<dt>Counter Rollover Guards:</dt>

	<dd>	<dd>The technique from "Fixed Bit-Length Dedicated Counter Seeding" ab
	<t>The technique from Fixed-Length Dedicated Counter Seeding that de	ove that
	scribes	describes allocating a segment of the fixed bit-length counter as a
	allocating a segment of the fixed-length counter as a rollover guard is also	rollover guard is also helpful to mitigate counter rollover issues.
	helpful to mitigate counter rollover issues.	This same technique can be used with monotonic random counter
	This same technique can be used with monotonic random counter methods	methods by ensuring that the total length of a possible increment in
	by ensuring that the total length of a possible increment in the least significa	the least significant, rightmost position is less than the total
	nt,	length of the random value being incremented. As such, the most
	right most position is less than the total length of the random value being incr	significant, leftmost bits can be incremented as rollover
	emented.	guarding.</dd>
	As such, the most significant, left-most, bits can be incremented as rollover
	guarding.</t>
	</dd>
	<dt>Counter Rollover Handling:</dt>	<dt>Counter Rollover Handling:</dt>

	<dd>	<dd>Counter rollovers <bcp14>MUST</bcp14> be handled by the
	<t>Counter rollovers <bcp14>MUST</bcp14> be handled by the applicati	application to avoid sorting issues. The general guidance is that
	on to avoid sorting issues.	applications that care about absolute monotonicity and sortability
	The general guidance is that applications that care about absolute monotonicity	should freeze the counter and wait for the timestamp to advance,
	and sortability should freeze the counter and wait for the timestamp to advance	which ensures monotonicity is not broken. Alternatively,
	which ensures monotonicity is not broken.	implementations <bcp14>MAY</bcp14> increment the timestamp ahead of
	Alternatively, implementations <bcp14>MAY</bcp14> increment the timestamp ahead	the actual time and reinitialize the counter.</dd>
	of the actual
	time and reinitialize the counter.</t>
	</dd>
	</dl>	</dl>

	<t>Implementations <bcp14>MAY</bcp14> use the following logic to ensure
	UUIDs featuring embedded	<t>Implementations <bcp14>MAY</bcp14> use the following logic to
	counters are monotonic in nature:</t>	ensure UUIDs featuring embedded counters are monotonic in nature:</t>
	<ol spacing="normal" type="1"><li>
	<t>Compare the current timestamp against the previously stored times	<ol spacing="normal" type="1">
	tamp.</t>	<li>Compare the current timestamp against the previously stored
	</li>	timestamp.</li>
	<li>	<li>If the current timestamp is equal to the previous timestamp,
	<t>If the current timestamp is equal to the previous timestamp, incr	increment the counter according to the desired method.</li>
	ement the	<li>If the current timestamp is greater than the previous timestamp,
	counter according to the desired method.</t>	re-initialize the desired counter method to the new timestamp and
	</li>	generate new random bytes (if the bytes were frozen or being used as
	<li>	the seed for a monotonic counter). </li>
	<t>If the current timestamp is greater than the previous timestamp,
	re-initialize
	the desired counter method to the new timestamp and generate new random bytes
	(if the bytes were frozen or being used as the seed for a monotonic counter).<
	/t>
	</li>
	</ol>	</ol>

	<dl newline="true">
		<dl spacing="normal" newline="true">
	<dt>Monotonic Error Checking:</dt>	<dt>Monotonic Error Checking:</dt>

	<dd>	<dd>Implementations <bcp14>SHOULD</bcp14> check if the currently
	<t>Implementations <bcp14>SHOULD</bcp14> check if the currently gene	generated UUID is greater than the previously generated UUID. If
	rated UUID is greater	this is not the case, then any number of things could have occurred,
	than the previously generated UUID. If this is not the case then any number	such as clock rollbacks, leap second handling, and counter
	of things could have occurred, such as clock rollbacks,	rollovers. Applications <bcp14>SHOULD</bcp14> embed sufficient logic
	leap second handling, and counter rollovers. Applications <bcp14>SHOULD</bcp14>	to catch these scenarios and correct the problem to ensure that the
	embed sufficient	next UUID generated is greater than the previous, or they should at le
	logic to catch these scenarios and correct the problem to ensure that the next	ast report
	UUID generated is greater than the previous, or at least report an appropriate e	an appropriate error. To handle this scenario, the general guidance
	rror.	is that the application <bcp14>MAY</bcp14> reuse the previous timestam
	To handle this scenario, the	p
	general guidance is that application <bcp14>MAY</bcp14> reuse the previous times	and increment the previous counter method. </dd>
	tamp and
	increment the previous counter method.</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="generator_states">	<section anchor="generator_states">
	<name>UUID Generator States</name>	<name>UUID Generator States</name>

	<t>The (optional) UUID generator state only needs to be read from stable	<t>The (optional) UUID generator state only needs to be read from
	storage once at boot	stable storage once at boot time, if it is read into a system-wide
	time, if it is read into a system-wide shared volatile store (and	shared volatile store (and updated whenever the stable store is
	updated whenever the stable store is updated).</t>	updated).</t>
	<t>This stable storage <bcp14>MAY</bcp14> be used to record various port	<t>This stable storage <bcp14>MAY</bcp14> be used to record various
	ions of the UUID generation	portions of the UUID generation, which prove useful for batch UUID
	which prove useful for batch UUID generation purposes and monotonic error checki	generation purposes and monotonic error checking with UUIDv6 and
	ng with UUIDv6 and UUIDv7.	UUIDv7. These stored values include but are not limited to last known
	These stored values include but are not limited to last known timestamp, clock s	timestamp, clock sequence, counters, and random data.</t>
	equence, counters, and random data.</t>
	<t>If an implementation does not have any stable store available, then	<t>If an implementation does not have any stable store available, then

	it <bcp14>MAY</bcp14> proceed with UUID generation as if this was the first UUID	it <bcp14>MAY</bcp14> proceed with UUID generation as if this were the
	created within a batch.	first UUID created within a batch. This is the least desirable
	This is the least desirable implementation because it will increase the frequenc	implementation because it will increase the frequency of creation of
	y	values such as clock sequence, counters, or random data, which
	of creation of values such as clock sequence, counters, or random data, which in	increases the probability of duplicates. Further, frequent generation
	creases the	of random numbers also puts more stress on any entropy source and/or
	probability of duplicates. Further, frequent generation of random numbers also p	entropy pool being used as the basis for such random numbers.</t>
	uts more stress on any entropy source and or entropy pool being used as the basi	<t>An implementation <bcp14>MAY</bcp14> also return an application
	s for such random numbers.</t>	error in the event that collision resistance is of the utmost concern.
	<t>An implementation <bcp14>MAY</bcp14> also return an application error	The semantics of this error are up to the application and
	in the event that collision resistance is of the utmost concern.	implementation. See <xref target="collision_resistance"/> for more
	The semantics of this error are up to the application and implementation.	information on weighting collision tolerance in applications.</t>
	See <xref target="collision_resistance"/> for more information on weighting coll	<t>For UUIDv1 and UUIDv6, if the Node ID can never change (e.g., the
	ision tolerance in applications.</t>	network interface card from which the Node ID is derived is
	<t>For UUIDv1 and UUIDv6, if the node ID can never change (e.g., the net	inseparable from the system), or if any change also re-initializes the
	work interface card	clock sequence to a random value, then instead of keeping it in stable
	from which the node ID is derived is inseparable	store, the current Node ID may be returned.</t>
	from the system), or if any change also re-initializes the clock	<t>For UUIDv1 and UUIDv6, the state does not always need to be written
	sequence to a random value, then instead of keeping it in stable	to stable store every time a UUID is generated. The timestamp in the
	store, the current node ID may be returned.</t>	stable store can periodically be set to a value larger than any yet
	<t>For UUIDv1 and UUIDv6, the state does not always need to be written t	used in a UUID. As long as the generated UUIDs have timestamps less
	o stable store every	than that value, and the clock sequence and Node ID remain unchanged,
	time a UUID is generated. The timestamp in the stable store can be	only the shared volatile copy of the state needs to be updated.
	periodically set to a value larger than any yet used in a UUID. As	Furthermore, if the timestamp value in stable store is in the future
	long as the generated UUIDs have timestamps less than that value, and	by less than the typical time it takes the system to reboot, a crash
	the clock sequence and node ID remain unchanged, only the shared	will not cause a re-initialization of the clock sequence.</t>
	volatile copy of the state needs to be updated. Furthermore, if the
	timestamp value in stable store is in the future by less than the
	typical time it takes the system to reboot, a crash will not cause a
	re-initialization of the clock sequence.</t>
	<t>If it is too expensive to access shared state each time a UUID is	<t>If it is too expensive to access shared state each time a UUID is

	generated, then the system-wide generator can be implemented to	generated, then the system-wide generator can be implemented to
	allocate a block of time stamps each time it is called; a per-	allocate a block of timestamps each time it is called; a per-process
	process generator can allocate from that block until it is exhausted.</t>	generator can allocate from that block until it is exhausted.</t>
	</section>	</section>
	<section anchor="distributed_shared_knowledge">	<section anchor="distributed_shared_knowledge">
	<name>Distributed UUID Generation</name>	<name>Distributed UUID Generation</name>

	<t>Some implementations <bcp14>MAY</bcp14> desire to utilize multi-node,	<t>Some implementations <bcp14>MAY</bcp14> desire the utilization of
	clustered, applications	multi-node, clustered, applications that involve two or more nodes
	which involve two or more	independently generating UUIDs that will be stored in a common
	nodes independently generating UUIDs that will be stored in a common location.	location. While UUIDs already feature sufficient entropy to ensure
	While UUIDs already feature sufficient entropy to ensure that the chances	that the chances of collision are low, as the total number of UUID
	of collision are low, as the total number of UUID generating nodes increase; so	generating nodes increases, so does the likelihood of a collision.</t>
	does the likelihood	<t>This section will detail the two additional collision resistance
	of a collision.</t>	approaches that have been observed by multi-node UUID implementations
	<t>This section will detail the two additional collision resistance appr	in distributed environments.</t>
	oaches that have been observed by multi-node	<t>It should be noted that, although this section details two methods
	UUID implementations in distributed environments.</t>	for the sake of completeness, implementations should utilize the
	<t>It should be noted that, although this section details two methods fo	pseudorandom Node ID option if additional collision resistance for
	r the sake of completeness,	distributed UUID generation is a requirement. Likewise, utilization
	implementations should utilize the pseudo-random Node ID option if additional co	of either method is not required for implementing UUID generation in
	llision resistance for distributed UUID generation is a requirement.	distributed environments.</t>
	Likewise, utilization of either method is not required for implementing UUID gen
	eration in distributed environments.</t>	<dl spacing="normal" newline="true">
	<dl newline="true">
	<dt>Node IDs:</dt>	<dt>Node IDs:</dt>

	<dd>	<dd>With this method, a pseudorandom Node ID value is placed within
	<t>With this method, a pseudo-random Node ID value is placed within	the UUID layout. This identifier helps ensure the bit space for a
	the UUID	given node is unique, resulting in UUIDs that do not conflict with
	layout.	any other UUID created by another node with a different node id.
	This identifier helps ensure the bit-space for a given node is unique, resulting	Implementations that choose to leverage an embedded node id
	in UUIDs that do not conflict with any other UUID created by another node	<bcp14>SHOULD</bcp14> utilize UUIDv8. The node id <bcp14>SHOULD
	with a different node id.	NOT</bcp14> be an IEEE 802 MAC address per <xref
	Implementations that choose to leverage an embedded node id <bcp14>SHOULD</bcp14	target="Security"/>. The location and bit length are left to
	> utilize	implementations and are outside the scope of this specification.
	UUIDv8.	Furthermore, the creation and negotiation of unique node ids among
	The node id <bcp14>SHOULD NOT</bcp14> be an IEEE 802 MAC address as per <xref ta	nodes is also out of scope for this specification.</dd>
	rget="Security"/>.
	The location and bit length are left to implementations and are outside the
	scope of this specification.
	Furthermore, the creation and negotiation of unique node ids among nodes
	is also out of scope for this specification.</t>
	</dd>
	<dt>Centralized Registry:</dt>	<dt>Centralized Registry:</dt>

	<dd>	<dd>With this method, all nodes tasked with creating UUIDs consult a
	<t>With this method all nodes tasked with creating UUIDs consult a c	central registry and confirm the generated value is unique. As
	entral registry	applications scale, the communication with the central registry
	and confirm the generated value is unique. As applications scale, the communicat	could become a bottleneck and impact UUID generation in a negative
	ion	way. Shared knowledge schemes with central/global registries are
	with the central registry could become a bottleneck and impact UUID generation	outside the scope of this specification and are <bcp14>NOT
	in a negative way. Shared knowledge schemes with central/global	RECOMMENDED</bcp14>.</dd>
	registries are outside the scope of this specification and is <bcp14>NOT RECOMME
	NDED</bcp14>.</t>
	</dd>
	</dl>	</dl>


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

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


	<ul spacing="normal">	<ul spacing="normal">

	<li>	<li>UUIDs generated at different times from the same name (using
	<t>UUIDs generated at different times from the same name (using the	the same canonical format) in the same namespace <bcp14>MUST</bcp14>
	same canonical format) in the	be equal.</li>
	same namespace <bcp14>MUST</bcp14> be equal.</t>	<li>UUIDs generated from two different names (same or differing
	</li>	canonical format) in the same namespace should be different (with
	<li>	very high probability).</li>
	<t>UUIDs generated from two different names (same or differing canon	<li>UUIDs generated from the same name (same or differing
	ical format) in the same namespace	canonical format) in two different namespaces should be different
	should be different (with very high probability).</t>	(with very high probability).</li>
	</li>	<li>If two UUIDs that were generated from names (using the same
	<li>	canonical format) are equal, then they were generated from the same
	<t>UUIDs generated from the same name (same or differing canonical f	name in the same namespace (with very high probability).</li>
	ormat) in two different namespaces
	should be different (with very high probability).</t>
	</li>
	<li>
	<t>If two UUIDs that were generated from names (using the same canon
	ical format) are equal, then they
	were generated from the same name in the same namespace (with very
	high probability).</t>
	</li>
	</ul>	</ul>

	<dl newline="true">
	<dt>A note on names:</dt>	<t>A note on names:</t>
	<dd>	<t indent="3">The concept of name (and namespace) should be broadly
	<t>The concept of name (and namespace) should be broadly construed a	construed and not limited to textual names. A canonical sequence of
	nd not limited to textual names. A canonical sequence of octets is one that conf	octets is one that conforms to the specification for that name
	orms to the specification for that name form's canonical representation. A name	form's canonical representation. A name can have many usual forms,
	can have many usual forms, only one of which can be canonical. An implementer of	only one of which can be canonical. An implementer of new namespaces
	new namespaces for UUIDs needs to reference the specification for the canonical	for UUIDs needs to reference the specification for the canonical
	form of names in that space, or define such a canonical for the namespace if it	form of names in that space or define such a canonical form for the
	does not exist.	namespace if it does not exist. For example, at the time of
	For example, at the time of this specification, <xref target="RFC8499"/> domain	writing, Domain Name System (DNS) <xref target="RFC9499"/> has three
	name system (DNS) has three conveyance formats: common (www.example.com), presen	conveyance formats: common (www.example.com), presentation
	tation (www.example.com.) and wire format (3www7example3com0).	(www.example.com.), and wire format (3www7example3com0). Looking at
	Looking at <xref target="X500"/> distinguished names (DNs), the previous version	<xref target="X500"/> Distinguished Names (DNs), <xref
	of this specification allowed either text based or binary distinguished encodin	target="RFC4122" format="default"/> allowed either text-based or
	g rules (DER) based names as inputs.	binary DER-based names as inputs. For Uniform Resource Locators
	For <xref target="RFC1738"/> uniform resource locators (URLs), one could provide	(URLs) <xref target="RFC1738"/>, one could provide a Fully Qualified
	a fully-qualified domain-name (FQDN) with or without the protocol identifier (w	Domain Name (FQDN) with or without the protocol identifier
	ww.example.com) or (https://www.example.com).	www.example.com or https://www.example.com. When it comes to Object
	When it comes to <xref target="X660"/> object identifiers (OIDs) one could choos	Identifiers (OIDs) <xref target="X660"/>, one could choose dot
	e dot-notation without the leading dot (2.999), choose to include the leading do	notation without the leading dot (2.999), choose to include the
	t (.2.999) or select one of the many formats from <xref target="X680"/> such as	leading dot (.2.999), or select one of the many formats from <xref
	OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/Example).	target="X680"/> such as OID Internationalized Resource Identifier
	While most users may default to the common format for DNS, FQDN format for a URL	(OID-IRI) (/Joint-ISO-ITU-T/Example). While most users may default
	, text format for X.500 and dot-notation without a leading dot for OID; name-bas	to the common format for DNS, FQDN format for a URL, text format for
	ed UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary input wh	X.500, and dot notation without a leading dot for OID, name-based
	ich will compute name-based UUIDs for any of the aforementioned example names an	UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary
	d others not defined here.	input that will compute name-based UUIDs for any of the
	Each name format within a namespace will output different UUIDs.	aforementioned example names and others not defined here. Each name
	As such, the mechanisms or conventions used for allocating names and ensuring th	format within a namespace will output different UUIDs. As such, the
	eir uniqueness within their namespaces are beyond the scope of this specificatio	mechanisms or conventions used for allocating names and ensuring
	n.</t>	their uniqueness within their namespaces are beyond the scope of
	</dd>	this specification.</t>
	</dl>
	</section>	</section>
	<section anchor="namespaces">	<section anchor="namespaces">
	<name>Namespace ID Usage and Allocation</name>	<name>Namespace ID Usage and Allocation</name>

	<t>This section and table, <xref target="namespaceIDs"/>, details the na
	mespace IDs for some potentially interesting namespaces such those for	<t>This section details the namespace
	<xref target="RFC8499"/> domain name system (DNS), <xref target="RFC1738"/> unif	IDs for some potentially interesting namespaces such as those for DNS
	orm resource locators (URLs), <xref target="X660"/> object identifiers (OIDs), a	<xref target="RFC9499"/>, URLs <xref target="RFC1738"/>, OIDs <xref
	nd <xref target="X500"/> distinguished names (DNs).</t>	target="X660"/>, and DNs <xref target="X500"/>.</t>
	<t>Further, this section also details allocation, IANA registration and
	other details pertinent to Namespace IDs.	<t>Further, this section also details allocation, IANA registration,
	IANA may use the table <xref target="namespaceIDs"/> as-is replacing "This Docum	and other details pertinent to Namespace IDs.</t>
	ent" replaced as required.</t>
	<table anchor="namespaceIDs">	<table anchor="namespaceIDs">
	<name>Namespace IDs</name>	<name>Namespace IDs</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Namespace</th>	<th align="left">Namespace</th>
	<th align="left">Namespace ID Value</th>	<th align="left">Namespace ID Value</th>
	<th align="left">Name Reference</th>	<th align="left">Name Reference</th>
	<th align="left">Namespace ID Reference</th>	<th align="left">Namespace ID Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">DNS</td>	<td align="left">DNS</td>
	<td align="left">6ba7b810-9dad-11d1-80b4-00c04fd430c8</td>	<td align="left">6ba7b810-9dad-11d1-80b4-00c04fd430c8</td>
	<td align="left">	<td align="left">

	<xref target="RFC8499"/></td>	<xref target="RFC9499"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">URL</td>	<td align="left">URL</td>
	<td align="left">6ba7b811-9dad-11d1-80b4-00c04fd430c8</td>	<td align="left">6ba7b811-9dad-11d1-80b4-00c04fd430c8</td>
	<td align="left">	<td align="left">
	<xref target="RFC1738"/></td>	<xref target="RFC1738"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">OID</td>	<td align="left">OID</td>
	<td align="left">6ba7b812-9dad-11d1-80b4-00c04fd430c8</td>	<td align="left">6ba7b812-9dad-11d1-80b4-00c04fd430c8</td>
	<td align="left">	<td align="left">
	<xref target="X660"/></td>	<xref target="X660"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">X500</td>	<td align="left">X500</td>
	<td align="left">6ba7b814-9dad-11d1-80b4-00c04fd430c8</td>	<td align="left">6ba7b814-9dad-11d1-80b4-00c04fd430c8</td>
	<td align="left">	<td align="left">
	<xref target="X500"/></td>	<xref target="X500"/></td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<t>Items may be added to this table using "Specification Required" polic
	y as per <xref target="RFC8126"/>.</t>	<t>Items may be added to this registry using the Specification Required
	<t>For designated experts, generally speaking, Namespace IDs are allocat	policy as per <xref target="RFC8126"/>.</t>
	ed as follows:</t>	<t>For designated experts, generally speaking, Namespace IDs are
	<ul spacing="compact">	allocated as follows:</t>
	<li>
	<t>The first namespace ID value, for DNS, was calculated from a time	<ul spacing="normal">
	-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8" used as a starting poin	<li>The first Namespace ID value, for DNS, was calculated from a
	t.</t>	time-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as
	</li>	a starting point.</li>
	<li>	<li>Subsequent Namespace ID values increment the
	<t>Subsequent namespace ID values increment the least-significant, r	least significant, rightmost bit of time_low "6ba7b810" while
	ight-most bit of time_low "6ba7b810" while freezing the rest of the UUID to "9da	freezing the rest of the UUID to "9dad-11d1-80b4-00c04fd430c8".</li>
	d-11d1-80b4-00c04fd430c8".</t>	<li>New Namespace ID values <bcp14>MUST</bcp14> use this same
	</li>	logic and <bcp14>MUST NOT</bcp14> use a previously used Namespace ID
	<li>	value.</li>
	<t>New namespace ID values <bcp14>MUST</bcp14> use this same logic a	<li>Thus, "6ba7b815" is the next available time_low for a new
	nd <bcp14>MUST NOT</bcp14> use a previously used Namespace ID value.</t>	Namespace ID value with the full ID being
	</li>	"6ba7b815-9dad-11d1-80b4-00c04fd430c8".</li>
	<li>
	<t>Thus, "6ba7b815" is the next available time_low for a new Namespa	<li>The upper bound for time_low in this special use, Namespace ID
	ce ID value with the full ID being "6ba7b815-9dad-11d1-80b4-00c04fd430c8".</t>	values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8",
	</li>	which should be sufficient space for future Namespace ID values.</li>
	<li>
	<t>The upper bound for time_low in this special use, namespace ID va
	lues, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8" which should be su
	fficient space for future namespace ID values.</t>
	</li>
	</ul>	</ul>

	<t>Note that the namespace ID value "6ba7b813-9dad-11d1-80b4-00c04fd430c
	8" and its usage is not defined by this document or by <xref target="RFC4122"/>,	<t>Note that the Namespace ID value
	as such it <bcp14>SHOULD NOT</bcp14> be used as a Namespace ID value.</t>	"6ba7b813-9dad-11d1-80b4-00c04fd430c8" and its usage are not defined by
	<t>New Namespace ID values <bcp14>MUST</bcp14> be documented as per <xre	this document or by <xref target="RFC4122"/>; thus, it <bcp14>SHOULD
	f target="IANA"/> if they are to be globally available and fully interoperable.	NOT</bcp14> be used as a Namespace ID value.</t>
	Implementations <bcp14>MAY</bcp14> continue to use vendor-specific, application-	<t>New Namespace ID values <bcp14>MUST</bcp14> be documented as per
	specific, and deployment-specific Namespace ID values but know that interoperabi	<xref target="IANA"/> if they are to be globally available and fully
	lity is not guaranteed.	interoperable. Implementations <bcp14>MAY</bcp14> continue to use
	These custom Namespace ID values <bcp14>MUST NOT</bcp14> use the logic above and	vendor-specific, application-specific, and deployment-specific
	instead are <bcp14>RECOMMENDED</bcp14> to generate a UUIDv4 or UUIDv7 Namespace	Namespace ID values; but know that interoperability is not guaranteed.
	ID value.	These custom Namespace ID values <bcp14>MUST NOT</bcp14> use the logic
	If collision probability (<xref target="collision_resistance"/>) and uniqueness	above; instead, generating a
	(<xref target="global_local_uniqueness"/>) of the final name-based UUID are not	UUIDv4 or UUIDv7 Namespace ID value is <bcp14>RECOMMENDED</bcp14>. If c
	a problem; an implementation <bcp14>MAY</bcp14> also leverage UUIDv8 instead to	ollision probability (<xref
	create a custom, application-specific Namespace ID value.</t>	target="collision_resistance"/>) and uniqueness (<xref
	<t>Implementations <bcp14>SHOULD</bcp14> provide the ability to input a	target="global_local_uniqueness"/>) of the final name-based UUID are
	custom namespace to account for newly registered IANA Namespace ID values outsid	not a problem, an implementation <bcp14>MAY</bcp14> also leverage
	e of those listed in this section or custom, application specific Namespace ID v	UUIDv8 instead to create a custom, application-specific Namespace ID
	alues.</t>	value.</t>
		<t>Implementations <bcp14>SHOULD</bcp14> provide the ability to input
		a custom namespace to account for newly registered IANA Namespace ID
		values outside of those listed in this section or custom,
		application-specific Namespace ID values.</t>
	</section>	</section>
	<section anchor="collision_resistance">	<section anchor="collision_resistance">
	<name>Collision Resistance</name>	<name>Collision Resistance</name>

	<t>Implementations should weigh the consequences of UUID collisions with	<t>Implementations should weigh the consequences of UUID collisions
	in their	within their application and when deciding between UUID versions that
	application and when deciding between UUID versions that use entropy (randomness	use entropy (randomness) versus the other components such as those in
	)	Sections <xref target="timestamp_considerations" format="counter"/>
	versus the other components such as those in <xref target="timestamp_considerati	and <xref target="monotonicity_counters" format="counter"/>. This is
	ons"/> and <xref target="monotonicity_counters"/>.	especially true for distributed node collision resistance as defined
	This is especially true for distributed node collision resistance as defined	by <xref target="distributed_shared_knowledge"/>.</t>
	by <xref target="distributed_shared_knowledge"/>.</t>	<t>There are two example scenarios below that help illustrate the
	<t>There are two example scenarios below which help illustrate the varyi	varying seriousness of a collision within an application.</t>
	ng seriousness
	of a collision within an application.</t>	<dl spacing="normal" newline="true">
	<dl newline="true">
	<dt>Low Impact:</dt>	<dt>Low Impact:</dt>

	<dd>	<dd>A UUID collision generated a duplicate log entry, which results
	<t>A UUID collision generated a duplicate log entry which results in	in incorrect statistics derived from the data. Implementations that
	incorrect	are not negatively affected by collisions may continue with the
	statistics derived from the data. Implementations that are not negatively	entropy and uniqueness provided by UUIDs defined in this document.
	affected by collisions may continue with the entropy and uniqueness provided
	by the traditional UUID format.</t>
	</dd>	</dd>
	<dt>High Impact:</dt>	<dt>High Impact:</dt>

	<dd>	<dd>A duplicate key causes an airplane to receive the wrong course,
	<t>A duplicate key causes an airplane to receive the wrong course wh	which puts people's lives at risk. In this scenario, there is no
	ich puts	margin for error. Collisions must be avoided: failure is
	people's lives at risk. In this scenario there is no margin for error. Collision	unacceptable. Applications dealing with this type of scenario must
	s	employ as much collision resistance as possible within the given
	must be avoided and failure is unacceptable. Applications dealing with this	application context.</dd>
	type of scenario must employ as much collision resistance as possible within
	the given application context.</t>
	</dd>
	</dl>	</dl>


	</section>	</section>
	<section anchor="global_local_uniqueness">	<section anchor="global_local_uniqueness">
	<name>Global and Local Uniqueness</name>	<name>Global and Local Uniqueness</name>

	<t>UUIDs created by this specification <bcp14>MAY</bcp14> be used to pro	<t>UUIDs created by this specification <bcp14>MAY</bcp14> be used to
	vide local uniqueness	provide local uniqueness guarantees. For example, ensuring UUIDs
	guarantees.	created within a local application context are unique within a
	For example, ensuring UUIDs created within a local application context are	database <bcp14>MAY</bcp14> be sufficient for some implementations
	unique within a database <bcp14>MAY</bcp14> be sufficient for some implementatio	where global uniqueness outside of the application context, in other
	ns where	applications, or around the world is not required.</t>
	global uniqueness outside of the application context, in other applications,	<t>Although true global uniqueness is impossible to guarantee without
	or around the world is not required.</t>	a shared knowledge scheme, a shared knowledge scheme is not required
	<t>Although true global uniqueness is impossible to guarantee without a	by a UUID to provide uniqueness for practical implementation purposes.
	shared	Implementations <bcp14>MAY</bcp14> use a shared knowledge
	knowledge scheme, a shared knowledge scheme is not required by UUID to provide	scheme, introduced in <xref target="distributed_shared_knowledge"/>,
	uniqueness for practical implementation purposes.	as they see fit to extend the uniqueness guaranteed by this
	Implementations <bcp14>MAY</bcp14> implement a shared knowledge scheme introduce	specification.</t>
	d in <xref target="distributed_shared_knowledge"/> as they see fit to extend the
	uniqueness guaranteed by this specification.</t>
	</section>	</section>
	<section anchor="unguessability">	<section anchor="unguessability">
	<name>Unguessability</name>	<name>Unguessability</name>

	<t>Implementations <bcp14>SHOULD</bcp14> utilize a cryptographically sec	<t>Implementations <bcp14>SHOULD</bcp14> utilize a cryptographically
	ure pseudo-random number	secure pseudorandom number generator (CSPRNG) to provide values that
	generator (CSPRNG) to provide values that are both difficult to predict ("ungues	are both difficult to predict ("unguessable") and have a low
	sable")	likelihood of collision ("unique"). The exception is when a suitable
	and have a low likelihood of collision ("unique"). The exception is when a	CSPRNG is unavailable in the execution environment. Take care to
	suitable CSPRNG is unavailable in the execution environment.	ensure the CSPRNG state is properly reseeded upon state changes, such
	Take care to ensure the CSPRNG state is properly reseeded upon	as process forks, to ensure proper CSPRNG operation. CSPRNG ensures
	state changes, such as process forks, to ensure proper CSPRNG operation.	the best of Sections <xref target="collision_resistance"
	CSPRNG ensures the best of <xref target="collision_resistance"/> and <xref targe	format="counter"/> and <xref target="Security" format="counter"/> are
	t="Security"/> are present in modern UUIDs.</t>	present in modern UUIDs.</t>
	<t>Further advice on generating cryptographic-quality random numbers can	<t>Further advice on generating cryptographic-quality random numbers
	be found in <xref target="RFC4086"/>, <xref target="RFC8937"/> and in <xref tar	can be found in <xref target="RFC4086"/>, <xref target="RFC8937"/>,
	get="RANDOM"/>.</t>	and <xref target="RANDOM"/>.</t>
	</section>	</section>
	<section anchor="unidentifiable">	<section anchor="unidentifiable">
	<name>UUIDs That Do Not Identify the Host</name>	<name>UUIDs That Do Not Identify the Host</name>

	<t>This section describes how to generate a UUIDv1 or UUIDv6 value if an	<t>This section describes how to generate a UUIDv1 or UUIDv6 value if
	IEEE	an IEEE 802 address is not available or its use is not desired.</t>
	802 address is not available, or its use is not desired.</t>	<t>Implementations <bcp14>MAY</bcp14> leverage MAC address
	<t>Implementations <bcp14>MAY</bcp14> leverage MAC address randomization	randomization techniques <xref target="IEEE802.11bh"
	techniques (IEEE 802.11bh) as an alternative to the pseudo-random logic provide	format="default"/> as an alternative to the pseudorandom logic
	d in this section.</t>	provided in this section.</t>
	<t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a 4	<t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a
	8 bit cryptographic-quality random	48-bit cryptographic-quality random number as per <xref
	number as per <xref target="unguessability"/> to use it as the node ID.	target="unguessability"/> to use as the Node ID. After generating the
	After generating the 48 bit fully randomized node value, implementations <bcp14>	48-bit fully randomized node value, implementations
	MUST</bcp14> set the least significant bit of the first octet of the node ID set	<bcp14>MUST</bcp14> set the least significant bit of the first octet
	to 1.	of the Node ID to 1. This bit is the unicast or multicast bit, which
	This bit is the unicast/multicast bit, which will never be set in IEEE 802	will never be set in IEEE 802 addresses obtained from network cards.
	addresses obtained from network cards. Hence, there can never be a	Hence, there can never be a conflict between UUIDs generated by
	conflict between UUIDs generated by machines with and without network	machines with and without network cards. An example of generating a
	cards.	randomized 48-bit node value and the subsequent bit modification is
	An example of generating a randomized 48 bit node value and the subsequent bit m	detailed in <xref target="test_vectors"/>. For more information about
	odification is detailed in the <xref target="test_vectors"/> appendix.	IEEE 802 address and the unicast or multicast or local/global bits,
	For more information about IEEE 802 address and the unicast/multicast or local/g	please review <xref target="RFC9542"/>.</t>
	lobal bits please review <xref target="RFC7042"/>.</t>
	<t>For compatibility with earlier specifications, note that this	<t>For compatibility with earlier specifications, note that this

	document uses the unicast/multicast bit, instead of the arguably more	document uses the unicast or multicast bit instead of the arguably more
	correct local/global bit because MAC addresses with the local/global bit set or	correct local/global bit because MAC addresses with the local/global
	not are both possible in a network.	bit set or not set are both possible in a network. This is not the case
	This is not the case with the unicast/multicast bit.	with the unicast or multicast bit. One node cannot have a MAC address
	One node cannot have a MAC address that multicasts to multiple nodes.</t>	that multicasts to multiple nodes.</t>
	<t>In addition, items such as the computer's name and the name of the	<t>In addition, items such as the computer's name and the name of the

	operating system, while not strictly speaking random, will help	operating system, while not strictly speaking random, will help
	differentiate the results from those obtained by other systems.</t>	differentiate the results from those obtained by other systems.</t>
	<t>The exact algorithm to generate a node ID using these data is system	<t>The exact algorithm to generate a Node ID using these data is
	specific, because both the data available and the functions to obtain	system specific because both the data available and the functions to
	them are often very system specific. A generic approach, however, is	obtain them are often very system specific. However, a generic approach
	to accumulate as many sources as possible into a buffer, use a	is to accumulate as many sources as possible into a buffer, use a
	message digest (such as SHA-256 or SHA-512 defined by <xref target="FIPS180-4"/>	message digest (such as SHA-256 or SHA-512 defined by <xref
	), take an arbitrary 6	target="FIPS180-4"/>), take an arbitrary 6 bytes from the hash value,
	bytes from the hash value, and set the multicast bit as described	and set the multicast bit as described above.</t>
	above.</t>
	</section>	</section>
	<section anchor="sorting">	<section anchor="sorting">
	<name>Sorting</name>	<name>Sorting</name>

	<t>UUIDv6 and UUIDv7 are designed so that implementations that require s	<t>UUIDv6 and UUIDv7 are designed so that implementations that require
	orting	sorting (e.g., database indexes) sort as opaque raw bytes without the
	(e.g., database indexes) sort as opaque raw bytes, without need for	need for parsing or introspection.</t>
	parsing or introspection.</t>	<t>Time-ordered monotonic UUIDs benefit from greater database-index
	<t>Time ordered monotonic UUIDs benefit from greater database index loca	locality because the new values are near each other in the index. As
	lity	a result, objects are more easily clustered together for better
	because the new values are near each other in the index.	performance. The real-world differences in this approach of index
	As a result objects are more easily clustered together for better performance.	locality versus random data inserts can be one order of magnitude or
	The real-world differences in this approach of index locality vs random data	more.</t>
	inserts can be one order of magnitude or more.</t>	<t>UUID formats created by this specification are intended to be
	<t>UUID formats created by this specification are intended to be lexicog	lexicographically sortable while in the textual representation.</t>
	raphically sortable	<t>UUIDs created by this specification are crafted with big-endian
	while in the textual representation.</t>	byte order (network byte order) in mind. If little-endian style is
	<t>UUIDs created by this specification are crafted with big-endian byte	required, UUIDv8 is available for custom UUID formats.</t>
	order
	(network byte order) in mind. If little-endian style is required, UUIDv8
	is available for custom UUID formats.</t>
	</section>	</section>
	<section anchor="opacity">	<section anchor="opacity">
	<name>Opacity</name>	<name>Opacity</name>

	<t>As general guidance, it is recommend to avoid parsing UUID values unn	<t>As general guidance, avoiding parsing UUID values
	ecessarily,	unnecessarily is recommended; instead, treat UUIDs as opaquely as possib
	and instead treating UUIDs as opaquely as possible. Although application-specif	le.
	ic	Although application-specific concerns could, of course, require some
	concerns could of course require some degree of introspection	degree of introspection (e.g., to examine Sections <xref
	(e.g., to examine the <xref target="variant_field"/>, <xref target="version_fiel	target="variant_field" format="counter"/> or <xref
	d"/> or perhaps the timestamp of a UUID),	target="version_field" format="counter"/> or perhaps the timestamp of
	the advice here is to avoid this or other parsing unless absolutely necessary.	a UUID), the advice here is to avoid this or other parsing unless
	Applications typically tend to be simpler, more interoperable, and perform bette	absolutely necessary. Applications typically tend to be simpler, be mor
	r,	e
	when this advice is followed.</t>	interoperable, and perform better when this advice is followed.</t>
	</section>	</section>
	<section anchor="database_considerations">	<section anchor="database_considerations">
	<name>DBMS and Database Considerations</name>	<name>DBMS and Database Considerations</name>

	<t>For many applications, such as databases, storing UUIDs as text is un	<t>For many applications, such as databases, storing UUIDs as text is
	necessarily	unnecessarily verbose, requiring 288 bits to represent 128-bit UUID
	verbose, requiring 288 bits to represent 128 bit UUID values.	values. Thus, where feasible, UUIDs <bcp14>SHOULD</bcp14> be stored
	Thus, where feasible, UUIDs <bcp14>SHOULD</bcp14> be stored within database appl	within database applications as the underlying 128-bit binary
	ications	value.</t>
	as the underlying 128 bit binary value.</t>	<t>For other systems, UUIDs <bcp14>MAY</bcp14> be stored in binary
	<t>For other systems, UUIDs <bcp14>MAY</bcp14> be stored in binary form	form or as text, as appropriate. The trade-offs to both approaches
	or as text, as appropriate.	are as follows:</t>
	The trade-offs to both approaches are:</t>
	<ul spacing="normal">	<ul spacing="normal">

	<li>	<li>Storing in binary form requires less space and may result in faste
	<t>Storing as binary requires less space and may result in faster da	r
	ta access.</t>	data access.</li>
	</li>	<li>Storing as text requires more space but may require less
	<li>	translation if the resulting text form is to be used after
	<t>Storing as text requires more space but may require less translat	retrieval, which may make it simpler to implement. </li>
	ion if the
	resulting text form is to be used after retrieval, which thus may make it simple
	r
	to implement.</t>
	</li>
	</ul>	</ul>

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

	<t>All references to <xref target="RFC4122"/> in the IANA registries shoul	<t>All references to <xref target="RFC4122"/> in IANA registries
	d be replaced with references to this document.	(outside of those created by this document) have been replaced with
	References to <xref target="RFC4122"/> document's Section 4.1.2 should be update	references to this document, including the IANA URN namespace
	d to refer to this document's <xref target="format"/>.</t>	registration <xref target="URNNamespaces"/> for UUID. References to
	<t>The IANA URN namespace registration <xref target="URNNamespaces"/> for	<xref target="RFC4122" sectionFormat="of" section="4.1.2"/> have been
	UUID filed in <xref target="RFC4122"/> should be updated to reference this docum	updated to refer to <xref target="format"/> of this document.</t>
	ent.</t>	<t>Finally, IANA should track UUID Subtypes and Special Case "Namespace
	<t>Finally IANA should track UUID Subtypes and Special Case "Namespace IDs	IDs Values" as specified in Sections <xref target="iana2"
	Values" as specified in <xref target="iana2"/> and <xref target="iana3"/>.</t>	format="counter"/> and <xref target="iana3" format="counter"/> at the
	<t>When evaluating requests, the designated expert(s) should consider comm	following location: <eref brackets="angle"
	unity feedback, how well-defined is the reference specification, and this specif	target="https://www.iana.org/assignments/uuid"/>.</t>
	ication's requirements.	<t>When evaluating requests, the designated expert should consider
	Vendor-specific, application-specific, and deployment-specific values are unable	community feedback, how well-defined the reference specification is, and
	to be registered.	this specification's requirements. Vendor-specific,
	Specification documents should be published in a stable, freely available manner	application-specific, and deployment-specific values are unable to be
	(ideally located with a URL) but need not be standards.	registered. Specification documents should be published in a stable,
	The designated experts will either approve or deny the registration request, and	freely available manner (ideally, located with a URL) but need not be
	communicate their decision to IANA. Denials should include an explanation and,	standards. The designated expert will either approve or deny the
	if applicable, suggestions as to how to make the request successful.</t>	registration request and communicate this decision to IANA. Denials
		should include an explanation and, if applicable, suggestions as to how
		to make the request successful.</t>
	<section anchor="iana2">	<section anchor="iana2">
	<name>IANA UUID Subtype Registry and Registration</name>	<name>IANA UUID Subtype Registry and Registration</name>

	<t>This specification defines the "UUID Subtype" registry for common, wi	<t>This specification defines the "UUID Subtypes" registry for common
	dely used UUID standards.</t>	widely used UUID standards.</t>
	<t><xref target="ianaSubtypes"/> should be used as-is for this registry
	with "This document" replaced as required.</t>
	<table anchor="ianaSubtypes">	<table anchor="ianaSubtypes">
	<name>IANA UUID Subtypes</name>	<name>IANA UUID Subtypes</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Name</th>	<th align="left">Name</th>
	<th align="left">ID</th>	<th align="left">ID</th>
	<th align="left">Subtype</th>	<th align="left">Subtype</th>
	<th align="left">Variant</th>	<th align="left">Variant</th>
	<th align="left">Reference</th>	<th align="left">Reference</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">Gregorian Time-based</td>	<td align="left">Gregorian Time-based</td>
	<td align="left">1</td>	<td align="left">1</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">DCE Security</td>	<td align="left">DCE Security</td>
	<td align="left">2</td>	<td align="left">2</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>
	<td align="left">	<td align="left">
	<xref target="C309"/>, <xref target="C311"/></td>	<xref target="C309"/>, <xref target="C311"/></td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">MD5 Name-based</td>	<td align="left">MD5 Name-based</td>
	<td align="left">3</td>	<td align="left">3</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">Random</td>	<td align="left">Random</td>
	<td align="left">4</td>	<td align="left">4</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">SHA-1 Name-based</td>	<td align="left">SHA-1 Name-based</td>
	<td align="left">5</td>	<td align="left">5</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>
	<td align="left">	<td align="left">

	<xref target="RFC4122"/>, This document</td>	<xref target="RFC4122"/>, RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">Reordered Gregorian Time-based</td>	<td align="left">Reordered Gregorian Time-based</td>
	<td align="left">6</td>	<td align="left">6</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>

	<td align="left">This document</td>	<td align="left">RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">Unix Time-based</td>	<td align="left">Unix Time-based</td>
	<td align="left">7</td>	<td align="left">7</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>

	<td align="left">This document</td>	<td align="left">RFC 9562</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">Custom</td>	<td align="left">Custom</td>
	<td align="left">8</td>	<td align="left">8</td>
	<td align="left">version</td>	<td align="left">version</td>
	<td align="left">OSF DCE / IETF</td>	<td align="left">OSF DCE / IETF</td>

	<td align="left">This document</td>	<td align="left">RFC 9562</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

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

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


	</section>	</section>
	<section anchor="iana3">	<section anchor="iana3">
	<name>IANA UUID Namespace ID Registry and Registration</name>	<name>IANA UUID Namespace ID Registry and Registration</name>

	<t>This specification defines the "UUID Namespace ID" registry for commo n, widely used Namespace ID values.</t>	<t>This specification defines the "UUID Namespace IDs" registry for comm on, widely used Namespace ID values.</t>
	<t>The full details of this registration, including information for desi gnated experts, can be found in <xref target="namespaces"/>.</t>	<t>The full details of this registration, including information for desi gnated experts, can be found in <xref target="namespaces"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="Security">	<section anchor="Security">
	<name>Security Considerations</name>	<name>Security Considerations</name>

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


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


	<reference anchor="C309" target="https://pubs.opengroup.org/onlinepubs/9 696999099/toc.pdf">	<reference anchor="C309" target="https://pubs.opengroup.org/onlinepubs/9 696999099/toc.pdf">
	<front>	<front>

	<title>DCE: Remote Procedure Call</title>	<title>X/Open DCE: Remote Procedure Call</title>
	<author>	<author>

	<organization/>	<organization>X/Open Company Limited</organization>
	</author>	</author>
	<date year="1994" month="August"/>	<date year="1994" month="August"/>
	</front>	</front>
	<seriesInfo name="ISBN" value="1-85912-041-5"/>	<seriesInfo name="ISBN" value="1-85912-041-5"/>

	<refcontent>Open Group CAE Specification C309</refcontent>	<seriesInfo name="Open CAE Specification" value="C309"/>
	</reference>	</reference>


	<reference anchor="X667">	<reference anchor="X667">
	<front>	<front>

	<title>Information Technology, "Procedures for the operation of OSI	<title>Information technology - Open Systems Interconnection -
	Registration Authorities: Generation and registration of Universally Unique Iden	Procedures for the operation of OSI Registration Authorities:
	tifiers (UUIDs) and their use as ASN.1 Object Identifier components"</title>	Generation and registration of Universally Unique Identifiers
		(UUIDs) and their use as ASN.1 object identifier
		components</title>
	<author>	<author>

	<organization/>	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2004"/>	<date month="September" year="2004"/>
	</front>	</front>
	<seriesInfo name="ISO/IEC" value="9834-8:2004"/>	<seriesInfo name="ISO/IEC" value="9834-8:2004"/>

	<seriesInfo name="ITU-T Rec." value="X.667"/>	<seriesInfo name="ITU-T Recommendation" value="X.667"/>
	</reference>
	<reference anchor="RFC8141">
	<front>
	<title>Uniform Resource Names (URNs)</title>
	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
	"/>
	<author fullname="J. Klensin" initials="J." surname="Klensin"/>
	<date month="April" year="2017"/>
	<abstract>
	<t>A Uniform Resource Name (URN) is a Uniform Resource Identifier
	(URI) that is assigned under the "urn" URI scheme and a particular URN namespace
	, with the intent that the URN will be a persistent, location-independent resour
	ce identifier. With regard to URN syntax, this document defines the canonical sy
	ntax for URNs (in a way that is consistent with URI syntax), specifies methods f
	or determining URN-equivalence, and discusses URI conformance. With regard to UR
	N namespaces, this document specifies a method for defining a URN namespace and
	associating it with a namespace identifier, and it describes procedures for regi
	stering namespace identifiers with the Internet Assigned Numbers Authority (IANA
	). This document obsoletes both RFCs 2141 and 3406.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8141"/>
	<seriesInfo name="DOI" value="10.17487/RFC8141"/>
	</reference>	</reference>


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

	<reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.180-4.pdf">	<reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/ FIPS/NIST.FIPS.180-4.pdf">
	<front>	<front>

	<title>Secure Hash Standard</title>	<title>Secure Hash Standard (SHS)</title>
	<author>	<author>

	<organization>National Institute of Standards and Technology</orga	<organization>National Institute of Standards and Technology
	nization>	(NIST)</organization>
	</author>	</author>
	<date year="2015" month="August"/>	<date year="2015" month="August"/>
	</front>	</front>

	<seriesInfo name="FIPS" value="PUB 180-4"/>	<seriesInfo name="FIPS PUB" value="180-4"/>
		<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
	</reference>	</reference>


	<reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf">	<reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf">
	<front>	<front>
	<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>	<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
	<author>	<author>

	<organization>National Institute of Standards and Technology</orga	<organization>National Institute of Standards and Technology
	nization>	(NIST)</organization>
	</author>	</author>
	<date year="2015" month="August"/>	<date year="2015" month="August"/>
	</front>	</front>

	<seriesInfo name="FIPS" value="PUB 202"/>	<seriesInfo name="FIPS PUB" value="202"/>
		<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
	</reference>	</reference>


	<reference anchor="C311" target="https://pubs.opengroup.org/onlinepubs/9 696989899/toc.pdf">	<reference anchor="C311" target="https://pubs.opengroup.org/onlinepubs/9 696989899/toc.pdf">
	<front>	<front>
	<title>DCE 1.1: Authentication and Security Services</title>	<title>DCE 1.1: Authentication and Security Services</title>
	<author>	<author>

	<organization/>	<organization>The Open Group</organization>
	</author>	</author>

	<date year="1997"/>	<date year="1997" month="August"/>
	</front>
	<refcontent>Open Group CAE Specification C311</refcontent>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l 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>	</front>

	<seriesInfo name="BCP" value="14"/>	<seriesInfo name="Open Group CAE Specification" value="C311"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>	</reference>


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

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

	<reference anchor="RFC1321">
	<front>	<reference anchor="IEEE802.11bh" target="https://standards.ieee.org/ieee/802.11b
	<title>The MD5 Message-Digest Algorithm</title>	h/10525/">
	<author fullname="R. Rivest" initials="R." surname="Rivest"/>	<front>
	<date month="April" year="1992"/>	<title>IEEE Draft Standard for Information technology--Telecommunications an
	<abstract>	d information exchange between systems Local and metropolitan area networks--Spe
	<t>This document describes the MD5 message-digest algorithm. The a	cific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physi
	lgorithm takes as input a message of arbitrary length and produces as output a 1	cal Layer (PHY) Specifications Amendment: Enhancements for Extremely High Throug
	28-bit "fingerprint" or "message digest" of the input. This memo provides inform	hput (EHT)</title>
	ation for the Internet community. It does not specify an Internet standard.</t>	<author>
	</abstract>	<organization>IEEE</organization>
	</front>	</author>
	<seriesInfo name="RFC" value="1321"/>	<date year="2023" month="March"/>
	<seriesInfo name="DOI" value="10.17487/RFC1321"/>	</front>
	</reference>	<seriesInfo name="Electronic ISBN" value="978-1-5044-9520-2"/>
	<reference anchor="RFC1738">	</reference>
	<front>
	<title>Uniform Resource Locators (URL)</title>	<reference anchor="Err1957" quote-title="false" target="https://www.rfc-editor.o
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee	rg/errata/eid1957">
	"/>	<front>
	<author fullname="L. Masinter" initials="L." surname="Masinter"/>	<title>Erratum ID 1957</title>
	<author fullname="M. McCahill" initials="M." surname="McCahill"/>	<author>
	<date month="December" year="1994"/>	<organization>RFC Errata</organization>
	<abstract>	</author>
	<t>This document specifies a Uniform Resource Locator (URL), the s	</front>
	yntax and semantics of formalized information for location and access of resourc	<refcontent>RFC 4122</refcontent>
	es via the Internet. [STANDARDS-TRACK]</t>	</reference>
	</abstract>
	</front>	<reference anchor="Err3546" quote-title="false" target="https://www.rfc-editor.o
	<seriesInfo name="RFC" value="1738"/>	rg/errata/eid3546">
	<seriesInfo name="DOI" value="10.17487/RFC1738"/>	<front>
	</reference>	<title>Erratum ID 3546</title>
	<reference anchor="RFC4086">	<author>
	<front>	<organization>RFC Errata</organization>
	<title>Randomness Requirements for Security</title>	</author>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3	</front>
	rd"/>	<refcontent>RFC 4122</refcontent>
	<author fullname="J. Schiller" initials="J." surname="Schiller"/>	</reference>
	<author fullname="S. Crocker" initials="S." surname="Crocker"/>
	<date month="June" year="2005"/>	<reference anchor="Err4976" quote-title="false" target="https://www.rfc-editor.o
	<abstract>	rg/errata/eid4976">
	<t>Security systems are built on strong cryptographic algorithms t	<front>
	hat foil pattern analysis attempts. However, the security of these systems is de	<title>Erratum ID 4976</title>
	pendent on generating secret quantities for passwords, cryptographic keys, and s	<author>
	imilar quantities. The use of pseudo-random processes to generate secret quantit	<organization>RFC Errata</organization>
	ies can result in pseudo-security. A sophisticated attacker may find it easier t	</author>
	o reproduce the environment that produced the secret quantities and to search th	</front>
	e resulting small set of possibilities than to locate the quantities in the whol	<refcontent>RFC 4122</refcontent>
	e of the potential number space.</t>	</reference>
	<t>Choosing random quantities to foil a resourceful and motivated
	adversary is surprisingly difficult. This document points out many pitfalls in u	<reference anchor="Err4975" quote-title="false"
	sing poor entropy sources or traditional pseudo-random number generation techniq	target="https://www.rfc-editor.org/errata/eid4975">
	ues for generating such quantities. It recommends the use of truly random hardwa	<front>
	re techniques and shows that the existing hardware on many systems can be used f	<title>Erratum ID 4975</title>
	or this purpose. It provides suggestions to ameliorate the problem when a hardwa	<author>
	re solution is not available, and it gives examples of how large such quantities	<organization>RFC Errata</organization>
	need to be for some applications. This document specifies an Internet Best Curr	</author>
	ent Practices for the Internet Community, and requests discussion and suggestion	</front>
	s for improvements.</t>	<refcontent>RFC 4122</refcontent>
	</abstract>	</reference>
	</front>
	<seriesInfo name="BCP" value="106"/>	<reference anchor="Err5560" quote-title="false"
	<seriesInfo name="RFC" value="4086"/>	target="https://www.rfc-editor.org/errata/eid5560">
	<seriesInfo name="DOI" value="10.17487/RFC4086"/>	<front>
	</reference>	<title>Erratum ID 5560</title>
	<reference anchor="RFC4122">	<author>
	<front>	<organization>RFC Errata</organization>
	<title>A Universally Unique IDentifier (UUID) URN Namespace</title>	</author>
	<author fullname="P. Leach" initials="P." surname="Leach"/>	</front>
	<author fullname="M. Mealling" initials="M." surname="Mealling"/>	<refcontent>RFC 4122</refcontent>
	<author fullname="R. Salz" initials="R." surname="Salz"/>	</reference>
	<date month="July" year="2005"/>
	<abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"
	<t>This specification defines a Uniform Resource Name namespace fo	/>
	r UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique ID	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml"
	entifier). A UUID is 128 bits long, and can guarantee uniqueness across space an	/>
	d time. UUIDs were originally used in the Apollo Network Computing System and la	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"
	ter in the Open Software Foundation\'s (OSF) Distributed Computing Environment (	/>
	DCE), and then in Microsoft Windows platforms.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"
	<t>This specification is derived from the DCE specification with t	/>
	he kind permission of the OSF (now known as The Open Group). Information from ea	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	rlier versions of the DCE specification have been incorporated into this documen	/>
	t. [STANDARDS-TRACK]</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"
	</abstract>	/>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"
	<seriesInfo name="RFC" value="4122"/>	/>
	<seriesInfo name="DOI" value="10.17487/RFC4122"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.xml"
	</reference>	/>
	<reference anchor="RFC5234">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
	<front>	/>
	<title>Augmented BNF for Syntax Specifications: ABNF</title>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"
	<author fullname="D. Crocker" initials="D." role="editor" surname="C	/>
	rocker"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8937.xml"
	<author fullname="P. Overell" initials="P." surname="Overell"/>	/>
	<date month="January" year="2008"/>
	<abstract>
	<t>Internet technical specifications often need to define a formal
	syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au
	gmented BNF (ABNF), has been popular among many Internet specifications. The cur
	rent specification documents ABNF. It balances compactness and simplicity with r
	easonable representational power. The differences between standard BNF and ABNF
	involve naming rules, repetition, alternatives, order-independence, and value ra
	nges. This specification also supplies additional rule definitions and encoding
	for a core lexical analyzer of the type common to several Internet specification
	s. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="68"/>
	<seriesInfo name="RFC" value="5234"/>
	<seriesInfo name="DOI" value="10.17487/RFC5234"/>
	</reference>
	<reference anchor="RFC6151">
	<front>
	<title>Updated Security Considerations for the MD5 Message-Digest an
	d the HMAC-MD5 Algorithms</title>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<author fullname="L. Chen" initials="L." surname="Chen"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document updates the security considerations for the MD5 m
	essage digest algorithm. It also updates the security considerations for HMAC-MD
	5. This document is not an Internet Standards Track specification; it is publish
	ed for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6151"/>
	<seriesInfo name="DOI" value="10.17487/RFC6151"/>
	</reference>
	<reference anchor="RFC6194">
	<front>
	<title>Security Considerations for the SHA-0 and SHA-1 Message-Diges
	t Algorithms</title>
	<author fullname="T. Polk" initials="T." surname="Polk"/>
	<author fullname="L. Chen" initials="L." surname="Chen"/>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<date month="March" year="2011"/>
	<abstract>
	<t>This document includes security considerations for the SHA-0 an
	d SHA-1 message digest algorithm. This document is not an Internet Standards Tra
	ck specification; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6194"/>
	<seriesInfo name="DOI" value="10.17487/RFC6194"/>
	</reference>
	<reference anchor="RFC7042">
	<front>
	<title>IANA Considerations and IETF Protocol and Documentation Usage
	for IEEE 802 Parameters</title>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
	rd"/>
	<author fullname="J. Abley" initials="J." surname="Abley"/>
	<date month="October" year="2013"/>
	<abstract>
	<t>Some IETF protocols make use of Ethernet frame formats and IEEE
	802 parameters. This document discusses several uses of such parameters in IETF
	protocols, specifies IANA considerations for assignment of points under the IAN
	A OUI (Organizationally Unique Identifier), and provides some values for use in
	documentation. This document obsoletes RFC 5342.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="141"/>
	<seriesInfo name="RFC" value="7042"/>
	<seriesInfo name="DOI" value="10.17487/RFC7042"/>
	</reference>
	<reference anchor="RFC8126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton"/>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<author fullname="T. Narten" initials="T." surname="Narten"/>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in the
	se fields do not have conflicting uses and to promote interoperability, their al
	locations are often coordinated by a central record keeper. For IETF protocols,
	that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	<t>To make assignments in a given registry prudently, guidance des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This document
	defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Consideratio
	ns is clear and addresses the various issues that are likely in the operation of
	a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="26"/>
	<seriesInfo name="RFC" value="8126"/>
	<seriesInfo name="DOI" value="10.17487/RFC8126"/>
	</reference>
	<reference anchor="RFC8499">
	<front>
	<title>DNS Terminology</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
	<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
	<date month="January" year="2019"/>
	<abstract>
	<t>The Domain Name System (DNS) is defined in literally dozens of
	different RFCs. The terminology used by implementers and developers of DNS proto
	cols, and by operators of DNS systems, has sometimes changed in the decades sinc
	e the DNS was first defined. This document gives current definitions for many of
	the terms used in the DNS in a single document.</t>
	<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="219"/>
	<seriesInfo name="RFC" value="8499"/>
	<seriesInfo name="DOI" value="10.17487/RFC8499"/>
	</reference>
	<reference anchor="RFC8937">
	<front>
	<title>Randomness Improvements for Security Protocols</title>
	<author fullname="C. Cremers" initials="C." surname="Cremers"/>
	<author fullname="L. Garratt" initials="L." surname="Garratt"/>
	<author fullname="S. Smyshlyaev" initials="S." surname="Smyshlyaev"/
	>
	<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
	<author fullname="C. Wood" initials="C." surname="Wood"/>
	<date month="October" year="2020"/>
	<abstract>
	<t>Randomness is a crucial ingredient for Transport Layer Security
	(TLS) and related security protocols. Weak or predictable "cryptographically se
	cure" pseudorandom number generators (CSPRNGs) can be abused or exploited for ma
	licious purposes. An initial entropy source that seeds a CSPRNG might be weak or
	broken as well, which can also lead to critical and systemic security problems.
	This document describes a way for security protocol implementations to augment
	their CSPRNGs using long-term private keys. This improves randomness from broken
	or otherwise subverted CSPRNGs.</t>
	<t>This document is a product of the Crypto Forum Research Group (
	CFRG) in the IRTF.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8937"/>
	<seriesInfo name="DOI" value="10.17487/RFC8937"/>
	</reference>
	<reference anchor="X500">	<reference anchor="X500">
	<front>	<front>

	<title>Information technology – Open Systems Interconnection – The D	<title>Information technology - Open Systems Interconnection - The
	irectory: Overview of concepts, models and services</title>	Directory: Overview of concepts, models and services</title>
	<author>	<author>

	<organization/>	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2019"/>	<date year="2019" month="October"/>
	</front>	</front>
	<seriesInfo name="ISO/IEC" value="9594-1"/>	<seriesInfo name="ISO/IEC" value="9594-1"/>

	<seriesInfo name="ITU-T Rec." value="X.500"/>	<seriesInfo name="ITU-T Recommendation" value="X.500"/>
	</reference>	</reference>


	<reference anchor="X660">	<reference anchor="X660">
	<front>	<front>

	<title>Information technology – Procedures for the operation of obje	<title>Information technology - Procedures for the operation of
	ct identifier registration authorities: General procedures and top arcs of the i	object identifier registration authorities: General procedures and
	nternational object identifier tree</title>	top arcs of the international object identifier tree</title>
	<author>	<author>

	<organization/>	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2011"/>	<date month="July" year="2011"/>
	</front>	</front>
	<seriesInfo name="ISO/IEC" value="9834-1"/>	<seriesInfo name="ISO/IEC" value="9834-1"/>

	<seriesInfo name="ITU-T Rec." value="X.660"/>	<seriesInfo name="ITU-T Recommendation" value="X.660"/>
	</reference>	</reference>


	<reference anchor="X680">	<reference anchor="X680">
	<front>	<front>

	<title>Information Technology - Abstract Syntax Notation One (ASN.1)	<title>Information Technology - Abstract Syntax Notation One
	& ASN.1 encoding rules</title>	(ASN.1) & ASN.1 encoding rules</title>
	<author>	<author>

	<organization/>	<organization>ITU-T</organization>
	</author>	</author>

	<date year="2021"/>	<date month="February" year="2021"/>
	</front>	</front>
	<seriesInfo name="ISO/IEC" value="8824-1:2021"/>	<seriesInfo name="ISO/IEC" value="8824-1:2021"/>

	<seriesInfo name="ITU-T Rec." value="X.680"/>	<seriesInfo name="ITU-T Recommendation" value="X.680"/>
	</reference>	</reference>


	<reference anchor="LexicalUUID" target="https://github.com/twitter-archi ve/cassie">	<reference anchor="LexicalUUID" target="https://github.com/twitter-archi ve/cassie">
	<front>	<front>

	<title>A Scala client for Cassandra</title>	<title>Cassie</title>
	<author>	<author>
	<organization>Twitter</organization>	<organization>Twitter</organization>
	</author>	</author>
	<date year="2012" month="November"/>	<date year="2012" month="November"/>
	</front>	</front>

	<seriesInfo name="commit" value="f6da4e0"/>	<refcontent>commit f6da4e0</refcontent>
	</reference>	</reference>

	<reference anchor="Snowflake" target="https://github.com/twitter-archive
	/snowflake/releases/tag/snowflake-2010">	<reference anchor="Snowflake" target="https://github.com/twitter-archive
		/snowflake">
	<front>	<front>

	<title>Snowflake is a network service for generating unique ID numbe	<title>Snowflake is a network service for generating unique ID
	rs at high scale with some simple guarantees.</title>	numbers at high scale with some simple guarantees.</title>
	<author>	<author>
	<organization>Twitter</organization>	<organization>Twitter</organization>
	</author>	</author>
	<date year="2014" month="May"/>	<date year="2014" month="May"/>
	</front>	</front>

	<seriesInfo name="Commit" value="b3f6a3c"/>	<refcontent>commit ec40836</refcontent>
	</reference>	</reference>


	<reference anchor="Flake" target="https://github.com/boundary/flake">	<reference anchor="Flake" target="https://github.com/boundary/flake">
	<front>	<front>
	<title>Flake: A decentralized, k-ordered id generation service in Er lang</title>	<title>Flake: A decentralized, k-ordered id generation service in Er lang</title>
	<author>	<author>
	<organization>Boundary</organization>	<organization>Boundary</organization>
	</author>	</author>
	<date year="2017" month="February"/>	<date year="2017" month="February"/>
	</front>	</front>

	<seriesInfo name="Commit" value="15c933a"/>	<refcontent>commit 15c933a</refcontent>
	</reference>	</reference>


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


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

	<seriesInfo name="Commit" value="bf376a7"/>	<refcontent>commit bf376a7</refcontent>
	</reference>	</reference>


	<reference anchor="Elasticflake" target="https://github.com/ppearcy/elas ticflake">	<reference anchor="Elasticflake" target="https://github.com/ppearcy/elas ticflake">
	<front>	<front>
	<title>Sequential UUID / Flake ID generator pulled out of elasticsea rch common</title>	<title>Sequential UUID / Flake ID generator pulled out of elasticsea rch common</title>
	<author initials="P." surname="Pearcy" fullname="Paul Pearcy">	<author initials="P." surname="Pearcy" fullname="Paul Pearcy">
	<organization/>	<organization/>
	</author>	</author>
	<date year="2015" month="January"/>	<date year="2015" month="January"/>
	</front>	</front>

	<seriesInfo name="Commit" value="dd71c21"/>	<refcontent>commit dd71c21</refcontent>
	</reference>	</reference>


	<reference anchor="FlakeID" target="https://github.com/T-PWK/flake-idgen ">	<reference anchor="FlakeID" target="https://github.com/T-PWK/flake-idgen ">
	<front>	<front>
	<title>Flake ID Generator</title>	<title>Flake ID Generator</title>

	<author initials="T." surname="Pawlak" fullname="Tom Pawlak">	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2020" month="April"/>	<date year="2020" month="April"/>
	</front>	</front>

	<seriesInfo name="Commit" value="fcd6a2f"/>	<refcontent>commit fcd6a2f</refcontent>
	</reference>	</reference>


	<reference anchor="Sonyflake" target="https://github.com/sony/sonyflake" >	<reference anchor="Sonyflake" target="https://github.com/sony/sonyflake" >
	<front>	<front>
	<title>A distributed unique ID generator inspired by Twitter's Snowf lake</title>	<title>A distributed unique ID generator inspired by Twitter's Snowf lake</title>
	<author>	<author>
	<organization>Sony</organization>	<organization>Sony</organization>
	</author>	</author>
	<date year="2020" month="August"/>	<date year="2020" month="August"/>
	</front>	</front>

	<seriesInfo name="Commit" value="848d664"/>	<refcontent>commit 848d664</refcontent>
	</reference>	</reference>


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


	<reference anchor="COMBGUID" target="https://github.com/richardtallent/R T.Comb">	<reference anchor="COMBGUID" target="https://github.com/richardtallent/R T.Comb">
	<front>	<front>
	<title>Creating sequential GUIDs in C# for MSSQL or PostgreSql</titl e>	<title>Creating sequential GUIDs in C# for MSSQL or PostgreSql</titl e>

	<author initials="R." surname="Tallent" fullname="Richard Tallent">	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2020" month="December"/>	<date year="2020" month="December"/>
	</front>	</front>

	<seriesInfo name="Commit" value="2759820"/>	<refcontent>commit 2759820</refcontent>
	</reference>	</reference>


	<reference anchor="ULID" target="https://github.com/ulid/spec">	<reference anchor="ULID" target="https://github.com/ulid/spec">
	<front>	<front>
	<title>Universally Unique Lexicographically Sortable Identifier</tit le>	<title>Universally Unique Lexicographically Sortable Identifier</tit le>

	<author initials="A." surname="Feerasta" fullname="Alizain Feerasta" >	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2019" month="May"/>	<date year="2019" month="May"/>
	</front>	</front>
	<seriesInfo name="Commit" value="d0c7170"/>	<seriesInfo name="Commit" value="d0c7170"/>
	</reference>	</reference>


	<reference anchor="SID" target="https://github.com/chilts/sid">	<reference anchor="SID" target="https://github.com/chilts/sid">
	<front>	<front>
	<title>sid : generate sortable identifiers</title>	<title>sid : generate sortable identifiers</title>

	<author initials="A." surname="Chilton" fullname="Andrew Chilton">	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2019" month="June"/>	<date year="2019" month="June"/>
	</front>	</front>
	<seriesInfo name="Commit" value="660e947"/>	<seriesInfo name="Commit" value="660e947"/>
	</reference>	</reference>


	<reference anchor="pushID" target="https://firebase.googleblog.com/2015/ 02/the-2120-ways-to-ensure-unique_68.html">	<reference anchor="pushID" target="https://firebase.googleblog.com/2015/ 02/the-2120-ways-to-ensure-unique_68.html">
	<front>	<front>
	<title>The 2^120 Ways to Ensure Unique Identifiers</title>	<title>The 2^120 Ways to Ensure Unique Identifiers</title>

	<author>	<author fullname="Michael Lehenbauer" surname="Lehenbauer" initials= "M.">
	<organization>Google</organization>	<organization>Google</organization>
	</author>	</author>
	<date year="2015" month="February"/>	<date year="2015" month="February"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="XID" target="https://github.com/rs/xid">	<reference anchor="XID" target="https://github.com/rs/xid">
	<front>	<front>
	<title>Globally Unique ID Generator</title>	<title>Globally Unique ID Generator</title>

	<author initials="O." surname="Poitrey" fullname="Olivier Poitrey">	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2020" month="October"/>	<date year="2020" month="October"/>
	</front>	</front>

	<seriesInfo name="Commit" value="efa678f"/>	<refcontent>commit efa678f</refcontent>
	</reference>	</reference>


	<reference anchor="ObjectID" target="https://docs.mongodb.com/manual/ref erence/method/ObjectId/">	<reference anchor="ObjectID" target="https://docs.mongodb.com/manual/ref erence/method/ObjectId/">
	<front>	<front>

	<title>ObjectId - MongoDB Manual</title>	<title>ObjectId</title>
	<author>	<author>
	<organization>MongoDB</organization>	<organization>MongoDB</organization>
	</author>	</author>
	<date/>	<date/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="CUID" target="https://github.com/ericelliott/cuid">	<reference anchor="CUID" target="https://github.com/ericelliott/cuid">
	<front>	<front>
	<title>Collision-resistant ids optimized for horizontal scaling and performance.</title>	<title>Collision-resistant ids optimized for horizontal scaling and performance.</title>

	<author initials="E." surname="Elliott" fullname="Eric Elliott">	<author>
	<organization/>	<organization/>
	</author>	</author>
	<date year="2020" month="October"/>	<date year="2020" month="October"/>
	</front>	</front>

	<seriesInfo name="Commit" value="215b27b"/>	<refcontent>commit 215b27b</refcontent>
	</reference>	</reference>


	<reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/ 6210/">	<reference anchor="IEEE754" target="https://standards.ieee.org/ieee/754/ 6210/">
	<front>	<front>
	<title>IEEE Standard for Floating-Point Arithmetic.</title>	<title>IEEE Standard for Floating-Point Arithmetic.</title>
	<author>	<author>
	<organization>IEEE</organization>	<organization>IEEE</organization>
	</author>	</author>
	<date year="2019" month="July"/>	<date year="2019" month="July"/>
	</front>	</front>

	<seriesInfo name="Series" value="754-2019"/>	<seriesInfo name="IEEE Std" value="754-2019"/>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
	</reference>	</reference>

	<reference anchor="URNNamespaces" target="https://www.iana.org/assignmen
	ts/urn-namespaces/urn-namespaces.xhtml">	<reference anchor="URNNamespaces" target="https://www.iana.org/assignmen
		ts/urn-namespaces/">
	<front>	<front>
	<title>Uniform Resource Names (URN) Namespaces</title>	<title>Uniform Resource Names (URN) Namespaces</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>

	<date year="2022" month="November" day="18"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="Python" target="https://docs.python.org/3/library/uui d.html">	<reference anchor="Python" target="https://docs.python.org/3/library/uui d.html">
	<front>	<front>

	<title>UUID objects according to RFC</title>	<title>uuid - UUID objects according to RFC 4122</title>
	<author>	<author>
	<organization>Python</organization>	<organization>Python</organization>
	</author>	</author>

	<date year="2023" month="May" day="23"/>
	</front>	</front>
	</reference>	</reference>

	<reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/
	openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-a93b-2f5c833d7d92">	<reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/
		openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d">
	<front>	<front>

	<title>curly braced GUID string</title>	<title>2.3.4.3 GUID - Curly Braced String Representation</title>
	<author>	<author>
	<organization>Microsoft</organization>	<organization>Microsoft</organization>
	</author>	</author>

	<date year="2023" month="April" day="03"/>	<date year="2023" month="April"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="MS_COM_GUID" target="https://devblogs.microsoft.com/o ldnewthing/20220928-00/?p=107221">	<reference anchor="MS_COM_GUID" target="https://devblogs.microsoft.com/o ldnewthing/20220928-00/?p=107221">
	<front>	<front>

	<title>Why does COM express GUIDs in a mix of big-endian and little- endian? Why can’t it just pick a side and stick with it?</title>	<title>Why does COM express GUIDs in a mix of big-endian and little- endian? Why can't it just pick a side and stick with it?</title>
	<author initials="R." surname="Chen" fullname="Raymond Chen">	<author initials="R." surname="Chen" fullname="Raymond Chen">

	<organization/>	<organization>Microsoft</organization>
	</author>	</author>

	<date year="2022" month="September" day="28"/>	<date year="2022" month="September"/>
	</front>	</front>
	</reference>	</reference>


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

	<date year="2023" month="March" day="23"/>	<date year="2023" month="March"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="RANDOM" target="https://peteroupc.github.io/random.ht ml">	<reference anchor="RANDOM" target="https://peteroupc.github.io/random.ht ml">
	<front>	<front>
	<title>Random Number Generator Recommendations for Applications</tit le>	<title>Random Number Generator Recommendations for Applications</tit le>
	<author initials="P." surname="Occil" fullname="Peter Occil">	<author initials="P." surname="Occil" fullname="Peter Occil">
	<organization/>	<organization/>
	</author>	</author>

	<date year="2023"/>	<date month="June" year="2023"/>
	</front>	</front>
	</reference>	</reference>


	</references>	</references>
	</references>	</references>

	<?line 2069?>

	<section anchor="test_vectors">	<section anchor="test_vectors">
	<name>Test Vectors</name>	<name>Test Vectors</name>

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

	<figure>	<figure>

	<name>Test Vector Timestamp Pseudo-code</name>	<name>Test Vector Timestamp Pseudocode</name>
	<sourcecode type="code"><![CDATA[	<sourcecode type="pseudocode"><![CDATA[
	# Gregorian to Unix Offset:	# Gregorian-to-Unix Offset:
	# The number of 100-ns intervals between the	# The number of 100 ns intervals between the
	# UUID epoch 1582-10-15 00:00:00	# UUID Epoch 1582-10-15 00:00:00
	# and the Unix epoch 1970-01-01 00:00:00	# and the Unix Epoch 1970-01-01 00:00:00
	# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000	# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000


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

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

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


	skipping to change at line 3019 ¶	skipping to change at line 2500 ¶
	time_high 12 0x1EC	time_high 12 0x1EC
	var 2 0b10	var 2 0b10
	clock_seq 14 0b11, 0x3C8	clock_seq 14 0b11, 0x3C8
	node 48 0x9F6BDECED846	node 48 0x9F6BDECED846
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: C232AB00-9414-11EC-B3C8-9F6BDECED846	final: C232AB00-9414-11EC-B3C8-9F6BDECED846
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	</section>	</section>
	<section anchor="uuidv3_example">	<section anchor="uuidv3_example">
	<name>Example of a UUIDv3 Value</name>	<name>Example of a UUIDv3 Value</name>

	<t>The MD5 computation from is detailed in <xref target="v3md5"/> using	<t>The MD5 computation from is detailed in <xref target="v3md5"/>
	the DNS Namespace ID value and the Name "www.example.com".	using the DNS Namespace ID value and the Name "www.example.com".
	while the field mapping and all values are illustrated in <xref target="v3fields	The field mapping and all values are illustrated in <xref
	"/>.	target="v3fields"/>. Finally, to further illustrate the bit swapping
	Finally to further illustrate the bit swapping for version and variant see <xref	for version and variant, see <xref target="v3vervar"/>.</t>
	target="v3vervar"/>.</t>
	<figure anchor="v3md5">	<figure anchor="v3md5">
	<name>UUIDv3 Example MD5</name>	<name>UUIDv3 Example MD5</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8	Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
	Name: www.example.com	Name: www.example.com
	------------------------------------------------------	------------------------------------------------------
	MD5: 5df418813aed051548a72f4a814cf09e	MD5: 5df418813aed051548a72f4a814cf09e
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<figure anchor="v3fields">	<figure anchor="v3fields">
	<name>UUIDv3 Example Test Vector</name>	<name>UUIDv3 Example Test Vector</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	md5_high 48 0x5df418813aed	md5_high 48 0x5df418813aed
	ver 4 0x3	ver 4 0x3
	md5_mid 12 0x515	md5_mid 12 0x515
	var 2 0b10	var 2 0b10

	skipping to change at line 3051 ¶	skipping to change at line 2537 ¶
	ver 4 0x3	ver 4 0x3
	md5_mid 12 0x515	md5_mid 12 0x515
	var 2 0b10	var 2 0b10
	md5_low 62 0b00, 0x8a72f4a814cf09e	md5_low 62 0b00, 0x8a72f4a814cf09e
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 5df41881-3aed-3515-88a7-2f4a814cf09e	final: 5df41881-3aed-3515-88a7-2f4a814cf09e
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<figure anchor="v3vervar">	<figure anchor="v3vervar">

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


	</section>	</section>
	<section anchor="uuidv4_example">	<section anchor="uuidv4_example">
	<name>Example of a UUIDv4 Value</name>	<name>Example of a UUIDv4 Value</name>

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

	<figure anchor="v4fields">	<figure anchor="v4fields">
	<name>UUIDv4 Example Test Vector</name>	<name>UUIDv4 Example Test Vector</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	random_a 48 0x919108f752d1	random_a 48 0x919108f752d1
	ver 4 0x4	ver 4 0x4
	random_b 12 0x320	random_b 12 0x320
	var 2 0b10	var 2 0b10

	skipping to change at line 3084 ¶	skipping to change at line 2574 ¶
	ver 4 0x4	ver 4 0x4
	random_b 12 0x320	random_b 12 0x320
	var 2 0b10	var 2 0b10
	random_c 62 0b01, 0xbacf847db4148a8	random_c 62 0b01, 0xbacf847db4148a8
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 919108f7-52d1-4320-9bac-f847db4148a8	final: 919108f7-52d1-4320-9bac-f847db4148a8
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<figure anchor="v4vervar">	<figure anchor="v4vervar">

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


	</section>	</section>
	<section anchor="uuidv5_example">	<section anchor="uuidv5_example">
	<name>Example of a UUIDv5 Value</name>	<name>Example of a UUIDv5 Value</name>

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

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


	<figure anchor="v5fields">	<figure anchor="v5fields">
	<name>UUIDv5 Example Test Vector</name>	<name>UUIDv5 Example Test Vector</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	sha1_high 48 0x2ed6657de927	sha1_high 48 0x2ed6657de927
	ver 4 0x5	ver 4 0x5
	sha1_mid 12 0x68b	sha1_mid 12 0x68b
	var 2 0b10	var 2 0b10

	skipping to change at line 3125 ¶	skipping to change at line 2622 ¶
	ver 4 0x5	ver 4 0x5
	sha1_mid 12 0x68b	sha1_mid 12 0x68b
	var 2 0b10	var 2 0b10
	sha1_low 62 0b01, 0x5e12665a8aea6a2	sha1_low 62 0b01, 0x5e12665a8aea6a2
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 2ed6657d-e927-568b-95e1-2665a8aea6a2	final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<figure anchor="v5vervar">	<figure anchor="v5vervar">

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


	</section>	</section>
	<section anchor="uuidv6_example">	<section anchor="uuidv6_example">
	<name>Example of a UUIDv6 Value</name>	<name>Example of a UUIDv6 Value</name>
	<figure>	<figure>
	<name>UUIDv6 Example Test Vector</name>	<name>UUIDv6 Example Test Vector</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	time_high 32 0x1EC9414C	time_high 32 0x1EC9414C

	skipping to change at line 3159 ¶	skipping to change at line 2658 ¶
	node 48 0x9F6BDECED846	node 48 0x9F6BDECED846
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846	final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	<section anchor="uuidv7_example">	<section anchor="uuidv7_example">
	<name>Example of a UUIDv7 Value</name>	<name>Example of a UUIDv7 Value</name>

	<t>This example UUIDv7 test vector utilizes a well-known Unix epoch time	<t>This example UUIDv7 test vector utilizes a well-known Unix Epoch
	stamp with	timestamp with millisecond precision to fill the first 48 bits.</t>
	millisecond precision to fill the first 48 bits.</t>
	<t>rand_a and rand_b are filled with random data.</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 r	<t>The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM
	epresented	GMT-05:00, represented as 0x017F22E279B0 or 1645557742000.</t>
	as 0x017F22E279B0 or 1645557742000</t>
	<figure>	<figure>
	<name>UUIDv7 Example Test Vector</name>	<name>UUIDv7 Example Test Vector</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	unix_ts_ms 48 0x017F22E279B0	unix_ts_ms 48 0x017F22E279B0
	ver 4 0x7	ver 4 0x7
	rand_a 12 0xCC3	rand_a 12 0xCC3
	var 2 0b10	var 2 0b10

	skipping to change at line 3185 ¶	skipping to change at line 2684 ¶
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F	final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	<section anchor="ill_examples">	<section anchor="ill_examples">
	<name>Illustrative Examples</name>	<name>Illustrative Examples</name>

	<t>The following sections contain illustrative examples which serve to sho	<t>The following sections contain illustrative examples that serve to
	w how one may use UUIDv8 <xref target="uuidv8"/> for custom and/or experimental	show how one may use UUIDv8 (<xref target="uuidv8"/>) for custom and/or
	application based logic.	experimental application-based logic. The examples below have not been
	The examples below have not been through the same rigorous testing, prototyping,	through the same rigorous testing, prototyping, and feedback loop that
	and feedback loop that other algorithms in this document have undergone.	other algorithms in this document have undergone. The authors
	The authors encouraged implementors to create your own UUIDv8 algorithm rather t	encourage implementers to create their own UUIDv8 algorithm rather than
	han use the items defined in this section.</t>	use the items defined in this section.</t>
	<section anchor="uuidv8_example">	<section anchor="uuidv8_example">

	<name>Example of a UUIDv8 Value (time-based)</name>	<name>Example of a UUIDv8 Value (Time-Based)</name>
	<t>This example UUIDv8 test vector utilizes a well-known 64 bit Unix epo	<t>This example UUIDv8 test vector utilizes a well-known 64-bit Unix
	ch timestamp with	Epoch timestamp with 10 ns precision, truncated to the
	10ns precision, truncated to the least-significant, right-most, bits	least significant, rightmost bits to fill the first 60 bits of
	to fill the first 60 bits of custom_a and custom_b while setting the version bit	custom_a and custom_b, while setting the version bits between these two
	s between these two segments to the version value of 8.</t>	segments to the version value of 8.</t>
	<t>The variant bits are set and the final segment, custom_c, is filled w	<t>The variant bits are set; and the final segment, custom_c, is filled
	ith random data.</t>	with random data.</t>
	<t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00 r	<t>Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM
	epresented	GMT-05:00, represented as 0x2489E9AD2EE2E00 or 164555774200000000
	as 0x2489E9AD2EE2E00 or 164555774200000000 (10ns-steps).</t>	(10 ns-steps).</t>
	<figure>	<figure>

	<name>UUIDv8 Example Time-based Illustrative Example</name>	<name>UUIDv8 Example Time-Based Illustrative Example</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	-------------------------------------------	-------------------------------------------
	field bits value	field bits value
	-------------------------------------------	-------------------------------------------
	custom_a 48 0x2489E9AD2EE2	custom_a 48 0x2489E9AD2EE2
	ver 4 0x8	ver 4 0x8
	custom_b 12 0xE00	custom_b 12 0xE00
	var 2 0b10	var 2 0b10
	custom_c 62 0b00, 0xEC932D5F69181C0	custom_c 62 0b00, 0xEC932D5F69181C0
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0	final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	<section anchor="uuidv8_example_name">	<section anchor="uuidv8_example_name">

	<name>Example of a UUIDv8 Value (name-based)</name>	<name>Example of a UUIDv8 Value (Name-Based)</name>
	<t>As per <xref target="uuidv5"/> name-based UUIDs that desire to use mo	<t>As per <xref target="uuidv5"/>, name-based UUIDs that want to use
	dern hashing algorithms <bcp14>MUST</bcp14> be created within the UUIDv8 space.	modern hashing algorithms <bcp14>MUST</bcp14> be created within the
	These <bcp14>MAY</bcp14> leverage newer hashing algorithms such as SHA-256 or SH	UUIDv8 space. These <bcp14>MAY</bcp14> leverage newer hashing
	A-512 defined by <xref target="FIPS180-4"/>, SHA-3 or SHAKE defined by <xref tar	algorithms such as SHA-256 or SHA-512 (as defined by <xref
	get="FIPS202"/>, or even algorithms that have not been defined yet.</t>	target="FIPS180-4"/>), SHA-3 or SHAKE (as defined by <xref
	<t>A SHA-256 version of <xref target="uuidv5_example"/> is detailed in <	target="FIPS202"/>), or even algorithms that have not been defined
	xref target="v8sha256"/> as an illustrative example detailing how this can be ac	yet.</t>
	hieved.
	The creation of the name-based UUIDv8 value in this section follows the same log	<t>A SHA-256 version of the SHA-1 computation in <xref
	ic defined in <xref target="uuidv5"/> with the difference being SHA-256 in place	target="uuidv5_example"/> is detailed in <xref target="v8sha256"/> as
	of SHA-1.</t>	an illustrative example detailing how this can be achieved. The
	<t>The field mapping and all values are illustrated in <xref target="v8f	creation of the name-based UUIDv8 value in this section follows the
	ieldssha256"/>.	same logic defined in <xref target="uuidv5"/> with the difference
	Finally to further illustrate the bit swapping for version and variant and the u	being SHA-256 in place of SHA-1.</t>
	nused/discarded part of the SHA-256 value see <xref target="v8vervar"/>.	<t>The field mapping and all values are illustrated in <xref
	An important note for secure hashing algorithms that produce outputs of an arbit	target="v8fieldssha256"/>. Finally, to further illustrate the bit
	rary size, such as those found in SHAKE, the output hash <bcp14>MUST</bcp14> be	swapping for version and variant and the unused/discarded part of the
	128 bits or larger.</t>	SHA-256 value, see <xref target="v8vervar"/>. An important note for
		secure hashing algorithms that produce outputs of an arbitrary size,
		such as those found in SHAKE, is that the output hash
		<bcp14>MUST</bcp14> be 128 bits or larger.</t>
	<figure anchor="v8sha256">	<figure anchor="v8sha256">
	<name>UUIDv8 Example SHA256</name>	<name>UUIDv8 Example SHA256</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8	Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
	Name: www.example.com	Name: www.example.com
	----------------------------------------------------------------	----------------------------------------------------------------
	SHA-256:	SHA-256:
	5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8	5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8
	]]></artwork>	]]></artwork>
	</figure>	</figure>

	skipping to change at line 3250 ¶	skipping to change at line 2771 ¶
	ver 4 0x8	ver 4 0x8
	custom_b 12 0xafd	custom_b 12 0xafd
	var 2 0b10	var 2 0b10
	custom_c 62 0b00, 0x38a375d0df1fbf6	custom_c 62 0b00, 0x38a375d0df1fbf6
	-------------------------------------------	-------------------------------------------
	total 128	total 128
	-------------------------------------------	-------------------------------------------
	final: 5c146b14-3c52-8afd-938a-375d0df1fbf6	final: 5c146b14-3c52-8afd-938a-375d0df1fbf6
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<figure anchor="v8vervar">	<figure anchor="v8vervar">

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

	<ul spacing="compact">
	<li>	<ul spacing="normal">
	<t>Line A details the full SHA-256 as a hexadecimal value with the d	<li>Line A details the full SHA-256 as a hexadecimal value with the
	ashes inserted.</t>	dashes inserted.</li>
	</li>	<li>Line B details the version and variant hexadecimal positions,
	<li>	which must be overwritten.</li>
	<t>Line B details the version and variant hexadecimal positions whic	<li>Line C details the final value after the ver and var have been
	h must be overwritten.</t>	overwritten.</li>
	</li>	<li>Line D details the discarded leftover values from the original
	<li>	SHA-256 computation.</li>
	<t>Line C details the final value after the ver/var have been overwr
	itten.</t>
	</li>
	<li>
	<t>Line D details the discarded, leftover values from the original S
	HA-256 computation.</t>
	</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>

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


		</back>

	</rfc>	</rfc>

End of changes. 319 change blocks.
	3351 lines changed or deleted	1643 lines changed or added
This html diff was produced by rfcdiff 1.48.