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 "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.0.2		<rfc 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="April"/>
	<area>ART</area>		<area>art</area>
	<workgroup>uuidrev</workgroup>		<workgroup>uuidrev</workgroup>
	<keyword>uuid</keyword>		<keyword>uuid</keyword>
			<!--[rfced] We have the following questions/comments about this text
			in the Abstract and Introduction:
			Original:
			This specification defines the UUIDs (Universally Unique IDentifiers)
			and the UUID Uniform Resource Name (URN) namespace. UUIDs are also
			known as GUIDs (Globally Unique IDentifiers).
			a) to reduce redundancy and align with the same text in RFC 4122, we have update
			d this text as follows.
			Current:
			This specification defines a Uniform Resource Name namespace for
			Universally Unique IDentifiers (UUIDs) (also known as Globally
			Unique IDentifiers (GUIDs)).
			b) Because this is the only mention of "URN namespace" in the document:
			Original:
			The IANA URN namespace registration [URNNamespaces] for UUID filed in
			[RFC4122] should be updated to reference this document.
			please confirm that this sentence should appear as is.
			-->
	<abstract>		<abstract>
	<?line 274?>		<t>This specification defines UUIDs (Universally Unique IDentifiers)
			(also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
			Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended
			to
			guarantee uniqueness across space and time. UUIDs were originally used
			in the Apollo Network Computing System (NCS), later in the Open Software
			Foundation's (OSF's) Distributed Computing Environment (DCE), and then
			in Microsoft Windows platforms.</t>
	<t>This specification defines the UUIDs (Universally Unique IDentifiers) and the		<!--[rfced] We had a few questions regarding the use of "DCE
	UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Glob		specification" in the document:
	ally Unique IDentifiers).
	A UUID is 128 bits long and is intended to guarantee		a) Will the reader understand what the "DCE specification" refers to
	uniqueness across space and time. UUIDs were originally used in the		in the sentences below? Or should some sort of citation be added?
	Apollo Network Computing System and later in the Open Software
	Foundation's (OSF) Distributed Computing Environment (DCE), and then		b) Do "DCE specification" and "OSF DCE specification" refer to the
	in Microsoft Windows platforms.</t>		same thing?
	<t>This specification is derived from the DCE specification with the
	kind permission of the OSF (now known as The Open Group).		Original:
	Information from earlier versions of the DCE specification have been		This specification is derived from the DCE specification with the
	incorporated into this document. This document obsoletes RFC4122.</t>		kind permission of the OSF (now known as The Open Group).
			Original:
			Information from earlier versions of the DCE specification have been
			incorporated into this document.
			Original:
			This document draws heavily on the OSF DCE specification for UUIDs.
			-->
			<t>This specification is derived from the OSF DCE specification with the
			kind permission of the OSF (now known as "The Open Group"). Information
			from earlier versions of the OSF DCE specification have been incorporated
			into this document. This document obsoletes 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 ap plications
	and large application vendors have sought to solve the problem of creating		and large application vendors have sought to solve the problem of creating
	a better		a better
	time-based, sortable unique identifier for use as a database key. This has		time-based, sortable unique identifier 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 ways.</t>		over the past 10+ years solving the same problem in slightly different ways.</t>
	<t>While preparing this specification, the following 16 different implem entations		<t>While preparing this specification, the following 16 different implem entations
	were analyzed for trends in total ID length, bit layout, lexical formatting/enco		were analyzed for trends in total ID length, bit layout, lexical formatting and
	ding,		encoding,
	timestamp type, timestamp format, timestamp accuracy, node format/components,		timestamp type, timestamp format, timestamp accuracy, node format and components
			,
	collision handling, and multi-timestamp tick generation sequencing:</t>		collision handling, and multi-timestamp tick generation sequencing:</t>
	<ol spacing="compact" type="1"><li>
	<t><xref target="ULID"/> by A. Feerasta</t>		<!-- [rfced] We have cut author names in this list as readers can find
	</li>		this information in full using the citation tag. Please let us
	<li>		know any objections.
	<t><xref target="LexicalUUID"/> by Twitter</t>
	</li>		Original:
	<li>		1. [ULID] by A. Feerasta
	<t><xref target="Snowflake"/> by Twitter</t>		2. [LexicalUUID] by Twitter
	</li>		3. [Snowflake] by Twitter
	<li>		4. [Flake] by Boundary
	<t><xref target="Flake"/> by Boundary</t>		5. [ShardingID] by Instagram
	</li>		6. [KSUID] by Segment
	<li>		7. [Elasticflake] by P. Pearcy
	<t><xref target="ShardingID"/> by Instagram</t>		8. [FlakeID] by T. Pawlak
	</li>		9. [Sonyflake] by Sony
	<li>		10. [orderedUuid] by IT. Cabrera
	<t><xref target="KSUID"/> by Segment</t>		11. [COMBGUID] by R. Tallent
	</li>		12. [SID] by A. Chilton
	<li>		13. [pushID] by Google
	<t><xref target="Elasticflake"/> by P. Pearcy</t>		14. [XID] by O. Poitrey
	</li>		15. [ObjectID] by MongoDB
	<li>		16. [CUID] by E. Elliott
	<t><xref target="FlakeID"/> by T. Pawlak</t>
	</li>		Current:
	<li>		1. [ULID]
	<t><xref target="Sonyflake"/> by Sony</t>		2. [LexicalUUID]
	</li>		3. [Snowflake]
	<li>		4. [Flake]
	<t><xref target="orderedUuid"/> by IT. Cabrera</t>		5. [ShardingID]
	</li>		6. [KSUID]
	<li>		7. [Elasticflake]
	<t><xref target="COMBGUID"/> by R. Tallent</t>		8. [FlakeID]
	</li>		9. [Sonyflake]
	<li>		10. [orderedUuid]
	<t><xref target="SID"/> by A. Chilton</t>		11. [COMBGUID]
	</li>		12. [SID]
	<li>		13. [pushID]
	<t><xref target="pushID"/> by Google</t>		14. [XID]
	</li>		15. [ObjectID]
	<li>		16. [CUID]
	<t><xref target="XID"/> by O. Poitrey</t>		-->
	</li>
	<li>		<ol spacing="compact" type="1">
	<t><xref target="ObjectID"/> by MongoDB</t>		<li><xref target="ULID"/></li>
	</li>		<li><xref target="LexicalUUID"/></li>
	<li>		<li><xref target="Snowflake"/></li>
	<t><xref target="CUID"/> by E. Elliott</t>		<li><xref target="Flake"/></li>
	</li>		<li><xref target="ShardingID"/></li>
			<li><xref target="KSUID"/></li>
			<li><xref target="Elasticflake"/></li>
			<li><xref target="FlakeID"/></li>
			<li><xref target="Sonyflake"/></li>
			<li><xref target="orderedUuid"/></li>
			<li><xref target="COMBGUID"/></li>
			<li><xref target="SID"/></li>
			<li><xref target="pushID"/></li>
			<li><xref target="XID"/></li>
			<li><xref target="ObjectID"/></li>
			<li><xref target="CUID"/></li>
	</ol>		</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>		<!--[rfced] We suggest listing the EIDs that this text is referring to
	<li>		for clarity. Please let us know which errata apply in this sentence.
	<t>Decouple other UUID versions from UUIDv1 bit layout so that field
	s like "time_hi_and_version" do not need to be referenced within a non-time-base		Original:
	d UUID while also providing "UUIDv1 like" definition sections for UUIDv3, UUIDv4
	, and UUIDv5.</t>		Further, [RFC4122] itself was in need an overhaul to address a number
	</li>		of topics such as but not limited to the following:
	<li>
	<t>Provide implementation best practices around many real-world scen		1. Miscellaneous erratas. Mostly around bit layout clarifications
	arios and corner cases observed by existing and prototype implementations.</t>		which lead to inconsistent implementations.
	</li>
	<li>		Perhaps (with corresponding errata reference entries as described at
	<t>Update the document to address security best practices and consid		https://www.rfc-editor.org/styleguide/part2/#ref_errata):
	erations for the modern age as it pertains MAC addresses, hashing algorithms, se
	cure randomness, and other topics.</t>		Further, [RFC4122] itself was in need an overhaul to address a number
	</li>		of topics such as, but not limited to, the following:
	<li>
	<t>Provide implementations a standard-based option for implementatio		1. Implementation of miscellaneous errata reports (mostly bit-layout
	n specific and/or experimental UUID designs.</t>		clarifications that lead to inconsistent implementations):
	</li>		[Err####], [Err###1], etc.
	<li>
	<t>Provide more test vectors that illustrate real UUIDs created as p		-->
	er the specification.</t>
	</li>		<ol spacing="normal" type="1">
			<li>Implementation of miscellaneous errata reports. Mostly around
			bit-layout clarifications, which lead to inconsistent
			implementations <xref target="Err1957"/>, <xref target="Err3546"/>,
			<xref target="Err4975"/>, <xref target="Err4976"/>, <xref
			target="Err5560"/>, etc.</li>
			<li>Decoupling other UUID versions from the UUIDv1 bit layout so that
			fields like "time_hi_and_version" do not need to be referenced
			within a UUID that is not time based while also providing
			definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and
			UUIDv5.</li>
			<li>Providing implementation best practices around many real-world
			scenarios and corner cases observed by existing and prototype
			implementations.</li>
			<li>Addressing security best practices and
			considerations for the modern age as it pertains to MAC addresses,
			hashing algorithms, secure randomness, and other topics.</li>
			<li>Providing implementations a standard-based option for
			implementation-specific and/or experimental UUID designs.</li>
			<li>Providing more test vectors that illustrate real UUIDs created as
			per the specification.</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&nbsp;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">
	<dt>UUID</dt>		<!-- [rfced] Regarding text in the "Abbreviations" section:
	<dd>
	<t>Universally Unique Identifier</t>		a) Would you like the abbreviations in Section 3.2 to be alphabetized?
	</dd>
	<dt>UUIDv1</dt>		b) Regarding UUID and its versions:
	<dd>
	<t>Universally Unique Identifier Version 1</t>		i) Is it necessary to list all of the versions with UUID? This seems
	</dd>		common notation in RFCs.
	<dt>UUIDv2</dt>
	<dd>		Current:
	<t>Universally Unique Identifier Version 2</t>
	</dd>		UUIDv1 Universally Unique Identifier Version 1
	<dt>UUIDv3</dt>
	<dd>		UUIDv2 Universally Unique Identifier Version 2
	<t>Universally Unique Identifier Version 3</t>
	</dd>		UUIDv3 Universally Unique Identifier Version 3
	<dt>UUIDv4</dt>
	<dd>		UUIDv4 Universally Unique Identifier Version 4
	<t>Universally Unique Identifier Version 4</t>
	</dd>		UUIDv5 Universally Unique Identifier Version 5
	<dt>UUIDv5</dt>
	<dd>		UUIDv6 Universally Unique Identifier Version 6
	<t>Universally Unique Identifier Version 5</t>
	</dd>		UUIDv7 Universally Unique Identifier Version 7
	<dt>UUIDv6</dt>
	<dd>		UUIDv8 Universally Unique Identifier Version 8
	<t>Universally Unique Identifier Version 6</t>
	</dd>		ii) Throughout the text, we will update instances of "UUID version #"
	<dt>UUIDv7</dt>		to instead read as "UUIDv#" unless we hear objection.
	<dd>
	<t>Universally Unique Identifier Version 7</t>		c) We note that the abbreviation for SHA-1 contains a number of bits.
	</dd>		This leads us to a few questions:
	<dt>UUIDv8</dt>
	<dd>		i) Is this convoluting the 1:1 relationship between initialism and
	<t>Universally Unique Identifier Version 8</t>		expansion? That is, the other SHA abbreviations have a bit size that
	</dd>		correlates to their abbreviation.
	<dt>URN</dt>
	<dd>		Perhaps:
	<t>Uniform Resource Names</t>		SHA-1 Secure Hash Algorithm 1
	</dd>
	<dt>ABNF</dt>		or
	<dd>
	<t>Augmented Backus-Naur Form</t>		Perhaps:
	</dd>		SHA-1 Secure Hash Algorithm 1 (160 bits)
	<dt>CSPRNG</dt>
	<dd>		ii) If a bit size is included for SHA-1, should a bit size be included
	<t>Cryptographically Secure Pseudo-Random Number Generator</t>		for SHA-3?
	</dd>
	<dt>MAC</dt>		d) We had the following questions/comments about the abbreviation MSB
	<dd>		(Most Significant Bit):
	<t>Media Access Control</t>
	</dd>		i) Please note that we have lowercased "Most Significant Byte" to
	<dt>MSB</dt>		avoid confusion with this abbreviation.
	<dd>
	<t>Most Significant Bit</t>		ii) The tables in Sections 4.1 & 4.2 use "Msb#" format. Should these be
	</dd>		made "MSB#"?
	<dt>DBMS</dt>
	<dd>		iii) To match the guidance at
	<t>Database Management System</t>		https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we generally
	</dd>		use an abbreviation (instead of the expansion) once it has been
	<dt>IEEE</dt>		introduced. However, we often see the expansion of MSB with text
	<dd>		interjected. Should updates like the following be made (just
	<t>Institute of Electrical and Electronics Engineers, Inc.</t>		examples, not all cases listed)?
	</dd>
	<dt>ITU</dt>		Original:
	<dd>		the most significant 4 bits
	<t>International Telecommunication Union</t>
	</dd>		the most significant 12 bits
	<dt>MD5</dt>
	<dd>		first 48 most significant bits
	<t>Message Digest 5</t>
	</dd>		The most significant 32 bits
	<dt>SHA</dt>
	<dd>		Perhaps:
	<t>Secure Hash Algorithm</t>		the 4 MSBs
	</dd>
	<dt>SHA-1</dt>		the 12 MSBs
	<dd>
	<t>Secure Hash Algorithm 1 with message digest of 160 bits</t>		first 48 MSBs
	</dd>
	<dt>SHA-224</dt>		The 32 MSBs
	<dd>
	<t>Secure Hash Algorithm 2 with message digest size of 224 bits</t>		-->
	</dd>
	<dt>SHA-256</dt>		<dl newline="false" spacing="normal" indent="14">
	<dd>		<dt>ABNF</dt> <dd>Augmented Backus-Naur Form</dd>
	<t>Secure Hash Algorithm 2 with message digest size of 256 bits</t>		<dt>CSPRNG</dt> <dd>Cryptographically Secure Pseudorandom Number Genera
	</dd>		tor</dd>
	<dt>SHA-512</dt>		<dt>DBMS</dt> <dd>Database Management System</dd>
	<dd>		<dt>IEEE</dt> <dd>Institute of Electrical and Electronics Engineers</dd
	<t>Secure Hash Algorithm 2 with message digest size of 512 bits</t>		>
	</dd>		<dt>ITU</dt> <dd>International Telecommunication Union</dd>
	<dt>SHA-3</dt>		<dt>MAC</dt> <dd>Media Access Control</dd>
	<dd>		<dt>MD5</dt> <dd>Message Digest 5</dd>
	<t>Secure Hash Algorithm 3</t>		<dt>MSB</dt> <dd>Most Significant Bit</dd>
	</dd>		<dt>OID</dt> <dd>Object Identifier</dd>
	<dt>SHAKE</dt>		<dt>SHA</dt> <dd>Secure Hash Algorithm</dd>
	<dd>		<dt>SHA-1</dt> <dd>Secure Hash Algorithm 1 (with message digest of 160
	<t>Secure Hash Algorithm 3 based on KECCAK algorithm</t>		bits)</dd>
	</dd>		<dt>SHA-3</dt> <dd>Secure Hash Algorithm 3 (arbitrary size)</dd>
	<dt>UTC</dt>		<dt>SHA-224</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	<dd>		f 224 bits</dd>
	<t>Coordinated Universal Time</t>		<dt>SHA-256</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	</dd>		f 256 bits</dd>
	<dt>OID</dt>		<dt>SHA-512</dt> <dd>Secure Hash Algorithm 2 with message digest size o
	<dd>		f 512 bits</dd>
	<t>Object Identifier</t>		<dt>SHAKE</dt> <dd>Secure Hash Algorithm 3 based on the KECCAK algorith
	</dd>		m</dd>
			<dt>URN</dt> <dd>Uniform Resource Names</dd>
			<dt>UTC</dt> <dd>Coordinated Universal Time</dd>
			<dt>UUID</dt> <dd>Universally Unique Identifier</dd>
			<dt>UUIDv1</dt> <dd>Universally Unique Identifier version 1</dd>
			<dt>UUIDv2</dt> <dd>Universally Unique Identifier version 2</dd>
			<dt>UUIDv3</dt> <dd>Universally Unique Identifier version 3</dd>
			<dt>UUIDv4</dt> <dd>Universally Unique Identifier version 4</dd>
			<dt>UUIDv5</dt> <dd>Universally Unique Identifier version 5</dd>
			<dt>UUIDv6</dt> <dd>Universally Unique Identifier version 6</dd>
			<dt>UUIDv7</dt> <dd>Universally Unique Identifier version 7</dd>
			<dt>UUIDv8</dt> <dd>Universally Unique Identifier version 8</dd>
	</dl>		</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" -&gt; "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.
	UUID formats and layout, bit definitions start at 0 and end at 127 while octet d
	efinitions start at 0 and end at 15.</t>		<!-- [rfced] To avoid personifying the "bit definitions", may we
			update "While discussing UUID formats..." to "In terms of these
			UUID formats..."?
			Current:
			The UUID format is 16 octets (128 bits) in size; the variant bits
			in conjunction with the version bits described in the next sections
			determine finer structure. While discussing UUID formats and
			layout, bit definitions start at 0 and end at 127, while octet
			definitions start at 0 and end at 15.
			Perhaps:
			The UUID format is 16 octets (128 bits) in size; the variant bits
			in conjunction with the version bits described in the next sections
			determine finer structure. In terms of these UUID formats and
			layout, bit definitions start at 0 and end at 127, while octet
			definitions start at 0 and end at 15.
			-->
			In terms of these UUID formats and layout, bit
			definitions start at 0 and end at 127, while octet definitions start at 0
			and end at 15.</t>
	<t>In the absence of explicit application or presentation protocol		<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 620 ¶
	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 672 ¶
	<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 764 ¶
	<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>		<!--[rfced] Please review the use of "bits...will contain...bits".
			Should this be updated as follows? Note: similar text occurs
			more than once in the document.
			Original:
			12 bits that will contain the least significant 12 bits from the
			60 bit starting timestamp. Occupies bits 52 through 63 (octets
			6-7).
			Perhaps:
			The least significant 12 bits from the
			60 bit starting timestamp. Occupies bits 52 through 63 (octets
			6-7).
			-->
	<dt>time_high:</dt>		<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
	nd <xref target="C311"/>.		<!--[rfced] This text seems to switch between singular and plural.
	As such, the definition of these UUIDs is outside the scope of this specificatio		Please review our suggested text and let us know if another
	n.</t>		rephrase is preferred.
			Original:
			UUID version 2 is known as DCE Security UUIDs [C309] and [C311].
			As such, the definition of these UUIDs is outside the scope of this
			specification.
			Perhaps:
			UUID version 2 is for DCE Security UUIDs (see [C309] and [C311]).
			As such, the definition of these UUIDs is outside the scope of this
			specification.
			-->
			<t>UUIDv2 is for DCE Security UUIDs (see <xref target="C309"/> and
			<xref target="C311"/>). As such, the definition of these UUIDs is
			outside the scope of this specification.</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>
	<t>48 bit big-endian unsigned number of Unix epoch timestamp in mill		<!-- [rfced] May we update "number of Unix epoch timestamp" to "number
	iseconds as		of the Unix epoch timestamp" for readability?
	per <xref target="timestamp_considerations"/>.
	Occupies bits 0 through 47 (octets 0-5).</t>		Original:
	</dd>		unix_ts_ms:
			48 bit big-endian unsigned number of Unix epoch timestamp in
			milliseconds as per Section 6.1. Occupies bits 0 through 47
			(octets 0-5).
			Perhaps:
			unix_ts_ms:
			48-bit big-endian unsigned number of the Unix Epoch timestamp in
			milliseconds as per Section 6.1. Occupies bits 0 through 47
			(octets 0-5).
			-->
			<dd>48-bit big-endian unsigned number of the Unix Epoch timestamp in
			milliseconds as per <xref target="timestamp_considerations"/>.
			Occupies bits 0 through 47 (octets 0-5).</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
	vendor-specific		<!--[rfced] Please review the use of "RFC-compatible" in the following
	use cases.		text. Compatibility with the RFC document series in what way?
	The only requirement is that the variant and version bits <bcp14>MUST</bcp14> be
	set as		Original:
	defined in <xref target="variant_field"/> and <xref target="version_field"/>.		UUID version 8 provides an RFC-compatible format for experimental or
	UUIDv8's uniqueness will be implementation-specific and <bcp14>MUST NOT</bcp14>		vendor-specific use cases.
	be assumed.</t>
	<t>The only explicitly defined bits are those of the version and variant		-->
	fields, leaving 122
	bits		<t>UUIDv8 provides a format for experimental
	for implementation specific UUIDs. To be clear:		or vendor-specific use cases. The only requirement is that the
	UUIDv8 is not a replacement for UUIDv4 <xref target="uuidv4"/> where all 122 ext		variant and version bits <bcp14>MUST</bcp14> be set as defined in
	ra bits are		Sections <xref target="variant_field" format="counter"/> and <xref
	filled with random data.</t>		target="version_field" format="counter"/>. UUIDv8's uniqueness will be
			implementation specific and <bcp14>MUST NOT</bcp14> be assumed.</t>
			<t>The only explicitly defined bits are those of the version and
			variant fields, leaving 122 bits for implementation-specific UUIDs. To
			be clear, UUIDv8 is not a replacement for UUIDv4 (<xref
			target="uuidv4"/>) where all 122 extra bits are filled with random
			data.</t>
	<t>Some example situations in which UUIDv8 usage could occur:</t>		<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>
	<t>Implementations <bcp14>MAY</bcp14> alter the actual timestamp. So		<!-- [rfced] May we update the second sentence as follows for clarity?
	me examples include security		Please let us know if this alters the intended meaning or if
	considerations around providing a real clock value within a UUID, to correct		there is another way to phrase this sentence.
	inaccurate clocks, to handle leap seconds, or instead of dividing a number of mi
	croseconds by 1000 to obtain a millisecond value; dividing by 1024 (or some othe		Original:
	r value) for performance reasons. This specification makes no		Implementations MAY alter the actual timestamp. Some examples
	requirement or guarantee about how close the clock value needs to be to the actu		include security considerations around providing a real clock
	al		value within a UUID, to correct inaccurate clocks, to handle
	time.		leap seconds, or instead of dividing a number of microseconds by
	If UUIDs do not need to be frequently generated, the UUIDv1 or UUIDv6 timestamp		1000 to obtain a millisecond value; dividing by 1024 (or some
	can		other value) for performance reasons.
	simply be the system time multiplied by the number of 100-nanosecond
	intervals per system time interval.</t>		Perhaps:
	</dd>		Implementations MAY alter the actual timestamp. Some examples
			include security considerations around providing a real-clock
			value within a UUID to 1) correct inaccurate clocks, 2) handle
			leap seconds, or 3) obtain a millisecond value by dividing by
			1024 (or some other value) for performance reasons (instead of
			dividing a number of microseconds by 1000).
			-->
			<dd>Implementations <bcp14>MAY</bcp14> alter the actual
			timestamp. Some examples include security considerations around
			providing a real-clock value within a UUID to 1) correct inaccurate
			clocks, 2) handle leap seconds, or 3) obtain a millisecond value by
			dividing by 1024 (or some other value) for performance reasons
			(instead of dividing a number of microseconds by 1000). This
			specification makes no requirement or guarantee about how close the
			clock value needs to be to the actual time. If UUIDs do not need to
			be frequently generated, the UUIDv1 or UUIDv6 timestamp can simply
			be the system time multiplied by the number of 100-nanosecond
			intervals per system-time interval.</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.
	illisecond
	value by 4096 and round down (toward zero) to an integer result to arrive at a n		<!--[rfced] Would you like us to update to use superscript instead of
	umber		"to the 12th power" in the following?
	between 0 and the maximum allowed for the indicated bits
	which sorts monotonically based on time. Each increasing fractional		Original:
	value will result in an increasing bit field value, to the		If we wish to
	precision available with these bits.</t>		encode this as 12 bits, we can take the count of possible values
	<t>For example, let's assume a system timestamp of 1 Jan 2023 12:34:		that fit in those bits (4096, or 2 to the 12th power),...
	56.1234567.
	Taking the precision greater than 1ms gives us a value of 0.4567, as a		-->
	fraction of a millisecond. If we wish to encode this as 12 bits, we can		If we wish to
	take the count of possible values that fit in those bits (4096, or 2 to the 12th		encode this as 12 bits, we can take the count of possible values
	power)		that fit in those bits (4096 or 2<sup>12</sup>), multiply
	and multiply it by our millisecond fraction value of 0.4567 and truncate the res		it by our millisecond fraction value of 0.4567, and truncate the
	ult to		result to an integer, which gives an integer value of
	an integer, which gives an integer value of 1870. Expressed as hexadecimal it is		1870. Expressed as hexadecimal, it is 0x74E or the binary bits
	0x74E, or the binary bits 0b011101001110. One can then use those 12 bits		0b011101001110. One can then use those 12 bits as the most
	as the most significant (left-most) portion of the random section of the UUID		significant (leftmost) portion of the random section of the UUID
	(e.g., the rand_a field in UUIDv7).		(e.g., the rand_a field in UUIDv7). This works for any desired bit
	This works for any desired bit length that fits into a UUID, and applications		length that fits into a UUID, and applications can decide the
	can decide the appropriate length based on available clock precision, but for		appropriate length based on available clock precision; for
	UUIDv7, it is limited to 12 bits at maximum to reserve sufficient space for		UUIDv7, it is limited to 12 bits at maximum to reserve sufficient
	random bits.</t>		space for random bits.</t>
	<t>The main benefit to encoding additional timestamp precision		<t>The main benefit to encoding additional timestamp precision is
	is that it utilizes additional time precision already available in the system cl		that it utilizes additional time precision already available in the
	ock		system clock to provide values that are more likely to be unique; thus
	to provide values that are more likely to be unique, and thus may simplify		, it may simplify certain implementations. This technique can
	certain implementations. This technique can also be used in conjunction with one		also be used in conjunction with one of the other methods, where
	of the other methods, where this additional time precision would immediately		this additional time precision would immediately follow the
	follow the timestamp, and then if any bits are to be used as clock sequence		timestamp. Then, if any bits are to be used as a clock sequence,
	they would follow next.</t>		they would follow next.</t></dd>
	</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
	eaturing hashing algorithms (MD5 or SHA-1), this document retains the usage of t		<!--[rfced] Would this update to "historical documents" convey the
	he adjective "name-based" in order to maintain consistency with historical docum		correct meaning?
	ents and existing implementations.</t>
			Original:
			Although some prefer to use the word "hash-based" to describe UUIDs
			featuring hashing algorithms (MD5 or SHA-1), this document retains
			the usage of the adjective "name-based" in order to maintain
			consistency with historical documents and existing implementations.
			Perhaps:
			Although some prefer to use the word "hash-based" to describe UUIDs
			featuring hashing algorithms (MD5 or SHA-1), this document retains
			the usage of the term "name-based" in order to maintain consistency
			with previously published documents and existing implementations.
			-->
			<t>Although some prefer to use the word "hash-based" to describe UUIDs
			featuring hashing algorithms (MD5 or SHA-1), this document retains the
			usage of the term "name-based" in order to maintain consistency with
			previously published documents and existing implementations.</t>
	<t>The requirements for name-based UUIDs are as follows:</t>		<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 this specification, <xref target="RFC8499"/> domain		For example, at the time of writing,
	name system (DNS) has three conveyance formats: common (www.example.com), presen		Domain Name System (DNS) <xref target="RFC9499"/> has
	tation (www.example.com.) and wire format (3www7example3com0).		three conveyance formats: common (www.example.com), presentation
	Looking at <xref target="X500"/> distinguished names (DNs), the previous version		(www.example.com.), and wire format (3www7example3com0).
	of this specification allowed either text based or binary distinguished encodin
	g rules (DER) based names as inputs.		<!--[rfced] To what does "the previous version of this specification"
	For <xref target="RFC1738"/> uniform resource locators (URLs), one could provide		refer? RFC 4122?
	a fully-qualified domain-name (FQDN) with or without the protocol identifier (w
	ww.example.com) or (https://www.example.com).		Original:
	When it comes to <xref target="X660"/> object identifiers (OIDs) one could choos		Looking at [X500] distinguished names (DNs), the previous version of
	e dot-notation without the leading dot (2.999), choose to include the leading do		this specification allowed either text based or binary distinguished
	t (.2.999) or select one of the many formats from <xref target="X680"/> such as		encoding rules (DER) based names as inputs.
	OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/Example).
	While most users may default to the common format for DNS, FQDN format for a URL		Perhaps:
	, text format for X.500 and dot-notation without a leading dot for OID; name-bas		Looking at [X500] distinguished names (DNs), [RFC4122] allowed either
	ed UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary input wh		text-based or binary DER-based names as inputs.
	ich will compute name-based UUIDs for any of the aforementioned example names an		-->
	d others not defined here.		Looking at <xref target="X500"/>
	Each name format within a namespace will output different UUIDs.		Distinguished Names (DNs), <xref target="RFC4122" format="default"/> a
	As such, the mechanisms or conventions used for allocating names and ensuring th		llowed either text-based or binary
	eir uniqueness within their namespaces are beyond the scope of this specificatio		DER-based names as inputs. For Uniform Resource Locators (URLs)
	n.</t>		<xref target="RFC1738"/>, one could provide a Fully Qualified
	</dd>		Domain Name (FQDN) with or without the protocol identifier
	</dl>		www.example.com or https://www.example.com. When it comes to
			Object Identifiers (OIDs) <xref target="X660"/>, one could choose
			dot notation without the leading dot (2.999), choose to include the
			leading dot (.2.999), or select one of the many formats from <xref
			target="X680"/> such as OID Internationalized Resource Identifier
			(OID-IRI) (/Joint-ISO-ITU-T/Example). While most users may default
			to the common format for DNS, FQDN format for a URL, text format for
			X.500, and dot notation without a leading dot for OID, name-based
			UUID implementations generally <bcp14>SHOULD</bcp14> allow arbitrary
			input that will compute name-based UUIDs for any of the
			aforementioned example names and others not defined here. Each name
			format within a namespace will output different UUIDs. As such, the
			mechanisms or conventions used for allocating names and ensuring
			their uniqueness within their namespaces are beyond the scope of
			this specification.</t>
	</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 randomization		<!--[rfced] Should this actually be a citation with a corresponding
	techniques (IEEE 802.11bh) as an alternative to the pseudo-random logic provide		reference entry? If so, please provide the correct reference
	d in this section.</t>		entry information as well as if it should be listed in the
	<t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a 4		Normative or Informative section.
	8 bit cryptographic-quality random
	number as per <xref target="unguessability"/> to use it as the node ID.		Original:
	After generating the 48 bit fully randomized node value, implementations <bcp14>		Implementations MAY leverage MAC address randomization techniques
	MUST</bcp14> set the least significant bit of the first octet of the node ID set		(IEEE 802.11bh) as an alternative to the pseudo-random logic provided
	to 1.		in this section.
	This bit is the unicast/multicast bit, which will never be set in IEEE 802
	addresses obtained from network cards. Hence, there can never be a		-->
	conflict between UUIDs generated by machines with and without network
	cards.		<t>Implementations <bcp14>MAY</bcp14> leverage MAC address
	An example of generating a randomized 48 bit node value and the subsequent bit m		randomization techniques <xref target="IEEE802.11bh" format="default"/>
	odification is detailed in the <xref target="test_vectors"/> appendix.		as an alternative to the
	For more information about IEEE 802 address and the unicast/multicast or local/g		pseudorandom logic provided in this section.</t>
	lobal bits please review <xref target="RFC7042"/>.</t>		<t>Alternatively, implementations <bcp14>MAY</bcp14> elect to obtain a
			48-bit cryptographic-quality random number as per <xref
			target="unguessability"/> to use as the Node ID.
			<!--[rfced] In the following text, which meaning is correct?
			Original:
			After generating the 48 bit fully randomized node value,
			implementations MUST set the least significant bit of the first octet
			of the node ID set to 1.
			Perhaps A (the least significant bit is set to 1):
			After generating the 48-bit fully randomized node value,
			implementations MUST set the least significant bit of the first octet
			of the node ID to 1.
			Perhaps B (the least significant bit is set to some value for the first octet of
			the node ID that is set to 1):
			After generating the 48-bit fully randomized node value,
			implementations MUST set the least significant bit of the first octet
			of the node ID set to 1.
			-->
			After generating the 48-bit fully randomized node value,
			implementations <bcp14>MUST</bcp14> set the least significant bit of
			the first octet of the Node ID to 1. This bit is the
			unicast or multicast bit, which will never be set in IEEE 802 addresses
			obtained from network cards. Hence, there can never be a conflict
			between UUIDs generated by machines with and without network cards.
			An example of generating a randomized 48-bit node value and the
			subsequent bit modification is detailed in <xref
			target="test_vectors"/>. For more information about IEEE 802 address
			and the unicast or multicast or local/global bits, please review <xref
			target="RFC9542"/>.</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
	d be replaced with references to this document.		<!--[rfced] Is it necessary to include both of these paragraphs as
	References to <xref target="RFC4122"/> document's Section 4.1.2 should be update		they seem to convey the same information?
	d to refer to this document's <xref target="format"/>.</t>
	<t>The IANA URN namespace registration <xref target="URNNamespaces"/> for		Original:
	UUID filed in <xref target="RFC4122"/> should be updated to reference this docum		All references to [RFC4122] in the IANA registries should be replaced
	ent.</t>		with references to this document. References to [RFC4122] document's
	<t>Finally IANA should track UUID Subtypes and Special Case "Namespace IDs		Section 4.1.2 should be updated to refer to this document's
	Values" as specified in <xref target="iana2"/> and <xref target="iana3"/>.</t>		Section 4.
	<t>When evaluating requests, the designated expert(s) should consider comm
	unity feedback, how well-defined is the reference specification, and this specif		The IANA URN namespace registration [URNNamespaces] for UUID filed in
	ication's requirements.		[RFC4122] should be updated to reference this document.
	Vendor-specific, application-specific, and deployment-specific values are unable
	to be registered.		Perhaps:
	Specification documents should be published in a stable, freely available manner		All references to [RFC4122] in IANA registries (outside of those
	(ideally located with a URL) but need not be standards.		created by this document) have been replaced with references to
	The designated experts will either approve or deny the registration request, and		this document, including the IANA URN namespace registration
	communicate their decision to IANA. Denials should include an explanation and,		[URNNamespaces] for UUID. References to Section 4.1.2 of [RFC4122]
	if applicable, suggestions as to how to make the request successful.</t>		have been updated to refer to Section 4 of this document.
			-->
			<t>All references to <xref target="RFC4122"/> in IANA registries
			(outside of those created by this document) have been replaced with
			references to this document, including the IANA URN namespace
			registration <xref target="URNNamespaces"/> for UUID. References to
			<xref target="RFC4122" sectionFormat="of" section="4.1.2"/> have been
			updated to refer to <xref target="format"/> of this document.</t>
			<t>Finally, IANA should track UUID Subtypes and Special Case "Namespace
			IDs Values" as specified in Sections <xref target="iana2"
			format="counter"/> and <xref target="iana3" format="counter"/> at the foll
			owing location: <eref brackets="angle" target="https://www.iana.org/assignments/
			uuid"/>.</t>
			<t>When evaluating requests, the designated expert should consider
			community feedback, how well-defined the reference specification is, and
			this specification's requirements. Vendor-specific,
			application-specific, and deployment-specific values are unable to be
			registered.
			<!--[rfced] Is this use of "standards" referring to RFCs that are on
			the Standards Track? Or is this the general use of the term?
			Original:
			Vendor-specific, application-specific, and deployment-specific values
			are unable to be registered. Specification documents should be
			published in a stable, freely available manner (ideally located with a
			URL) but need not be standards.
			-->
			Specification documents should be published in a stable,
			freely available manner (ideally, located with a URL) but need not be
			standards. The designated expert will either approve or deny the
			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
	entifier). A UUID is 128 bits long, and can guarantee uniqueness across space an		<!-- [rfced] RFC 1738 has been obsoleted by RFC 4248. We have updated
	d time. UUIDs were originally used in the Apollo Network Computing System and la		to cite the latter. Please let us know any objections.
	ter in the Open Software Foundation\'s (OSF) Distributed Computing Environment (
	DCE), and then in Microsoft Windows platforms.</t>		Original:
	<t>This specification is derived from the DCE specification with t		[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
	he kind permission of the OSF (now known as The Open Group). Information from ea		Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
	rlier versions of the DCE specification have been incorporated into this documen		December 1994, <https://www.rfc-editor.org/info/rfc1738>.
	t. [STANDARDS-TRACK]</t>
	</abstract>		Current:
	</front>		[RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, DOI
	<seriesInfo name="RFC" value="4122"/>		10.17487/RFC4248, October 2005,
	<seriesInfo name="DOI" value="10.17487/RFC4122"/>		<https://www.rfc-editor.org/info/rfc4248>.
	</reference>		-->
	<reference anchor="RFC5234">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1738.xml"
	<title>Augmented BNF for Syntax Specifications: ABNF</title>		/>
	<author fullname="D. Crocker" initials="D." role="editor" surname="C		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"
	rocker"/>		/>
	<author fullname="P. Overell" initials="P." surname="Overell"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"
	<date month="January" year="2008"/>		/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	<t>Internet technical specifications often need to define a formal		/>
	syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"
	gmented BNF (ABNF), has been popular among many Internet specifications. The cur		/>
	rent specification documents ABNF. It balances compactness and simplicity with r		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"
	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		<!--[rfced] RFC 7042 has been obsoleted by RFC 9542. We have updated
	for a core lexical analyzer of the type common to several Internet specification		to point to the latter. Please let us know any objections.-->
	s. [STANDARDS-TRACK]</t>
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9542.xml"
	</front>		/>
	<seriesInfo name="STD" value="68"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
	<seriesInfo name="RFC" value="5234"/>		/>
	<seriesInfo name="DOI" value="10.17487/RFC5234"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"
	</reference>		/>
	<reference anchor="RFC6151">		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8937.xml"
	<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
	&amp; ASN.1 encoding rules</title>		(ASN.1) &amp; 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">		<!-- [rfced] Please review the title for reference [Snowflake] as the
			URL navigates to a page titled "snowflake-2010", and we were
			unable to find a URL with the title below.
			Current:
			[Snowflake]
			Twitter, "Snowflake is a network service for generating
			unique ID numbers at high scale with some simple
			guarantees.", commit b3f6a3c, May 2014,
			<https://github.com/twitter-
			archive/snowflake/releases/tag/snowflake-2010>.
			-->
			<reference anchor="Snowflake" target="https://github.com/twitter-archive
			/snowflake">
	<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 &amp; IDs at Instagram</title>		<title>Sharding &amp; 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">		<!-- [rfced] For reference [Microsoft], the provided URL navigates to
			a page titled "1.1 Glossary", where "curly braced GUID string" is
			defined lower on the page. To better match the title provided,
			may we update to the following URL with the title "2.3.4.3 GUID -
			Curly Braced String Representation"?
			https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af2d3-5
			c00-4899-bc87-ed4c6515e80d
			Original:
			[Microsoft]
			Microsoft, "curly braced GUID string", 3 April 2023,
			<https://learn.microsoft.com/en-
			us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-
			a93b-2f5c833d7d92>.
			-->
			<reference anchor="Microsoft" target="https://learn.microsoft.com/en-us/
			openspecs/windows_protocols/ms-dtyp/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>
			<!-- [rfced] Please review the URL for reference [IBM_NCS] and let us
			know if you would like to update to the newest version of this
			manual:
			https://www.ibm.com/docs/en/aix/7.3?topic=u-uuid-get-command
			Current:
			[IBM_NCS] IBM, "uuid_gen Command (NCS)", March 2023,
			<https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
			command-ncs>.
			-->
	<reference anchor="IBM_NCS" target="https://www.ibm.com/docs/en/aix/7.1? topic=u-uuid-gen-command-ncs">		<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[
	# Gregorian to Unix Offset:		<!--[rfced] May we update the pseudocode in Figure 15 as follows (note there are
	# The number of 100-ns intervals between the		multiple changes):
	# UUID epoch 1582-10-15 00:00:00
	# and the Unix epoch 1970-01-01 00:00:00		Original:
			# Gregorian to Unix Offset:
			# The number of 100-ns intervals between the
			# UUID epoch 1582-10-15 00:00:00
			# and the Unix epoch 1970-01-01 00:00:00
			# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
			# Unix 64 bit Nanosecond Timestamp:
			# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
			# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000
			# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
			# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset
			# Work:
			# Greg_100_ns = (1645557742000000000/100)+122192928000000000
			# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100
			# Final:
			# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
			Perhaps:
			# Gregorian-to-Unix Offset:
			# The number of 100 ns intervals between the
			# UUID Epoch 1582-10-15 00:00:00
			# and the Unix Epoch 1970-01-01 00:00:00
			# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
			# Unix 64-bit Nanosecond Timestamp:
			# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
			# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000
			# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
			# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset
			# Work:
			# Greg_100_ns = (1645557742000000000/100)+122192928000000000
			# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100
			# Final:
			# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
			-->
			<sourcecode type="pseudocode"><![CDATA[
			# Gregorian-to-Unix Offset:
			# The number of 100 ns intervals between the
			# UUID Epoch 1582-10-15 00:00:00
			# and the Unix Epoch 1970-01-01 00:00:00
	# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000		# 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 3000 ¶		skipping to change at line 2992 ¶
	# 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
	# Final:		# Final:
	# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000		# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<section anchor="uuidv1_example">		<section anchor="uuidv1_example">
	<name>Example of a UUIDv1 Value</name>		<name>Example of a UUIDv1 Value</name>
	<figure>		<figure>
	<name>UUIDv1 Example Test Vector</name>		<name>UUIDv1 Example Test Vector</name>
	<artwork><![CDATA[		<artwork><![CDATA[
	-------------------------------------------		-------------------------------------------
	field bits value		field bits value
	-------------------------------------------		-------------------------------------------
	time_low 32 0xC232AB00		time_low 32 0xC232AB00
	time_mid 16 0x9414		time_mid 16 0x9414
	ver 4 0x1		ver 4 0x1
	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>
			<!--[rfced] We see "Ver Var" in the title of Figure 19 and "Ver/Var"
			in the title of Figure 20. Should these be made uniform?-->
	</section>		</section>
	<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 3052 ¶
	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 3089 ¶
	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
	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>
			<!--[rfced] Please review Figure 24 for line breaking of "-2dee3e35"
			and let us know if any updates are necessary.-->
	<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 3176 ¶
	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 3202 ¶
	-------------------------------------------		-------------------------------------------
	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.
	A-512 defined by <xref target="FIPS180-4"/>, SHA-3 or SHAKE defined by <xref tar
	get="FIPS202"/>, or even algorithms that have not been defined yet.</t>		<!--[rfced] The structure of this list is difficult to parse. We
	<t>A SHA-256 version of <xref target="uuidv5_example"/> is detailed in <		assume the citations apply to both algorithms listed before
	xref target="v8sha256"/> as an illustrative example detailing how this can be ac		them.
	hieved.
	The creation of the name-based UUIDv8 value in this section follows the same log		Original:
	ic defined in <xref target="uuidv5"/> with the difference being SHA-256 in place		These MAY leverage newer hashing algorithms, such as SHA-256 or
	of SHA-1.</t>		SHA-512 defined by [FIPS180-4], SHA-3 or SHAKE defined by [FIPS202],
	<t>The field mapping and all values are illustrated in <xref target="v8f		or even algorithms that have not been defined yet.
	ieldssha256"/>.
	Finally to further illustrate the bit swapping for version and variant and the u		Perhaps A:
	nused/discarded part of the SHA-256 value see <xref target="v8vervar"/>.		These MAY leverage newer hashing algorithms such as SHA-256
	An important note for secure hashing algorithms that produce outputs of an arbit		or SHA-512 (as defined by [FIPS180-4]), SHA-3 or SHAKE (as defined by
	rary size, such as those found in SHAKE, the output hash <bcp14>MUST</bcp14> be		[FIPS202]), or even algorithms that have not been defined yet.
	128 bits or larger.</t>
			Perhaps B:
			These MAY leverage newer hashing algorithms, such as:
			-SHA-256 or SHA-512 (defined by [FIPS180-4]),
			-SHA-3 or SHAKE (defined by [FIPS202]), or
			-algorithms that have not yet been defined.
			-->
			These <bcp14>MAY</bcp14> leverage newer hashing algorithms such as
			SHA-256 or SHA-512 (as defined by <xref target="FIPS180-4"/>), SHA-3
			or SHAKE (as defined by <xref target="FIPS202"/>), or even algorithms
			that have not been defined yet.</t>
			<!--[rfced] May we update this text for accuracy?
			Original:
			A SHA-256 version of Appendix A.4 is detailed in Figure 28 as an
			illustrative example detailing how this can be achieved.
			Perhaps:
			A SHA-256 version of the SHA-1 computation in Appendix A.4 is
			detailed in Figure 28 as an illustrative example detailing how this
			can be achieved.
			-->
			<t>A SHA-256 version of the SHA-1 computation in <xref target="uuidv5_ex
			ample"/> is detailed in
			<xref target="v8sha256"/> as an illustrative example detailing how
			this can be achieved. The creation of the name-based UUIDv8 value in
			this section follows the same logic defined in <xref target="uuidv5"/>
			with the difference being SHA-256 in place of SHA-1.</t>
			<t>The field mapping and all values are illustrated in <xref
			target="v8fieldssha256"/>. Finally, to further illustrate the bit
			swapping for version and variant and the unused/discarded part of the
			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 3322 ¶
	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>
			<section anchor="Acknowledgements" toc="default" numbered="false">
			<name>Acknowledgements</name>
			<t>The authors gratefully acknowledge the contributions of <contact
			fullname="Rich Salz"/>, <contact fullname="Michael Mealling"/>, <contact
			fullname="Ben Campbell"/>, <contact fullname="Ben Ramsey"/>, <contact
			fullname="Fabio Lima"/>, <contact fullname="Gonzalo Salgueiro"/>,
			<contact fullname="Martin Thomson"/>, <contact fullname="Murray
			S. Kucherawy"/>, <contact fullname="Rick van Rein"/>, <contact
			fullname="Rob Wilton"/>, <contact fullname="Sean Leonard"/>, <contact
			fullname="Theodore Y. Ts'o"/>, <contact fullname="Robert Kieffer"/>,
			<contact fullname="Sergey Prokhorenko"/>, and <contact
			fullname="LiosK"/>.</t>
			<t>As well as all of those in the IETF community and on GitHub to who
			contributed to the discussions that resulted in this document.</t>
			<!--[rfced] Will the reader easily know to which section "the byte
			ordering section" refers? Or would a pointer to the section's
			title be preferable?
			Original:
			This document draws heavily on the OSF DCE specification for UUIDs.
			Ted Ts'o provided helpful comments, especially on the byte ordering
			section which we mostly plagiarized from a proposed wording he
			supplied (all errors in that section are our responsibility,
			however).
			-->
			<t>This document draws heavily on the OSF DCE specification (Appendix A of
			<xref target="C309" format="default"/>) for UUIDs.
			<contact fullname="Ted Ts'o"/> provided helpful comments.</t>
			<t>We are also grateful to the careful reading and bit-twiddling of
			<contact fullname="Ralf S. Engelschall"/>, <contact fullname="John
			Larmouth"/>, and <contact fullname="Paul Thorpe"/>. <contact
			fullname="Professor Larmouth"/> was also invaluable in achieving
			coordination with ISO/IEC.</t>
			</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+y96XIbWZYm+J9mfAdv0qZFVgMgAIJrdlYWRUkRrAwtLVKZ
	WTY9I3MADtJTgDvK3cElFBrrd5hf82+eZR6ln2TOd5Z7rzsAioqMyKzqLEWY
	RALudzn33LMv7XZ7c+P2NNrf3BjnoyyeJafRuIgnVTtNqkl7sUjHRXLbLiaj
	Qa/fH6ZluzfY3BjF1WlUVuPNjXxY5tOkSsrT6BmeeEZf5lmZZOUCH1XFIqGP
	ysVwlpZlmmfVw5xmuHh59WpzY56ebm5ENE6Rjmi8Zw9J+QwfVPmo/ts4mVc3
	9NE+f1A+zIpkUgaPlHlRBR9F21E8GqXjJKvi6fQhGuVFkYyqNLt2n0en7d3N
	jSqtprSaD1l6mxQlP0s//+siiS5e0EPpJKWPo50PHy5e0NPxcEigoMfpV/qt
	SOLT6Oz91ebG3fVppIDa3Ph0J78QPOOKBu93+wRben5R3eQFbbgdCZR///Bj
	UkTvO9GL+DYtsY1kFqfT0+jTwxif/NMoLUd5Z5TP8F1e0CTn+CS6fCirZFb6
	kZ4X8Tj6rhO9S+JhPn4IhhrSN/80l487ae4G+pCNpvlijCHSjMD2rhP9kMSj
	GzwgY4af6GDzP0+P/mlx10nGi2AgBl1aPUT5JPpjXN4QlKs8w46zvJjFFX3P
	p3y+3z3hH+hE4+I6oQO/qap5ebq3N18My04+T7LrIl/MOzTwXp5N0yzBF3sn
	h/TfyUn35GSPUKEzH090FDm8rRfnL0+j98ksr5LoXZGPaHlFEp3TaW7JgwVh
	01saPfoOw0fnZy+jy3kyotMlNCaU5KXJo2VSpEmZZpNclxpFF5fP35xGvfbx
	wUmv3+4Oeu0D+UqO92xxvSirqHdyMsDHfzo8PDp9ZKy3excvzwlNT473B+3j
	0363O3jmvr360L6inYw6p9GfOjRQbZ//6B6jERmwtPKrZHST5dP8+qEVbbnN
	lxE9EVU3ib1CsC3kBTqkt5cXNMl1StdOPjtjzEyrFJf4uySzZ+NsbAMU4fM0
	xqobM27cmHIXI2AZaWHjLMokisvo7PJNpxe9Hf6ZbmXwIl3U2TzP6NdyK4Qx
	oITf3786P+4Neqf2Az57dfHusnfcbQ/W4FZ2O2X0ymj9nev8dg8/MF7hzb03
	F5dXHfzU4UGWsOsyGQGbvifEji4r2k9cKFDcfcYvbbkNbxhA8ZTOqKQBFoSR
	BCx7r2R4+CNbgUb9bu9gLfZgmXQxPzyPeK22eyIwf+neaYjle3X5/Vl73y2e
	Jk6K2aLiHbafx2UyFqhgTy/vq4SeGk6T9tsFzVBFrxbZCE/aQf4toUW7EwLU
	6/18AnRM/60nQFGv0zvliwRcHrn7I/gD6niZFLfpKCmfTpN6vXDLRGCOQFRT
	u/1KVukq9Pb7cifwg312tH98aj/oZ4Pu8eGp/WCfEcs+tR/0s4P+/uDUftDP
	DnsHMgd+cJ+dDE7tB/3sqDuQ8fCDu7P9w1P7wT4bnJyc2g/22cn+0an9wMT0
	oNt9EjE9OBm0e2voKI3xdTpaOTSL/uf/+L/lZJTN0nNVUpBMkyWM0fzA1U0S
	vUghVOTFA53kLU43uQP+0pMjElfKVjTLx8lU0LjU069Ttd6Jsoyn7RIsY90u
	aYxv3uUyv6gzilzoc+rpc40NxMtsYxrN/ZhM/PN5FBejEsNh/BSwzOzeL09A
	UlzSgFFPYHT8JBgdH/cJRsRW+2sBdfwEQHmqQ7TqbIgt0zovH0ievI/e5EIE
	o7dZEu0wK9uN/rPytCQb5WMImsVi2jxuuZw/JPd0x6fgkGuo0XVa3SyGEPz2
	qru0Ioi1CYY3dOP3RjEJ0UltA2fRJQ0XR6NpCrkWJ3lOTxH0i3g97b2SgRuw
	7reN6KyAMq1nltIyJ4fjeJAwFC+z/G4yjT8l376T0l7dK5JpQuyk3Kvia/9x
	m5az5qTcrFFKWBZlSXWXF5/sjjEErlWKoYNYmEAfZYvZENJJXEU36fWNDVcS
	+JKIlndDesQsicp0NqcPrhdxERO6JmXnW8E4aHfX86VzBeNwf3IY74+Yiz8N
	hMN8Ac74sMebr8HmmQxByDBORoQGdBXTH5NxK/rUzotxUhCzTscOKoS7Bqw0
	i14W0zi7frZ+k8913sYuj9rCVx/dZe9gdLK/z4h4eUNcnU5kLd6TJkIoUMSz
	NjFiYr40anbNOy/11XY6Ltsxqabuyd5ochAf9ZKD+GBUF9z0FbqZJIrizC/s
	pfU7dY9EL/0Klu8Ib/v3l0+6wWVyPQN5y/c+lawVBmv8ffuSFFeITdF303xY
	1z/L9cu8lDEb1KXb7h59Hesm+0eHMT/3chqT2DV64v2dkxZZjB72kuCthqRM
	66aNEl0HbYv2BK1x8RTv6F7OF9Mp4WJOEiJxBB2rxMg3TF+gOK7Ytaqk8WIK
	HZeW0TiTg3Z3Pd2yrY/HR72R0GBe2VNO76r97o+/l/tGuEf7qG3ZbfA72+Aj
	q7/KZ7SDO3pl+dwGX138ZDQ+jPsseF7m2cMTD62kR/mv5eMiSgFWng5J7B4H
	RNKfFV2yeQrKMXwwOves9MT3EfSkCZf3ePzVPR4PjseHhwwLJVof6MasIxZV
	ltxXHbpXU6LTt8m0TfJFewaZrUjzRWl0jy1Y7f5JckSC4HAwOa7TzR/k5VOW
	6Pzb0dZbJZvA5a3VxFHO9aKKp3n0PE5+jInxDovE2G64eca687evn3/3JKJR
	pCOQL1iv6Ertvb/qEIyGtZWfF4nwt9LfOwxegqSfbzMXfH15+d9+IFhG7/Ky
	ui6Sy3+dPrKR9zJpdCWzLm2i93Vq/6x/dHBy3O8yvD788JStLqbpeK8k1ae2
	uxX2BZabciLO8xvIT/SFI57egvDI9s6II8YEm1dE1YnsNA6pd/IUnj3ujo56
	RyL6PGVzJOpMq3KvbND9Z/RBdGpXLWHzJW/ES8LlYyh3RrIdKRvnGN0oZriR
	w69uhNSF5GTAbGC+KG/W7mVCBGBIwlnnOs+vp8mQRGLeGGjuXre/hzvX7xFy
	3MUPZbvK27D7Fklb6MnHw+POTTWb1jaPi9b/P+md6I/0DmkIxGvxzgo70noS
	8x0vZ5kLMIr+6UlXrNy7bxzLMg9+EmF/O01vobu8y1NSX5Ypn4mxjxxHMokP
	j46ZuotRbO0Oxvmo7BCbvM7Hso9ZnC3iKQnREyJXpHnuzRJa43hPxxnv1bZo
	n9LiX2OQF8+j1zzAelDrc+G2JvG0TKLt6E9/+lM0uklGzNHOn0TZCAajZDpN
	86raGzXlofOcvoGToE36I3EnEr/pSpDyOK/SGeRZpmpQOn/MYdpn0Z2t+qRq
	kubKChzBYLXALqf1khZAog+v4OccVb93MOwfMS2+ePny5dHBOsNjaXasTpok
	CduU8MMevbF32O916weDsZzpi7f5apozgW8TXhEczkjTvqGzTUePqCMYZZkc
	rJcKL/mj04jW1DZzxIf3b94QpMp5PKKvVu/t7u6uk8ZZzLuCSnqdQSAt9xZF
	1s7c241fO/dLxIBuGg6NtPMyXxSkj/DU0Q4tYjfyy3hkx2dvzhrHCCW23WM+
	/+6B3sgeu0pzfoL3sb83TYcF9CuIDMuEi6VaMVmU8CPlol8QAXv/6nz9CmUN
	jTXuE7dpwy8URa/TUZGX+aRas0xSjousM7On5BZl7UW5B4MlOGe5d5dm4/yu
	/Dgv8iof5dNyb1a2x9XDfC8+PEzGybDXPujH3fZgfDhoxyf7w3Z/cjA63t8f
	H41P+rVdjhYFUUCCw4iuGwQKds+ZFrSSQNjSlvdIirDs8fIjCT8fHxF+xskt
	mEvZ2Gg+HWfJXQWn0h6OtnvSP253u3u/m/+21z3q93u1tf/x5iEa54Q/NFmU
	3M+JipReKIqjWXoPtWOYXhOfGhMCM+GYkmg7TfST3/Egozj7n//j/yHiU0V/
	hqF5no4+0fvEthMx51X4gE0GafW7x2Sq+IGI9ZhYddJEgX67e9LuM5pePH/9
	8c355WOXbThjeABn6fT34vR+76jT+12V09J+uxAhl+SJNpQoWmE7G5U10OCB
	j/QA0zFsYYcm3H3kXj1/vXyc+4qy78/evHj7ep0tPSEZOl/MRx0l+ySiFzRj
	Plu+Ulvv+YvoDVtmPLeFtY7WCZ8COxGYIJ7N51O1jq/xKqiaiAVEb0ejdNrc
	Agzo7XY7itWkh9+vbtIyKmu293EyIeW/ZIsle7KIID3qInaeLiESK6maEjVH
	Djs6dEyiD/HTPPpEmlUG75hg7M6yOOLnIx5wJnPR4nv9Y8JpIkrTXHlhWrKl
	NRsnMMF6U9bmhghmGS5GjIuGrdNiZP3pjFaly7ojcYJQIb1OM17EAg4fukXs
	VTybE6fOozdqeSOcmi9YGRGbuVyrGMcgb6hBnW71HW13c+MVW5QAa9Iod95e
	vtqNXgTaqB/vZXabFjkzl2jnxfnL3ZZBOoMrxNOe6I9CAqM5zQvgw2q38nDp
	A9Ls6DSJzRaEe1gePDj1p/hu814/pSJcaPyCWbJp0dEOnZg/tivbJ7t0cESh
	SZnnIlI+hajILnPgtQ62PP8NaaXRMJFtEquZ59AUcAJ0nhV2RaRgAbh0oqvw
	18gFZJhXp2NYP0vHYwjNmxvbcGoU+XghHo3P28/j0Sf4vrLxl/9V70RBenIK
	v0SWR2oi3dyoOTTYd1Ea4iTsrIavWxhISRyF5PtZQrMTOtzGJe0e+D0ybKW7
	Q6898AdFWhKksXs6vFCxozcm0D8Lgj20HlA2IsgP5nqBRm/xHeVidIPNL2M5
	NhQH9DCyRzHj6/zHdDqNoz8mQ2Lk9DjNylSBkImnGsHc3iL0GsHeTYwy18vN
	32Ykf5vwGkGvW3eT4oqWOa9Yh7MXSEqnNcTEMkFfYWGOIb8nGUEtpi3RVGUK
	VVcWREyVZpA3wuGGRKImxH2xHUCOAMVuuCypOnI4aXC3bkCraHmzBBoDv04D
	wxFHp0DUD2xbPFy0UbraHKRCp5NHbOrna2MeOjp1nIEcekJUQIgYQWqYZgFt
	IMQto8+fNRLhyxeYWXI8TcMnhkKyLJIznA8q4GpyiJl5r7z0//kzokhoSAEL
	CGaNYvGsuNlfvhDKPc/huEgqEBNCmfCESk9G6DqRkJ6MZVLg3QLXiD2CYk5B
	3NZsTu/R6dD63+QsdQkBD+lLeZMvpmOAGHFeiO9iHpMTKSgAaEfPnB+ftyH0
	Q+xpglHbhKhVehsrCZq5X5gEwbmm1HEGs02RxKVJAuERpTq+v9VQFC3cCp53
	ekLvPi80Hs9SxEEk7PGcRTvxlJ5cXBO5v8sjQSpCJcLKaUJ7iq8T1j/hsCSK
	DjXtuNun6cY1c01LDh9wou+qXTqYMziniOAsplUrcL1sbjA1ZSGM5EwBJNCw
	AmWhZeczpvT4npkudhxHtzGpahxlRZdoUeDKlkJwhOYFvp14ep2ztkjTlCNi
	qjQI42K5mBMfod3Rvui84QSjh6e53mdwGGZJvS7xCqjIGSgdIdcoFx5IYBkR
	VkAwiGZM12g1WQKqSXpTKypzOYxKyCDwhGDIe+StgECRJFLGwncMEzzRp8nj
	aJLe07MlSMmO0XFi/Hc3KdE4Pk2gQjwkcJUzWr9irp4vnwNtSx3Ntwomem9K
	N48QpiqT6YTkm+mUCRcBhLCpRccCiy9+ZNDfSCgbr4iexGN0yCUJp3or6BLH
	QyGk4jEknHOwlDHg1sQAxFjgVJrpm3JUU976JXH3JOB6aohXgwaMIIRiLQHo
	DN6G5B72E1xE5aibG3XlWZHCBhqmU1wCSIFmboTL9E6wBqQMzph4NStk7LiT
	SydrFOKa+8vJdNBLS/R4QgoTbZVZ2SgvK7ns29GHOQTx4NLj89fgOExplFiN
	buLs2omaLJMSfD2QmnLpCHbwZEyTvKYrWWR1tshDYr+CG/KwXK0qBaUw0Avn
	JLY9Y0dnwK+b1y8apxO2tUE9RHyIigDT5F5FAQtvUD7eYhFuumBrAQm4oA+k
	dM7SShZliBR9Sh4ImSYpcUeWiFrhdZPB6LbJN8w+g4g7rBJXrWqPwSmy8J7J
	JQNBRcwq1itXSbbOILqOmTjP8/liGhvVrC2sYyIA79lJzrQzXEfaGp1F6FGi
	u7eQCz1bPheWjUVmUVlkC4RPRgOX2YrKERFnJkd0A4R6DB/8pVM6G0H/2NzA
	ZW7ZISYTAkZVo/mjnI01bGv37pKMGBqsgSEcRSmiq+zCCkCjsUNYRURgiukU
	iVZkKolMEBvCZE8AqkSdl+xxTu5jq0a8brDO23i6gIULJCWAnyKPu6GyHblT
	uhlcVNCEUhhZHF3nOTifJ30txje+6U7l6LUPjJY275LxaAJ0IGO0SJUbERyS
	ogIjFvpKnCUt2GcBpxFBgCDJvtxT4NrmRq8TvSE5EtfXRSDU12ESKz69HUQ7
	nlfRJJ8/w2BxO/jyZVcQdE6b9ghJUnByD+Ue9Bb0jW2ijJ+QAU0kICon0DUq
	gaFpXpA2ZpS0fSDRaAq5kM4KAc+6wZTtNYLiNJkqMwsnS8A9mhQmrZr1GTyO
	zoqtGrY+w3ihyyIQ4Byz5JoPKbRcA3nZvphn6g+PnKpQOnFAVkab3XneRsSU
	UAPwdbq7JAKT7qVIOCa2E4vNmM8EK+h1u+0sznJl698R4c/xWpTMc9q+Kfp8
	Lr3V59LDueBsScibzVkIW2Tef4/lgEqmI9oqAFQksMWBZMaj0QJMiC0KbLp3
	gqLG56gIxvjBg0HMVlM7Cby6EdZfIewCunvE/HmwhqjHiAdsFi7CN3+UtEQl
	EaWn4pj4YcJLATrTa3oebPDjUKDhQ5W0hw9t/BuJrJHSJba1vCOKG48eeNs+
	GEnjPtOyBALijUTIpu379dk5CaNjNlKaYSUSwZJoEYlOqnvalYl6jEQvVV0L
	Xk/qRCdmlYPUKVzbclFMYOChfTEyJm6JHIs3MfO6qMi3CdFFYBF84HwR8F2o
	a8VDUCO+vMqdCA0hUc+YhMAdBYJI+Fq06NZWQmvpGzfaOCE6MiV9PTobj1Ph
	lVMSHk2IoF3dsiFjEt2mRbWgFbmZWGiG74d+K8BZoxoYA+tWyoo+tH9CAWcA
	G9uZsdxhQYmmBJqlg9dnyq4hvqOH9OttPoU2Rjx2zIeWTyal09YIwKI2Ol0X
	YiYP9iDSBMmTNSklkyvtBGlGQjbPaMQk2wbYQVxbamm7CVc3TsdM1MBMCNEW
	pO0SZlR3UAIrJkB8Qdhf04yVizW3JYqU3oEu4hm+CA9O/CX5rxV5vQnCqUjv
	4NVOPuLVvVjw/vlcaaREgqHAZeRmtMTocEdMuCFBOGofworYG9sWi+va53RH
	iOQWKs2UWFYl0j0dlIp2OQFwxhG6GjoBLk+Q4fg9ZlSYbdzy7niVoRvCoOYw
	xDX5SK1wN7BxTIX6sHiBe9Q4NNI0bkX5jOYxUke6/yV6SIiC8WrZpURflTCP
	2aLBtkh/v6kYRCZ+OtvMH28gMxKJBWHi95u2GtYgaPUQ5/FE7zAUY5vrY7kg
	pmv5YD5X4jKsOxEK5XC8ElUiHeS6umlBO6PzeCCqQIKCxLYqCQeM9ywgtiUw
	ZoYRIQms5RmIPh9+InxiRGRBCCI/sOfzQ1pQ+tRbTFDPxlOnuc3AX9vBZPDV
	1EIfmQ/Q8yqrfD5lIzh98Nstpu6jauuL3isEsdClIh5y1glCR/i7IJJXHnHR
	oPy1i5Ra9eUr/4UPr5TXXJikfB2ELfL3HHcoX7k4QP4ijOeT7991XLicn9Qt
	tuPC0WReCxPTsTmIi78JgrF0SfSuC3XiRyy0Sb5/3/FBRDJ2AEQXtcLfSPSJ
	fGlBHfzFn+zTtx0fWcHfWISEfO3CE2Qdbg0vO97Lv7lxlnE4m0bwC90vl8ip
	s1gr0/aiD3E9oiPh7a4bxdQ2wT6XUqxM8bxyerZ+JExKp+Yp+Pq+WhTgF606
	k1EzRcy3jhVYYuqgHDcIgwzGi01wwrbgD/Sy9Qpts0YHTo0bpiWsCnGWgF4l
	Bd2UuKSPSXuHTYodA8FFJ4GZCI23Msrup0nMM8BfkanlYh3DekGy5wKilQjb
	dc2ApSQVP4NJzbjEwlFJe/qURFu45h9v0o90ch91gC3TDU3rH4LpaXjMmMUM
	Njxnpp8w2Vd7CFNSdj0Q7b1NWWff0rVgxi1RklKlJCPvnuSH9luqzwgp4p8P
	vJyIEZfkjSEMJmYuLw3azBWJUU3bJKyRMEgHlEEuMxmoyJAvx6pwPoTxWvQ2
	Ikll5UJiEA4AWrvuGNQkA5xwqBxglhNim0sUKQzu8CJw0LKtVpX9a+aRdHhz
	URvLurzacvY1Z6yEHU2S7UR9ghQnUBQcEdR+HJZloE7osYrtltfXgLsxSMyx
	B/PJPa015e81hBlK7nW2NCdbPiuA5JYTgFT0S6fTBRvQEj43swao5knQmCvX
	r3FmNYVfwcGoKSeftyv/2xe1nr0PxbYfYhLsAOPP26E493Gqn38xFxZJJjCR
	0HXZev3h8mqrJf9Gb97yz+9f/rcPF+9fvsDPl9+f/fCD+2FDn7j8/u2HH174
	n/ybRPJfv3zzQl6mT6PaRxtbr8/+ZUvOb+vtu6uLt2/Oftha9iZAbJQryoIu
	yTACrI2a2vn8/N3/9//2BkQg/xNRyH6vd0IUUn457h2RWkgXN1Gjaw5Xk/wK
	wXQj5sh19jWR3D2K5ymdb8lKYHkD7yJM452NjX/43wGZ/+M0+q/D0bw3+Ef9
	ABuufWgwq33IMFv+ZOllAeKKj1ZM46BZ+7wB6fp6z/6l9rvBPfjwv/4OaY1R
	u3f8u3/cUNQ647z2VG/Q523YwLKHWemwyMuNce1RNli7uIDgWE9VrILpJKt+
	u9UbQKAS3WJ1un0QwSsP3va++mj0B1OM3Uv9p7/Udy/tP/2lfffS4OkvDdxL
	B09/6cC9dPj0lw7dS0dPf+nIvXT89JeORXT+8P6NvrMijI8Fr+dvXuGJswWL
	qoQrCDVYlO038aKIXrH/YnPj/PLd+zff4bnz4mFe1aO8hSm8K5PFOG+vCRhi
	V8LZOUZ4nYzTODpjI190nsNONOWvL5/z1yTTRJdE1pkCEwV6nrKE+OL560t8
	/8KUutekAF2Lb/hSbe/i/8NTtYzll1NiAwUrPpwMzb/mGQQxSyMienORiRXu
	4uqDjBBmQl4lU/YNLzJTaAmk6iF5cSDbKktQ/BfpNTgPowfRGHwV5qifGTvV
	79u9tU9EPTG5zHTksYwM/99hl51uNka/P1g/Sn/lKOy9o6Ho1fpQB4c/e6iD
	w9pQB73+zx2KXq0Ntb9+oH195vcvH3kmUlkji37/8vz87PdequFLcsWIee6c
	EGN/yaIrkjjYPSO0cakmgtLoc3aLkUBA9HlkP38BkSXeT1pBmhWTERNsKd7S
	Gzyi2bajsxd0VzljebsvQbTR5WLIouJrUte9aL/N6Q7NFy7VmvUHsa5DuPqD
	mJ73bJjzfLqYZXi/t/z+d/CGElOWnUSxBXqwzfOg08NrfbxGgOc7hdtyLeRn
	mOJAGxoIPT/A8y9IkZnGBFJm+Fk63ZvF984nXSamGkwgC3AsFSrROLs5xjnA
	OK/S++i2t3d7SNpGZuIguJyX+vDsYQDw/UcBDvEN7zKotfrGAw0xkGWrsBN6
	4+l8STYleLgwaFhdtnuHDM/X0EdHaeWStfmpeC5PLeYQqiZpQTNyrmQmqZ63
	+3u3BxjjiDcpemfEdVrYGeqnujVA08OHBpErZ1OhCfGL1oEQ5hG9vI/ZXE6v
	8K4EZy2hn89Riw9gdRe+kAEBRNUznMDhvp3kooRu+aDLhrQxjMUe5aj0h1IW
	eXAQHEX/0aO4epjnmGdwjPd4c5cvz19cvHcYyqVFmp/28Tkj5dt3l/WnGWUu
	3jQf5otz8fLyO4fv9OGhYMMt3AG9wzb0W2hGb2Dlss0MTvjKjMcRMa19AEtv
	V3TFdkla9r4+ofbzZec6dnjAx/zyfg7Q0wFdeW3XzgpuARhTi8D2Ri+e2JEL
	v+XcC14i+9OeldFsBNMlVk9odUYidjamp7e5OASdPN/OB9ILYkOSLYnUUcMm
	Cd9bIKL2Hb04cGhdR6fSskWvcH/+oBoXvcDgvYRSh6n0JR60vkWC51GAHL1H
	keONuwtb8LRLdOwWwLTlohS34GkvHu44pma7t89Q1ouN0z/1ZIreW8jJqGXH
	WyKwh325/W8Yn4qkXej7z9kqTWQB/thoK4Z7J+c4LefF4gINoyqpSkBvn9Hq
	HL5rQu7qlJFcj6bI71OEFAkR88dMo40WU4cs+4rFVzXc3j8JQNd9nKe8v6L/
	7VWg3KskGQ/hhKJxuiFeSDkdpWkw5ZSs9ak7lgtRQIsT3Z0X17cbkXjEDezH
	ix9/hHpCD+779XZPHl3vDxwKolcI4GRW4M5HKimwYMohhExDt3v9/eDI7LyZ
	pPwnfNtf8S39CkE0NJfodaUX+L68LApOuDUs5msjWBxgPR7ni3kxg3FKAvDY
	zjZiX5baycR56M1UgF//OADL8aNgwa2vlET29u0TsQlGh/3+QbQTI1xkF98f
	4a/jGoM/hbYekbIO7s2qLT0yaDyCk5yzWyu8EHSmtz3GHGK89NZh4633LOrY
	sKkzwEUDbLEbso2tCUngVXuax4iBL6DA3nKBqQXk7i0+3P0+k19xe7O4+A7o
	QHgkOXRYQsBWukePwI1PEXE3bBy6Vnpf3SXxJ0aM7onQfd7AIvOuvq19FkW3
	3OkfORSnt44DProlcXEcmSe++62o/Y/RVvABh8gkk3gxpQGLZCpePYCVD6qr
	vCcpiOmQXMQEgXBNrk6X6ZgUA9M5y2D3h1/Z/Wts3Bgd6WCV7JsvxBXggEWI
	VUdMcgh9StrJbH4Ti1yuUZZBFTAMwCioBNHox7kEgUTQLvEMo5eXDQVe9P1h
	B4y4Gx7iwVe2ca7xZw4+tMzwZ3EYasQXa4c/AMrRm3TqzNi8jE60fcIk9QyR
	t6S/MUoRN0/uK+/rVkVELPQizG2fMN6/RrSfqtt7FgIw4lCrKDCwaxbHgYTO
	02JAAwhwJ3ya5ymEgktOiOJkrris5zvJIh10HtMaAgRGJHyshsXt436L/joW
	69v2CZ/XO5T/WvgwZ1gzi6isHqYJh3fitVBGZJs33zwIGUTLFFwDaFw8Ch/l
	STfaYe/A9vHhrnEEAJywJkQthA4chT4/OriDzpHCyBk+aMBesKv3xIBN3CEN
	raITfZ0TQwLnjXbsAHfFP+G+gX0cWzwX0gLQ941qxrNher2AT4VPXU37YtVB
	1BHiM4yfbx+fOAlIzobjGIjBVYJnPK3S+Cp3YTIKn+3jg1Cmn7EWx54rrV4E
	bzgcxCwJvH8j9nTvawn9GtvHcohi74ZLDEFGTNn4UZ06MQFNn6fDwMPY6USX
	IWraA07WobBEjaPuk3cbqAIWGhKXVlEf0+wkGIGjwPauOTeEZdLbUrzATkjl
	sRyWP6aqefF8LDJdg3Nviz6L092Cyfq6kEhCriwUyGRegRJl6wrxmIjccVRX
	c1txMARNjcdk0Ui/2D5Sgm0SCZTWuumhJCpzeFIXXFlnDuy0LqZ9WzQ53Blx
	qchYNZPu9uFBcCOAJxLqiXw9WtC+Q9FzsVYR8jcAxKpdkFy0fXjsXuL6Sm+W
	1b6mPrgt2jzckkEsgRL2mjP14sWbi6vLaKKSJosA+V12jcicyOz3eMGb2SXo
	ZQH+q8HRLslnW7R/zNtRRHazt1gqMup1dNx4sGmQODrxD8jce7yceIyMUnHj
	bB/zATvWADIywNbEbzlzxMdf8l6Axo+puQFtnY0PPnKoP10utgi64UASbuLe
	x1lKhFt0PmeJIH625/geTAd6QyvVQA9DamN8WTMxsrYRY4nesOB2icPBoSNA
	T4WsRtwrzxcUId1WZdhUzOetkPtlKrwchFg7XkhcUCLyASMwX+WGz3JblH9P
	40UMP0dFA+ZFyPjjQM07dppsiz7Ngo6r69jA/vfOdxlt9w/VhAWr5/LGRIFV
	7ZzJFWLIQejEwa2Oai8Rg5DVxPrBvihVCfFxmHyAhypGqk/yRY5ydWZOfOAT
	+B4W8O3DXmCICNdGELisOBPEYd0gtCMs5kiBunlAdNS9Cs9OvuaoO2J0LnJp
	2wxcyG+JLkWwPQdSeKPBYT9A6sfUc7lRABELgJdzVJKgA0r43LZVESHytvUU
	EMQlJ4FsBSof80g92Cay9BgP34ot4t0UumuYs8qIziewLZqIcfiPxOElNBRP
	LNjEI3IBZtnuKzu5hl25zw/uq7GNSa5olEw9vXWuVr73ikToKbvx89UcS1RW
	knqwfbkSnqayLkfQ0HKf9DQf2PMFqdX8bA069FSkjwmlhJjxANtSQF8hMRvl
	3e4fBTdzy8dbbKkgEKcm2piAcCzouC267qu6JAG5zhRcL++R9ncQbYuNAbr4
	qRMbBx2STk3ge4UXW4IdMqfKG1v0stwlCdZXIZ/3Xwtf/j65hwcGEsU+L+95
	Ac3meZpBl2MfmEXtSqbuXR6BdoBPiz2QT5KFBGUwWIbXYwUD+RfakdghgdE0
	9B1ipGunoXEpLtJkwCReXydxWcyVoGoS2FN7mV5Exmcoxm6LJRPz/RAPE47j
	i7bW0cetCNIku+pYHi1gL+OcHZYst83UySfPiXP+ed71FmLJLT1Q7PJpeEtv
	6JbSyQz4WptmaZapg5BoPG6Yep0U194Ax6qXvKeF0dvEf+aQwNpE6aWUglwQ
	0oc6s7FnpaeBxKLldvVSHJrhc9Vz/d7AnjtW0/Lq53Cx5DmpvLvqOZQ15vrP
	PKT7bcBnpQ4//x6RAmj7ZqPv1YVNIlGGbHwgLwCVqFub+apIZ0hrGCNUAqei
	REFvhCZy+edRBoLo6rBMK5HUuC5EhCiV21hCAhkl4yo+jZ7H47oQyAWLD7rR
	f/8p2j8kqG0PwsdVoHn94sBm4KQNUUNQH4PfGxwdEk+Jds4QxfWKxTUbAHSV
	K2FIVM5HiEbY+UfYdnd28Xpv/4BuTn83nNeMqSNQcEnhrfDs4eEhvCm98FlM
	8fzsRfQWyrYEUvCjMJxtn4RPXmTalyB6FyMO9wY1j5RBePK1z4s6Jop7EL68
	uhoaCPo7d8mwFLw86B8TuWouctDp0eA1kqDp6rwmtkrg7ZMD2I6WXq/TEq++
	CWk7xquDkyPa81HtzQY13y/Ge1NT0ohymp+DY87nyQjDHBwcdknybS7AMVcL
	/wNCchjcjOhGuwxc/KwSmj4mC4N9sVtDxbqFyZIkOOVD8kgQU+S2LbYKdinX
	5mGY7R8MML7YguVOHdAMnX7HOSU40VXtfexFZVaxRYCUICmVstWo6cZgvuq2
	Qg++T6ZpoMYcsu9UZAr/lkF9jPYRC05pDnKlraqzJCc8Iot3WM+EIbYm98vM
	dAsJa+T0Y40WhRkmLvZurQ6IRqW7YZ6zBWSccnhzPZK8Fl7nwisHP//V/Z//
	6oF7lV1yRH3WSf/uUrRCpuBeFe3rqS+fDCQ0kE/hlZhcPm8LZ3KhWaE9BmUv
	DtUAEWROs6GcDvo3NUsL4yrTtOzPWqvfWyVVFNvc4KdqoXj4GpU3ffDrOJFw
	RVj2EJTqEtY6kSQmjMUmbzn7zh4hmRwC+aZuU1ZxgZIQUVcyqTNOrOv1jzRE
	VxDtCW9I9O2FLDweluY7S+6hJNKsYRYJKtQGfC2yelqNugqeVuISIfGdEwdF
	LkWhEOQ8aKixVuQoK+R6B1FHoCvioN9xRU6Wic6uJInHt77gAWzQXtyUYx8j
	IXv4EKQ2sK1IFUk6taDklbxF436f3yWaiKJ1KrTcyii+TWJNaXWlR56VXJaH
	7fIWpYKM62m0c/729a4WaHElE+pGZiadpeziOy0AAew1zLCY/BS5fkGxMMTB
	s/+3tMoSRMDmiXt4OZJWYPT67F8k6ltPU+JvFWxI24nY3cYxJVjLH7G+lNOM
	g+oeSNUqnVYdZiHB1v0QXXOiNaO0FMWg+1KfdCiC7NZNct9GVa5xXN5saUE1
	Oz61ZmitAbMDbG5wKwo2KS7m8JOxnfMuKUacEjWdkyyk+cs0ejwmQMzgO7Fs
	3NJZe3kZnKFNAKcFJOXezcOcdux2zjGcIhe7/Oo5F2UXogSc+/zZvvtY14w1
	J1PiRGGDDC3JViTA15FriI4437lZeBVcPtx0B8LmruRFQCTWuf4v+kN3OZvI
	eXMpw99GA4LDWyYLW+0tq3DIf/q/6DeH9s3mhnvmt9H3L//04uI7/Wdzg/66
	uJJ1/W/3+902tEV9BJ/J13vR1tkW/n7Of5/z3y/475f896st2Sw2/SavEhfJ
	JAgwRDnI8MhRtUSiiARpgCst/tWhTotrd7ARRb+VwHQH45bXIDv7DPCzzLkk
	GdySwMoXEJcDCZqNQ3XlASRvhlWG1OKtOZuy5PEuGSUkgcqd7ObG5Lg3Hkzi
	pH1EaN3u9cbddnx0eEB6XtwdnfSSw+Hk0J4lrW+7OZiYq3/7zIQt+SZkPs8c
	A+VwFG8QWLUySSv2txoB6UJKduxx+V0e321FH7JSqu1Y3Jp7UD/QJ6UaDygv
	LO3uIfrFHmim5EuxoQBWPfzp8h/8gP+68lmPP7Bf5C95zj3b7f73zQ33Dn8v
	H+tz+jx/bK/xszK4vrN8FB4czaNQwOErOQN5db9/ctztHu0fHJ4cHxwfHvZP
	+icHpACeHB0f9HoH3cPeUf8E9r3mTAE8m1MtHQI/tCNIKAmcSjTFfbMbLmhR
	ZKfQFE9/Hi7qCS4tiU7Zb10KRMEwLgXAWKS+06LIcvCqJCjW/kYcKM7vhlcl
	WxkYktAdJ8R4J4Q7C8hFWjrDLK7yTbwo2c2CuBurF8gBN44Sc7qMz/pGYxer
	OfQV++xlbvepkZrTCmqUSVrxItPUaimRShcNayEBwGQO1J64S4l65dJUypWs
	EVEgZKOtyNdYESbXghg2tcpmQVnTkvUYV2RL91zWROlQsLScXzPs8QIIkKTh
	80igItPkGhUAPn/WUp4gGvVsI83nBtppWnE4ny+9JcObHty954qlnz+zQmg3
	f3vbPcAmTVILVKz/yCKfI24m7JvFVAV1CcRTV3LAorl0EEuULSlH4HJyXJgp
	eIkgqikQjr+PkzlnP+byWZlUkmStE4TP19YlpbKAHC0kjEnZKHY2+2IRLFnB
	zgFJjtOH5d3fRHeQUbgwCYeNaTGTCDuVUhkGWtaRtThSHS4qgZWilPN3OAiX
	VSl1/FZr++bxjY5rgORL4g6NL1rpVAb2/enTtZWgLktSaN3AqRgktu5hEBiz
	PwvIs0Wy/rOqPaK7vyXRmDzZT9HrctiN+J+e/NOXf/bpH8OWn14ERvNf4M9P
	mJj+YGL6c0//3PPn9k+vfSQPvlfjTCui2xHBVcvm7NrhaE1AXGPaqguocQJK
	lk4XnIPccRP3Ijd/feLj9knrrP08+ik87lpFh0YRzW/csU6Mf7q1ic/bL5o7
	9uUbz7WQJ6d9roTB2oWsmLhXm/hl+1V9YiZckwWXYQpE8hqQnYfXAXkW3xuQ
	3cTga4LLxtAkjkaj5oWbXfhCFbyTFitNmaipWt3DxdlrSifpMBrtyTUORdQx
	dRT8yhfu4Fxm/RSJuNMHK/SYSS41V+yxHFVRm007hHnUlzBrnn1LbvLhgEFz
	eFBTWnb4OzEp9ILbviumuCHTOaxE3DBdTisM0azIEQ3epOFnVj4chU9AU2H/
	wABCkaYaxRXf5qlkpCsDkiQGrMkxgtC3BUYgvztGcOXNOUbRUkeHl2jaoEHV
	SLQRCAyOEQXE5T4OeiGEdkNa13e0jvnEJDQmWbBPqpzWLmUPPO6Rm/kE6qbb
	+yn6Zclbg7qt/Ed/+pCxDv0L/Xl04p6bGD/heH0Fp2Y6+7cSvNUT95o7Buxr
	VAb1Pp1ZU89br3xCKMcBLe/eXl78Sct/ftvEfsf7uuPMx0cbbq/fqkjBCxg1
	YLvVxPPOyol7a854oBNLfCBC04toLhmJ7iOrr/iUNXUen9jv+OAv3LGYnMM9
	r5546YwP+YytdNsvgWKPTux3fMTXKb2PXnJoyV+K0tES61x3j4+bWD0iNcmi
	I81m/U3TPzqx3/FJc+Ilpv1k8eTRiZtn3Ov+dSd2O+71fu2J19zj3hLl+nUn
	9jve/ytNvHTGg7/uxH7HB7/GxE4S7dck0Zos4eSNwHa27C0QoTUwbd5aqL2O
	Zdk0zveodmnR43gRmxuSA/bamwfLUORBM4KRBm9roHNoq28YTUlc6t4Pop3u
	EKa2Xal0hnfeLA2vS6wPHxTlneSLoPzc43OGsDvd3OjeH2MJMPbttmhBJ/pb
	j387k9968t1z/a236w1nZjxs818D/HVsv9qflU+dPOmpsyc99Xz5qXv90+a/
	XuOvN/ar/QnseAF20cmb/mwpiarxhMXQYW8be/u8KDhFgtrlzvbs1J/A9uVt
	BOY684XZysWwXT3MUUZNMUqSkxAHnZYz86IVifUi4sKbS96X1auQRjZuhrDC
	vdbiVrebjlL3vNXE8+167snnbbk7YobKI64Oicj0UZ5NFlJ5latIstLju0dZ
	xKt6sNk2jlZnCpEgiUDsUzKr7D7cduhSYjsvu9LUwVYPro1rVa1qnji+Q7oU
	zlNj6yq7uWQIwMg7BZxZckmnyjP19LpC2GESSo/ApTVV1Zvlyn2KT7YpAE0S
	VFaWao1Sp8EnQqKKd837uL7mQLTz4ep8V+DDWXFS+L3bRolpVxyWDYC3Maph
	cg3ubveU/+90uy2Q+LejKodK2Ts47kc7XEcq5qIYmxteZCwSDoxUp/n5DVcK
	juFnRkX2WJ3cFsyIqC3ZI9u7Glkyoh+7UvBWZPkmmc5FW97ccOHfGlooBkUp
	wMqOaLbD8bBgCqTlmilG9GIuyAD7t+C9RrBb8oFzdgaFWmsGxCxyTQK4Iolm
	KrRorQu2RFhoo8th4ALjTo2wVg9s21OjzCIL8xWcoXyRWWlKEJGaW0isUo0/
	vRWf9Vd8ts/v9+i7fdJ8DkgXOCLp+ORbPtvc+C/tv/A/FTPW/OHCb8SOvyIw
	/MKr4FmRLhHOEuHKRk6c15J01ze/7CqIbPuV+MjyYBXBH0bOXxkWK/4sT/ur
	nMhKLt1TExiuxvO0Um4knJoeveXI+d8+68onhj6nKLoiHpy4Qbf3+84Yhiur
	tJbDjNj/bUSXqzK/HY2IxSRlpPZCM5bt96IdZSLd9r5QOkMiN7c0ZkLw1s+d
	kNZqMw6O3IyD9oHMSPjpJhtYOCQzGSFgcVl3NNeNiF9aZuQk0ZQkwWint7ti
	DUsmQjUh+j3jUvA6LOuV6TN7+LSo82oOao+7sIJvAc2BB83hvgPNYftIQRN7
	0PQFNDXn0BJoao62EDS97orZa1ZltR3zvO4Gu9l7anxVUFgh4DoDXDXFodvg
	0Ynb4HH7RDaIO8lzDI4FaHA2SEu3ZnnjFYMfe1RG8J2N3uu2e4pbr1xzinoo
	P1diJhmD2HKcTsGgpBsBfc1fsY8LiZuCHK7HCbea04qKGQ0bSyH0q3MOVZF2
	XqU8PEaBZ3j4LB+MuSuvlpNkIbXyykjT1Gi3Vs0dXlhDJnQMEgknqIbNIiZt
	QBJvsVQpJM+uchQXNfEs+pEdGKgCnoiUdzF5RMrQEByUqPb9mWpPbG7sJJ3r
	TkuDHf1GuB7sHLE8KDc1mfh+eLUuQDBexRnOvmIXxaJILDcvbKPiLZYivfqC
	/lYT5gajiMo5lULeInr5zWFBtHY+vmwFwrKfRNy3kllPZ6HQmSPvFHkpMng+
	WfU6AY+jEuEbRo23f5FakdonJBn/xnfdgvdY05C8X8Ykqwi+YBCg9r8uuGVE
	3X4buFIvSVmh/cMzs1oEjPRwhsko5mLgQa+QYixVgvlMkfkydsXXrYj9bst8
	46v2GyyZzk8cNqZAWZOafBiEfMdBvuNYzkhqhZMkrJokwg7S+uHw/I7V2NL8
	2diRaA+7+hpJZ8tHaVxTe6xvj8GKEUxPruJ2jatwY+k4hUbI7Uc9f3H1OaF7
	BW5xPyLfw2Qn7SR0NrlWvGIqk04SubgTlHyXm4Sw6BSEkEPgQ0RRoFeB4uoS
	I6aa72K9M4XuWYMpF0oyi+/T2WLG8cMaTGd5doBP2F9IiSboHidKgZoSUEea
	I6XXHocqPxXxPB0zRK64NwnvQY/LZd0N/XJ91edGy7KOBRWWqo07tcU0ELxQ
	WinPdfE+b7NaqxoXwOqHC4r+wh3s2AErxooB0OM6q4bLchnIaVHxU30wHiI6
	/m8Ib5JvUqZqy5GGUap3ixAVtp6oVsmQrajATWyzRDPQjpSPbDmYw6uRnd5B
	Z6DCoZvO1cARDmndrGgVabFqeWKo/PYFRmdZ2EuNi3gFrcQCGVlvD0dXc/Fp
	GnKCGhi14n74UbdSg57vzWVyiifITZNJ30wm/abJpO/YBWSEmldS2N7nz+f7
	3RN35uf7PfXHWwASmzCaFrTS2oR9YzB6c+H7tvD95sL3ffvKRksOmVjyJbkC
	2RYoqXYaGRfxnUTbihygEp0Yt1oSLRjWLfOhNPTZRzYqfbTO0BrPrVYEyZmx
	9kmYywpZDx98x1OgKXyqHJqKdMgvtDE4G7lQPSxvHCKfhRUM5WLuyBqk0gUC
	XbldJ02Q1dkK95kCLUKYLr9KxHeCwKgh+l56+WnkMh2Zlj9WMK3VEOolmNC6
	VUJ2wliZWELpLSC4W2xLyvE3EzWsPRqgITuUcneZM1FJb7VKorNde9ow1kTM
	kJ0gscfQgwsAWAEGSUNj27+ad6Wxwa3G2H1FmVPUb+gxfNETn5zGGM3qwmIo
	pW6l/BB3GQrM14LOH/VNRZ6w77HWvClR4FZ7zIRn+qwMjkqDIZ1ttok9y9M/
	hsetaOtMwmBzHWRLu6WAFDrviKR4BYKjVbSepsnCgj5v9zui6UjXy2B/udyA
	dWUDhOVoMtjfl4XOFx75te1BwSpWztm00OGh0Ij3a1joVsDir26t/NutYqWF
	bv+bLHR2ks4+ItlygzrhVNcNdzROER4ME8ZaXww6FE3q0g6ed3YlYWzJ2JPx
	zlrLXmBn6/4adrZeL9rZ/2Y7m6K2WdmYXK2AV93VtVp2xcyBdNjzop4ZKrky
	QCrd/HzSlh3c1yD778ZUp7cmQEREmB/2VwF2NUjUaa/r5LhVhg5jrEdXPoP2
	OvE8nE2XMPg5KBzYC0OT3jEsequk1oFJrYOm1Dp4itRaFYvpQzswwtTtLlo6
	raPRGI2sCajFTtkIhaZQ2zBv4OaGyVoTTRrxspVPhbXWovIJJJ+muCWRF7+U
	vCWjLQtcvGGvWXEg8NL+oYqNbnJtT7qk5opmxZn3ru+lbwYlNnOAXF78GLd0
	iI9D0Rf0txGyxc0kj/5u3qyYhXJ5LbYlhFFaay3Iul/qtKBXXG4N/f049YQb
	jfvDqzVmW6We/z2JTHZOvz6DDlaxctKmyGR48wuv4hGRyeHmXxMWf8NVOJEp
	Hf/2WUiinjWCkb5FiLKzfZIQJdESqmMFrKlm2Vnqi7p0X/9WElOv2412Bt8s
	MRlmf01kWgGdBmBWx2o04fFvVMgxRP91pZyfBbHHBJaVdrYDk1gOmhLLwb9J
	O9vBU+xsEsn/+TNKfnHFr59va/tfwNT2uG7XNK8J7P4yu5xztPpwyv3+Vyzq
	NpTMr1nMjFBpCV8hewD+zVr7pI07L5SrbN5zSy2JUVhtCDz4d2UIvGJDoNbM
	cP01faCeJDRLv2tCves4S3+0dHhn75vnKCME55a4WOSop+mwoNESKcmhbvjA
	81XQ4AnK6i2yMp4klmMeeiLSypbGYLLm9E70DzKChHaZ245pmFWdpXGz5C7h
	0oBacbdkjadcMYLzH5o7SakTEME8aXomdjluj6VFSh0JGRmOrXiIa4yZ3iYh
	1un7VrgQy11aUhjLq9PGVjjW5jGk4yp+innrbLWuAPLXrLUng78v1YMLQf+V
	rbWr52yoHq5C9S+8ikdUD57yb26t/eutYqW19uCbFA13lH8Tc23A3x+NxvzV
	NZBetHPwzRqIYfjf0mjrzu/nAPjfqEpjF+hXU2lQV+1TOp/bk/1HMTic1MuQ
	PkEXAzurm9XY0mKLh18fmiFzlj3wx6wSyNAiJYYyp6owEt/xF6pah6ZqHX4x
	dcbdn0NJYGHYtYMKN/a9iQA94+Q9HHbhko61ZzdaXY3RoFViMFEkg3OvUGjx
	HrKw5V1pSWOOJ54X6YzQaPoQenS5+Mp9ZdEwOrmmkdCglyvCWNPsNp/eugo/
	+o56ixcaGXJ7ZFtARSENylEJ2IWwlnMURbRj9c3LpFA4R8PetRALLjom80Xf
	Yb5APKDM3nIdZKwfBoefmPJVhp3RoDbJ8ZdVXph0OON6lOj91yQgrI9oCSCR
	upezjFSRqpmCXJpkL1AHcJ6bG+6rw5b6LpQxrK6o49dKr+LRlt5Hr0HWyfQO
	l3Azk/Pu8uPusm1u9Op335ULam5xXcChL+TPw8jIdJcs+tEoZ1q4BdXhsW7g
	+rg+GAHJXBrHuiJelcHOtUdJyDescDFwv4luLOi5UYur6VcICighnWl5aWGs
	1jC5iW9TJPRKwTy3tWhtgETwttS3Vi1CZHxI3Zj782eL1mrWlPT5s2iZSSjd
	Mk3dNl2vLnh7qBmIMs7fjRDfTD369UTGn5UUFQiz/5EU9UuvouY/sAtQ9x0c
	fnuKVE2kXyLY/5EitVIN6HWjncOflyJl4urjGVLLyWr/kSL1bzhF6o9cUjoQ
	gUgmnJfa5OAxodCRc9YL9E5sbkBEevvu6uLtm7MfLG+J5aJA2V75qmCSSi2K
	Syw9mWGdzcLo7YgVLgutK3X6FZKsyJcBfqLCq4p3KPq+jL56r1nYZ3l8spha
	xwXRhbh0qai/Llm8LtYor2+qKEemohwtqyhHYao5Z9qb8qHylRbODCyr2N8d
	ohkeNjfc/KpUoZ+Uxp83ShgJgMp8UYwk1S2I0wgauJZ2nHRYGWeI9aJ/pp33
	To66kgNHsJtH+jBM8qjjB1VD1RAR/oC6pFI67SlCt4d8/uBrRQOQo1JcR0tK
	WOQkdvvwMHRXHa1xV1nzerbt8/5D1Khtc30BumOPJtCyDfO8wnwkNKClm/cP
	aOzJKi+KvBB6IC02piE9HwUZJPANielZyQB3dXvEa9mI5lklc3NgEpbrdvHn
	PEXeoq4uDstw+GouzkqzGEpMQMuVn5LeJA4zV+tUpmDi3rXYi2B1FV0DbFKC
	ar2gnO8lODbOBeqhXmvm6A+XEAlbEAddubkYIzQ0406c6MSpUbtBxclg2o/a
	oLkkJPQdVwn1+o1ZUf+USMQUPQ8S2DT0xacP2wOW9zH2Po39PnBMP44W+BZ5
	TB4jWWwSbb9x5GYmCN0pR7W01kYHL1JkJpsbFpv+96W8oJ/gx6r8OCt/bVH5
	p69Muir4KYyP+ivEi/OUw3Xf/jqw+BuuYqUH4uib1BV/kqEoFzQ+WVg9eM95
	P/gWlutZVcxOByEq7qlVTTD+dn4HxIof/azIJw0NMwJdtzExNfxGNqhW7D0U
	JPMN3bXlc/k03hNCfA0Z//ejxcgdWu+D+EVBTmgeQF044hNB/s3w/mZfwbEJ
	4sfLgvixT56mPbx/dR46DAIbICz+RcosdgoGfkuXOy/alnvJIeDc2MSKo3Gx
	BhUOuVReqkq1unZcKTRbiaTABsWdgY2GGWJdrGOGhdjU76eJ5MfPyvAQWQFD
	yntNUnDr96EWmsYdl+ViloydOZS3Y72rOEZFUdZM59JcoV56uSYLmwBJwiD3
	Y+qhw6y4VtXhEgagu4Vp4d4rrrk9opdxmzSCw3X91UAlV5JQI1Yt5J5gJZ4X
	CbXqq65pa4e9f2WooJRlCFpfkIRbLVTGSjNNANDFiIFZin7laCBwKlLUP0TL
	6QV3/BRqDHAjSZQq1jUFFmxzUYe9DoL65XdaqyBAkeUKeesWACVNxgraS+1N
	Y7rh2AXppVWRqguId4nFpNlNyt6KG1cXPKj9SDvm4oEftM+W4I0FzbToMAjI
	FjJTgrC5m4cWhKuCdZhOBdVwCcqx60AfdmPHAO6ILKDq7ymKRoD0Vw7gXzlp
	U4bVh/6KAfw64984gP+vt4qVMuzxN8mwdpI/N1w/LlfkEJGCLGEzafW3is1H
	Ndlo5/ibJVRD2p8Rm78WFAyHfzfSo6HvrxbD8q1weorU51q3fN62ni1aM9O+
	sHIZGuvreitZ4R8fWFBpuTASGeC+15ug0PwxKfKAvdQrAdf/8pWAm/fUrfZV
	0BruzG9CLMGKXWqZRr2SfDZbZFJ3icNSfW9R380rGIC7sDqphTfqK1epgBpp
	q6m45t6G6csvZ8SG8LkrOoNg/mReRVtZLh22ZDrIWVuI9F2UCCXmFnZBMW5+
	kqcquZSZD7dZKZb6lbuyQV6KbkBqQkdVhhJTwV27FVXP5kBM7gLkpG/RPbyD
	AT1Tah1TaIiq1jDGXm2W+K6XJd72/W0+b1tjG5OI3FccpPTt2OhyBTY3rAVM
	R8pAuWMasji+gBkfWCHnlSJ5QqQ2BzjdBhpu1focedR+pX/aK/6yP8uo7fZY
	R233cRO1tV4y6gfTeqYrMVcl+BqGCnqpAR4FvGKHltb0bUsLAElGRVpWW1pC
	T7r4KEYnGvz0a6JrY/ePo+vWg5zt0EW4b1kh+3oxbY/D3M/8l0JhmeU5+lK/
	095GparRH4f06UfreFQ6xOaqZYtZqPSWq7OdWOdqdHcO24g4Q7hydlrSS/rx
	AaC6jpJpKW2Dl9iH9CSUg6wkMXtuPgjvMiukzeEIZg5TokhNKfJ5AR4mhnYJ
	Qgs8beLp44rsKB1YJNPkltlwLF272ScFt1bC7XgRcmL1oTkJubZcPg9hZpwB
	5SqvkwI0Ttoo6CglyK2Wniui3nDuGL25clbERnPvz9trTYfOFrLsJ6Q7MUql
	mY74TbNr0ozvlJJU+ZxwnbDsGj44AuWQwIaeBKgZyX45W+7tkW++VC9TFZ0j
	Csw50djlGHhwkDz+gELoYZdsJpjAA0AhLyrOU8JalP5p0KLYOhQXkCLnWgGy
	kwr8Ey0S4P/SpoFcXAzjrJaOg173LA41vS3xSJhoqAWH3ijSXmGimEp7P4Ex
	Tci2RjW3qWPTJf7VXMI4AkQepJnkB3HZwhjAYznpnDt5LkrO9aniTwn3CU8y
	X33TL8YiN53fLslu0yLnOvgYi62ndlm18h+Gp9fGU7mqMVqFOhbla6CK9aSO
	nxwVHpADXu8rNqexss6VLkVKcHWRLOJOZ5cYCxRFRJVC17xuvGBhEhtNmb7N
	YkAnisd/JkgwFeEsPzqNIJLV6qaWD9mI7p/lVbl+6xzG3vSfgu4LybB+8zd6
	uRkowiPE9BftXCaJ+GMJgK3o1eJHVNVrKWgvZ0nMV1l6pu6KeQnowHjVqMLP
	grnkQJojLw4aIjXdB3L95NZhPn2nNJ94Iyagg4qbak5q3H+tDK+Gl6DIf6ST
	AiOM7bbMMhOWPBTD2WLYVt/sO6MnvKkzbq85ksv0OubQ8Vui6myVdk9y0IVg
	g6sPe1rzkCBoGfUw9Tesz7cQKIV0DZMH+kVi1J0JGmqK+oiXWpPwKkq/dL+g
	MCtOEki4VOc9c1TwhFW74AtTu82EqJnG87xaFDgAaJetGr4znZ2VyRRBKSL4
	wY9EA0wfgD/XJCsspnGhzSsZa/kWTQoORoKFdiqCunJ9v6KceY0LUm5ed16Y
	CxxqomOLWzUEUK7vNmhNIfiIwYwRWMBL6LRnkNXHGLJxOV5Mq5r103nMGPAS
	KJ+I/RcJoonkyIaAGcVzJrjwq4Hwz3KCn6t56UiR3IFVZ+etzC6Dkt/SQr3S
	nX6N30LjKtTP7iPR2WciMfYEi3wqGa8BgRaZuCRJamrxLZ+SZC7BLdYwQ2AQ
	xvKIYMVw8QnTzTrLFnXli+xGIamVcticpMGcOa1E31QnmuUKaOhHYAfgcTxh
	YXuB6+2Bt9bvVwLDWPK1esVQrl3Sc9AMN2rgXtAkBCJwsAn3DdOhH1h6CQru
	szDDFYwl08CvZpyCXUxZwIjhNgSl5ybZ/hkSej+5RGQNCDTOyFdmiLYjIg1o
	0AnW7uPm67FrYh1hvYMk3kRI1RVxcQ41WeLkfJVxZ20fLPdMJRulJrmGR2LX
	cIm7eMayKtkiRboOPREdHPb3o7MXPl6kFr82OMb469/Goh+I89H5HR+f0Di+
	BlGNS4YscqWghUgmLgorho9RtdDS6Ip4l7Uu5dps1iXdYpGNvFvNDRcpTK4Y
	HcNUhQ45MheQhI235EawVCEuEesVrYS7FQgGYcgcby4IwBmnbsYwIM+zM1x8
	Nl/SePmQI3BrMVGyut/4gfj5/iDagdoKQAhh48d2GTUIa9i5BGsRBEjoDyo5
	h7I5Ye0npqwN6S3iekrOocu1m3E/uNl5EA8rYAuVbFXB5MAMMxkpL4xyadaT
	yVqwp3pW5uiYb78UEtU6+cSwJWS4B7GD1MiblYlOPQP04K+TFzneJ1GYd/Bu
	K87+8aZGUebyVWioWBGhB9GJnlwZSad3q4x2XN7drnzARJ39lGFZBadw2dTs
	2pf6yS4McCmpD7MspwwuhVPylCDQSam2SJqysijgZTKguTa3R0sFnVnjho7P
	mPktS22u0/E2f5IS9NtcfJFPp22o6HTxub5Iv7t/3O722r0T8VcWi0ziSFec
	ZBniZiVPGkIi66toLYcXu6OrycbhYd1ZG7fKze3LfNeXrwLnyjD8leW0nSP8
	iHf3sijog+9Bmhx9xQkrVgMutAbR8H07h6EEMSSS/lvlubBDvrSBgzpGn67r
	abLyjgRN02BaS6WQhlAX4iEZh1hjdUwkabN68o3OEp6ZhKIyU/W4ItZZRot5
	qx7IoOMjMpp7XgctC1Tj1s4FsTAHCVwBngAcTKG8DS+17hE56pHA5qMwW1os
	u6oc+RKZz8e/NOrhO1lCw5h94XzZZss74CXDFEpoxSIVaNIcWGkR0CI+E/3m
	ephWEd8d1jyHoi4ZBr4oiLO2iWrsMy3rwm4yuuFwEp/UuyhLC02hX6siHSJn
	+2N5Qw+MPwLo02R8bZUxYBWvRf7QQZ2rvAwz+Uo5Gi/W3trhlaJcjIBXuc0w
	EbUIMeGBrRMm0V2tvMO2g6EFLPjmdiUsSVaQmRjiG7DIKSKj/UNiKHNmk9BW
	aYE1bv0OpTLfg9pdYp8a2TQtChp8PWDqNo1D90vpjY5mRlUzmJC0FYKkbMXr
	BvTeUC8QG2a5E56bExKC5uWmEu8B10JpkqBgQz1K2fQMSS3ifTMJQIKt61tZ
	LiYTFLBBx9P8msDGrUSl2I3Lr2FbIhfBGasSoGFGS8ug3T7HJtQJYi+uioX3
	Mq8/MxezRnsFJEeh/ZpRzo+bwPqkjRAbCoQrASPUsM1XfZXdNgpTvY2xaCcC
	Owxsl/cm9HMZmcJs1iD5HTA5YmxS6+LmRgDsGjI5dGNxU6UmRhM5grjOyw0q
	MHCzjuOMvbGLWe9ELzwtkFYeSwRjc+NJFGNNVHtCH+cPjQwFLTEkTpuvAF8L
	rJnvc7iMN8yIuBep85TyfSug6YnkG8Jxc4NlENZyle5ryn7AEdYYl1+l98m4
	LTpq9CIZp8IClDIidqP0qQO7zLZZzWkilHEP8ynCHdUoySqmFKcLWgyDMpuc
	SOB8UcwtjA800OWHoTjrkrVBbwMGbFyIhlsBKrOY4Eisu5eowbbqr3rzmLqo
	6ajl5CXLZQfWBDEGIr3pXpbvRcd1xZlxmxmh8NK4iJu7Sjvl1dVgOUTBLr2R
	BYf63jrGpFawrmXuOwTrmxNih3VxZlSVVZirC667LhGD7bXWVTQuBUgGoLHD
	CVuNT9CMi1oTI/GbEEjYSbKMf2KZqQri/DitMCWpTsFrWSjAGw3IB1FhlxbB
	drwYMfxdVLBnoRfCfZNbIThFUl963Xy8TudZUne0+jItI2gUw45jzyrDeTo1
	4cEybewu9eUurT9LQw0u91FxrzZm69wnloR1KS7n2tiquMiY5/lKzdFd98nH
	0Zarq1zPJdryEp9dhPCQ1+biusoPK5kW+yCyFUYvdzsFF5+VBmZD5aBFhbBO
	Z090YAusHkxOHZEJJGJHI1RVWLGCq5tgq2GpiVUILf5APSroGtcJY78GwliR
	P71GQWc5Cd+JLiqViEonwJdhSQpDUVGN1U5dj4H3NeLUmBDY6DX1ce2+FIl7
	vjdwk77WRLSYlOSCAAXrtmYppPnYZFnAwjtFQeRqy7RAacCsRGV215XQrcrJ
	XHaDHhC2Gtnha1g4X7nhw2pxZhLfspoWTt2y8BMCM/QRuLSjMI8TjkyYeIyG
	dMTjKoUnfwAJeA3ioLf3uVP4L8QJClbJVifvYvL5e3zDXzk1WDUpDn5enTkY
	+L3rXklVvjkSJKA2PHPg/ghajNUsT7kvcJkYg5HQhF6/RobXR9LV7etpWRfw
	osc9yAyxZsJksFm292MU1U5EyXfEOoyO0MvRiLwI3MiPsMgAdIy0gdPHWUlk
	10teBUMjrkrl4UzvtSIfPwMGLAb1hvEjQgLBKJ6OpOQqr4wh1pJKBd6IhDsU
	5MDWvZ8WLCT02+WZIkodqECkE6TMyt+G39dst4YCssBdOtFzKXjmbyB7oswl
	Hp6t8pKw33qamSOnBphIi9kOuieHTi9T630IK6H97PGZTHOR5zk6gq0xaJY+
	NvKKbubVDR1pOmqZfUHDhx7drCrpD7IW7gDAhvcxMtZ3qpxd+qDKu6o523xC
	NfjDomCzYeUs5mxdU59R1zmMrAVirLWYbONpZmKUlfMTYgDhMODYbBsRw4D6
	qTrRS7BSH3QR+I793rTAAa82zWQL7gUchqCl4pzI3BIAskw8DBfLxMsxjbCJ
	aVI9KzVJx9vw/G2BNZsT+Pvd/j4RmdP9wenBYafX3x8cHB6Zj8loi19EzYLS
	m5UsLEAwReSNdUvtdjAIU/ZYyvatOXpp63mHHZU3YoEY5WO9fvS2Zv+18Iha
	BBG/8oRbMEm1+UOuQIp2gFqst/VNpen1CY7ctHbXatw5nEWK5kOECKOQJLqd
	NPYq2KVG34CdaRSPR1hjMQK2AJHdgL3joy6hVEhJbuhYEY82I7qocWtR1L0/
	Grzk/bDtKs3iQimyJF6i7Dz+IRi/zUTErLS8tIJFocsLLFeK2TUZu0H4lCuZ
	DBjUpWbhXDrRLpFdZ+/f9dIwymiXLn3dxDLcCRXN7ERLKeRhnjZW1Xz4VymW
	3sxC96qbOmPSwdzd9fepwaal1auqSiYZCLufprNUDbDLpQOkYhkHh4bWKylD
	rMMFvNz4DtMk2NhImpuIS52vAcvCdYbYEEJUKxTjcxUE9Kxlo/GU7u84NO6m
	NUHEWcyDTM+m4MD6mrS/VW+HpBFaa5aF1JZmY1E6Ea9qUrDU3AxOlPN3lmM+
	Pdaf6rUR/2zaFBM+bmkduUp5Etwl1h2rdS30Yy0UxKkSiFLCb02uiAKrpKt7
	mYrS4NMZ81DDrBf6UW77oBPpyJBMgupxQemMNgcXqqU20l+sSS7sLlMpe+HN
	aRYsiMzEx0wBrkvutxmVLkndXOdj961gJS4+mN5UA1X5nPbqGxqbHGJP8q6c
	MWGFwuf0EKcE+YcgpkslTJX0W7WxofGoPz3UjlURMzLjtS62MotwynQyaKu7
	Rg8nXM2za+66aga4mnnA6XEiidCpNQJuVtuQ+DtJm0GQCSOJt1A5fRGyEc9t
	JMDVDxHbVsZICpSasDkLGOwmAyceE7rGom/4WBEA1MWLKHNZYQhjvTkGD0MZ
	JqIjRU5PKJELleNAafX2YXHtr0Wsx5BKQjyIRLgqkZ6s1lANCnGdYzn3XSPg
	HcqtN0FxtUgR5lWWiqO++FttAMnh5TAqvE8ClJlPH22U1hIXm9pgVix5LC2/
	fAGXR1zboT9yKMwp7BtOV4PDpJy7pWG9hWFfOIy0/17l3hQO9RVSEQRPXTLa
	BEgWWHGdaiLBSVwGCtYgQxdnP1nB5gBY6UHQEHJXKqtBpSnFQcimat0J3DiZ
	yKaN0IUgesyNyBN/J6NyrD4HyITp+jasN4TFldrfTEyASJHlEQhGopeEljDo
	+xLJTwjTDqZSuLqrKreR74LexFAGsTJbgSZMDzXuB5vPnOl82Wppg8DA60p4
	qVWrZk1aKua1wiEQhG6yQfApnNEQU3AHjwgVlQDv6kF6Xuu6NzeEYqzhgIa/
	723M73AjShcF6IUS9uk+jWGq104TV0SyDmuPlcm1BEpN1jNPthy4nfI9ZUMm
	0Tw2wBDwNdGPRNH0miPLGhdXjHilPzkO6qyLWSa8MAS9PVoxo050eSPDJcef
	8/uEEZNOG/PsbJ092teEF0LnCxOXjeDk5jRLPFbc+wGbF29S2Dz9EVraqvWO
	CYUFOgwDKgY0qtlZiUG10JnzJjF1pnpLlVBBJExggXJzm6cScyBRYcFBmht9
	BREK1SCjtYXF4MVDjqtNGi5JUXhD35c63ydFkvyY1KgN1xCMU1/uOBDVUGXh
	NlaxV7RbM5vXfMkqXAyLnEibnM/X69J5LKrPGt9onORy3KCYj5JAEqhTs2W/
	MTv9NUTRkx+JOmiGRUhYK9vv1a+4uWHCtqpHdpfQJIpjYLXQR6/DZrx4bSaQ
	8mIzudwiaQBCpxRIrwcR6IAXkzVjgV7/K4e/5rXxQuWmBtxQAohHo1zEA33b
	pGWhB09dwFK4zapFFEl7WT+w+RrCn66mriuwM8M1H6KvTMdGhXm2RWhglpSc
	v4OCSDT9xwRhI0o5TI9jUSlxkdJL8R+7a5z03osoUXTnN8no0zoNSqWEEZ6x
	oDGFXxjL6hJYFYwclZA1kaP+uJ5HWtpt47Fjwe2MNVizjUp3LVJfQnGW69Kw
	19XSY0WzBRVDeBSSaIKoZceIW5qD1hQgo7OQMLn4DCR1eumEhrSrxoF6atp0
	dVp0bI6p1u3nxGFmq8QjKNmatRh4xx5BRYnkMGmtSCATwS4XWo449hBlm5wP
	U+KodIEtuT5PIc5MalA4NllzHyRbp0713FP121ArZfWdi4K8JDTjVFwXGPmx
	5I9cHu6OVeLabUZQ8oNSyikMz4bNSMSgUiLhQJFQBijnMvxE0/O8kmCuIGGv
	EM2bDXZiXmqjPG0kwTzRbT4lkOhgtCje+GI+Fu2YsJX9THwh/aQMVH1oV0VG
	nER9WaH7n21yoGYuC0ul3norvTC+Q3iYSLdaVgHkIAgDCnzMqlMJknp6wSgj
	V9zJqRqM7nMkpBJY6VpgqKXN8hKG2pAI9zgwPHIat9TyDcho3QLVcgagsJ+y
	r1mFwN7l7GjLl9KEsoc65J3NkPEdqc8VQ5rjXU2SbIInLoXCwcyr9FVKKdTC
	5VyQsKkCV0rCvNzoe801Vj1MRjHuU6qhlmYNkrks2IrpnQ8XnBis62RuFfjy
	IoSe2e9tllLuPiiSSVFI3rAoYqKAmsPXcgG/IXh8w3BtNy62jfmCXU7ccITr
	aeRCu00D0xRhnCz0Yf10nufTFfxsGJdp6YsVPKm9ubOy+ADskIoJdqdhFI8I
	nTkUcrZuJMj6NTKoN21RaYI1R8ppHbwymZE0rmoiI4qMDsz32fnh7Jy+3yyw
	fckd8twCPvoFfPnCm1/V/+MugfYBgPmVV/mUTocXXtt06WI3l2rjtoyLc0Sh
	1tgQ+iX51KE7xPqGcvD7RJpGFmgpA/oqyBUOlfr+iWLQTEiAVNOv5WgLdd2V
	FCKxU+u8eoaBhKW1WcTO71qpMJEONaqWWr19QpIlGYpjTSgDjVBxbmooAtrK
	NR1WMEhTfteAT6l8lXgaFE/v4odaTsVdkVaVGEVqdIljf4T7WIZdGsTGaLph
	LeVkiauI6kf3mINm1MvrGtyIjhkGCAHEKMBhTorY1cMpIc1A2a8lSiQWDC1G
	Q58zEuq5cWWwZ17ozmlFMx7aY7PFT0v4Nm+NOezmhmOxI5AHvYQC55C9Kz/t
	NPKNU03dbLZXcqfvObKCVOuPDBu5xTTEw5zbp0okUsXWrTL0OzGXhhQBa+uo
	QPNgJubABCHv8eZGiMe1OuRLbRaYwYkUgowU1ObMSkQH4DhH3C1WpRCBhs9u
	cAhk8pzl8IRuMpFjvNhkhoOg6D7M0kHE7ZBXaLFYevZ+VlkqsA7NkWLEbrWZ
	qfBS6xO5UfX6Q/zi0SX9JdX+YzcEtSpxQmIYcx0KjIDi5+1HY61djctV+rko
	ahz6pFHz7EHn2GoIJVgE6xN1R60xUWlhhuqMSqGl5wUwSprc1nQiXyDGdx8Z
	OumJr6EW77BsF9r+H13Zg9K5PzU3dZWFdJXJ9QbsoBQRwvEJ8CdujOaKniyH
	QIcLt32J3PAbdENjYsciDryp6U2ej3mS2E8TyLgripfwvHd5PcB1BQu2XDpz
	4/oM8HyoxYyQFuROTjWo5oEThANMCWO6hDleVEH+BvoaS/+7FvL6brSYTbAT
	2YQU5wzD8/miIcyD4S0JhKhRuyIlRqcz3GNtqVa2+I1SS1F5mDt+BVZYwbh5
	W5aCSn3WK+38Bzo+5AC0dCGOOFnpEbFeqEruPGO1QlGugE841VfgvWyH0O2W
	a0KXm73aDDquATlHVY5D47wFdEgygDcp+/w09Qe4W8PxNm0X9eC7ZOfiq7Ro
	gVrAp+u5Fua9kKA4IaKhwXeN4nVhf49MPhfUjaxjha+apBl1K92OIri6lnNw
	RLESGaZn6fuNtgkuPOTYGWgbD1qt5Cy6ePnyZXTc7ddazrna1rX2cjKSy9fj
	IiU+FobJTjJhyWQpxQMBMUhKIfVBI2A42ZnYv++mXi+zxD61kOszwTM9ieWN
	5DonnmsorY2HdKNahUqIm4ajsMwJuzPqpPDUa0o8sREddFd9lu+Ta2D7w0rk
	5cp2QkOruPxk+matmpRUG0LYFVFQGRg+dx7U7N3AqbSYNYQzdwFkex24Dmo2
	dQ5ztPgCq6+Y+hrM8k1jTrWskYaas2gxzOEqz2D2Ux0mHlXL9odIWBkBXjKh
	SRDuRJcirzi2TCu6obPXYGedee96SnroVDJneQ2pRlEHKPEYPliNOyDu+5fn
	b1+/fvnmxUupxxCKEDXYLJdvq1hopslFHb4hrU/8H0gMYw6mtuUCoS15zSmp
	HNRU3IoPnkdwVTzRi/2568VeF2XQav0jx3h95Fp0HrBfuKSE8CGufzAvkokU
	ezN73B3sRFvoeStpnVtS1knceUsOADzHfj1fcnrn9YuDSNvG93ZbUT0VVHIH
	hOVLNXBzYIz/DJ5IZ73lG81vAQ0ksRHOPnqTY6hcQa2RBgXRFCQAsXxtMwkp
	sK5UK2vCXfkYDZ/IuNTlnp1IpTpFJJjoH5aSD0CwfYE6aAu+fBh7HjFstOM7
	B/OHJMtKPK1W0d8N0s/cW8JFzHPGDo3O6kXIjCRJBFQfA2gXVmbqVihv3dSN
	eXklTp7x4+4w2DnjhDP6AuPP7qOrq8Pjqeta3hMWV/4Fq4OPgEYNRemknqSL
	5Sr4vnpsnKSBk/F6ElPbVWPWQbAS6sEG2N+9cg/Lks8ZC5ygJTyS8+NbuU+6
	aQJ25mk22W4AwiGJyOPpg9Uz0rp6DeMr2jTDq8YjEJsI4OG0dKuUzBZMyUSO
	RZghiLmeV3W6KywylgNm0D4rg7HrJcgwb6aHIbI8p2MsyoUeS6nGAE1mF23L
	KhLZoJ1a2X9RWuA+8yjmchBKby9gmplYY79Vm2jiiIFezQSxyzsA7nONUbXC
	1t8TK5jDCnErBCW9iLYtRwTF3k+8msGhzcD7V+fHg5OTL19oOLahMCzVErHz
	4s3lLocWVjdFwvhzmzyYZkAIX56akrlzd3fX0ak79NluKwpPaen7zq740aEw
	a+eQnX165kif2adnuhIX/UOes9+AHvn8+U8H3S4WK9R8kZY3ydhu54s35W6r
	7iUKupivYvCa9mBBM0iX0ZDowqLI6zO5YORiMeUpX77f1VdkEbDxZzBZu/Ng
	GPeO9o9p2SQqMRaguhezdJZsUR1j58P7H7B6YKlIShZyHEfcQq0NqiL1jeWk
	2nKFX/23F292NRi4cNGS6hnkOo2herJ0THhp56aq5uXp3l7zSx8AygF/M6lj
	Q4dweIhDyIfg1LXqHDtv6YLsBrtQZWKcV6RMW0OPYJHTJJZiNoTHO/3OyckJ
	AcFrIOb+WXq0I89y1o2E2gXdNZgCKIZaA+w/HR5jzebjoHVGF5mGXEABVqlb
	z+UiABk92r54f7Eb7ez9MzJ92heXb9sXVx/aV3svBVgGKBhX2KpPMlQhkd9W
	nU8Jnd6WoFcOXbFWhEMMP4wjQoeWIGTw8Z86hP18b1bCM66BCC/Q0n/TFGSW
	NCUfI6iaGl8LYmWkaRW4AozQSji1y60kYC2JSJa3YKIc6h6wQs9Z6VbHR28K
	HDa4d0LErMIyYtYZnJxI5DhAXHnHmCeEvBraOtbnub4mVi9HPSWwXqXlrJRy
	p9mtLE1zyXnxPkLNrzII9ULP+FqjILMNpEXIKyAGSDHNrykZoRwve6IT+lCK
	0j2OznytGhHnZYIvDTsYR+aLO/LzZ/cYQQG1FZ1pqcZD7LhE+g9q3bAvRksY
	BVviiyO5MhzZ/BTW0fpG4vd1ytLSPk5fYwPiYDFvY83Sxiq5wcTXAmpFF2dv
	zkxV9AqgWFPs+XmCWDSW7fPamYHe8wC49KZCiWegeSJEftocEgADE6C8xWf5
	QvWVLWvQJBF3aiDjDf0UTPlTHWX+wEr7iq4p/BgRNpNUforqL/pvXJuVn0CU
	3PuHw/hoeNzrtk/G8bjd64177ePucNDudkfdwWQ82O+OjumxEB/4Pf5g0Ov3
	gYNXNd3PpqFjb07Te8o0ilBPnQa0vjFN/6vTKCbae0+YBjjZmGbw9WkEkZ88
	DQn72yE6uf4YIS6KFnCByq3meYzHY6uVBUcQI6ZoM1uXNZnovSLcFhGFaToK
	ms7hfHt9azL8iiVWxJCyRsMt35Cd6LkJ0TnOmmzVL4ro0a58V0Ojpv3hSXrt
	t1vcXG5UbdFu2kGjnZCGmZPQcVIEVrjU5XFYxzpgVOpx3XoKam+FLResTztn
	/HawrEtfXGt5XWUjZPPRjAg2bFpTcDBgt7wtLVfNsai+lXJZ1aJ26Gy3HtsH
	L/dNqNME62SrgpAtC5GWOLRahTjpehIE3DFo3iyN15EDQ0CZbeJgy0JYGknp
	brsi90DpWh7QmxUhC0dcN5Zx10Z/9AQ7hj+LOTB5yNnUViub53bVwLTByAL+
	ixVwamETWxP9swUxwv32OBJp/vSqil7eO6A+4xUTr+iQsfyUA8f+42uRlg+l
	mt3SuvzV7HARSV3DGmGKVRwghF1R8YKvykqkoC2sPF4fD26zyjBCd8BWiUSK
	C/4hSDgUA2+tPB+2Jh2nWYzhet1SJ2NVnLP2CUjM7NnoU1lz1IafQgBPUFcL
	4/mGJqs2hrg12Knl3IJF1WqNuNJiYxcGpwXl1wLL7iPTFbmqw/xWIGCRKgBV
	YLnmJqMWHCzO/duBqwx7tPrMLkI/bxjatbMuwkg0+0BKpiflqD6C6E8/+q/w
	sMv/yNSUFOoqFvIXW5zrb1bE6rkALeevsmLkCgdfLs4K9a8+2nVYuyZo2TR0
	VnUUKqyzzqW5jpygv6cScMGp+mxgTu44LwsCJxceYflx1YGbw4JBBQkcrXms
	uFEg2kKrWd5e9BiCmv5x7s74vXf/ft5eecKrQKKUjYPIVNPNzAjokp48JtVV
	p82NZkgbZ7hy7rp0gJDCFWHtPjXW4gpYuMKOeE2AWLvcGK9cCMsRGR7iRJ6x
	fd+sAAJNLsq5vmm0qhzre+5agGai7AORR8Vi2XvOfsLVMQmuMd3mBhPbJxT8
	u5IWT0WyuqGntM2wIj4oQ+aahgrG3pJqz5llCYcCA2rNgAuncteC/9YYnX+g
	2S5YYGN781njxEMfSVBZlkgXn9+DrlQc4WweJdnJ1w5HbJJm0FkIoDOiS1Xn
	lb5sox/mP5T09ngykUTB4UOIkhCVHUtwEodhV4OoWTErTQdjda+IXTgFb14M
	Fwyv73EvauDxMPiUPEhgFxfBiNOC1D9JWKbdJ6nmFd4VOcdmLtCXTMOyF5U2
	4c5p78+Qf8yVNCoSK8tPWlouCM7HOIVyfNptcZ1q+TOO6fc0gAe17EtOwlIH
	wIT47EIDz1HMPZmzJtFIbRgnsU9IxAI4k0UzEt1aeHwtT4kaU9wYZs3lcIl0
	gpCWGSOxFCHtwPFZaQGma98x4+HF/wDmgzrRdoSft9exJev2VIaRFSsMyI3g
	emMIPF6ALJsbvnZoR1QnZ6V3xqX6fM7YJWOt2KPUn9UQBPc47gL4py0tkDOd
	tadpAOQ6EbRGAVWA4zW+k6xaBNeTWuqNjOgkjlpmSVudydOloB/rbKDhUCCZ
	y2vQWm16/rU26d7uaUGezYiAlvtuKVhgKQJp+OD0KFcpLFgHV16XNm6oPFOX
	QCzxYY2c6Z5+bDkgMygT+aQi0Rpox0UYIiuUwoUXxaHu1+1Fy9U47K/Kh3ri
	8uftRgv7tXKQrxE8Kh7mVX5dxPMbFzc8AsGoh1pZ2pUP5tw5v3z3/s13u4/V
	WuHmTrDyoq5fJU8i+biKdraCuppbxPvjTHO4Yu7B4kMKo1rYIt4DoLZ2NTAa
	zXHmFtnGMkiMesCp2EtkjUr8mkVjknva6Yrybqu7k7jBJOZWilRILQB4zbiw
	xmKOABh5QFuR+VQ0i4edoF5QKxhbG57o8NqwiI9ZPwrLOA7ViLA2WUBEHx+S
	VWtaxL2CuE2QVZV2NlekwaJ0vef77NMP0UMcWoRojaQP6xDMtIOvAjTP7vEh
	NE+xQp3sH+na5PuzNy/evvaV04WSciXuFzlq0ps7R9j09zC2ALvNvIxjbFrU
	Xd669S9rKk5hSw2NmJpYcNvmBqLbLLLN6kn6lCHEOrL+HWjfpaOIqyiI02zC
	kDkBnIVYBjXndyzCrtPrDW92tX1w2FDCEmFr11LUSFelc1WJ9CdkKYs3LmzE
	Ij0WHj39zQ0NdXJaf4P4fDEdPa1cdUMJ2KR1nXGdhgDR8LXOKtYAA5VJ4Wo2
	XNlbhFMdblbVjDULnTNFShPovJ7w4hrNKkppRRKlyyMadI+ji/GT1GQMXGuS
	KQPGnfAFs5MkmianDm1qqG2UJDRFc2iQOVMSHftekrZE1PPJN0NOG3BRpKFK
	FQbncEeEEckSFk0nXnphtDoVDcNzcbKUKR6oo+IPIA4hrifhAe/qDwatCfAE
	URMvW3GyD7wuhorwpFTopnqbcBdRkIA54uLTexWqltKaJOffxZu6WFPPJhvH
	QYOwwKXBg1ILYT7lHDqYPZM7IUFH3UE/MISzpbpKlXNqOaNimkrPCc9siVJn
	gREPkrGzsy00gW4dkgTpRyyMFcTZh4TakilgKcHN1buUwIBwJEEbmKXnuQJ3
	IRTLmG5Qx4JNtIwFgeJbS652Q6/cB72FCnyiCseZz7CsUTaGj3uPow5cgw6O
	exVCmbkAdtSkg7fDK/aJeakL0ovYM+m6pMUWEINmp42Ofi21tXPpJxLAuMGZ
	eTIUqVtyVaFUW8tZ9p7Wqh26uD8uMmQ3dmhh276xnoQf0jVCuSCLnmxwHCMt
	Lv6sTFy9bRmJBAVnn7Qj57MzBblhJBVbeqbtPh215kwr6WKaT5BgxrFz6tO1
	GbjVOa8OVkdNp2i5Zh2cMCS2roU05mP9jnNotWVmqNJpVvRwATi2Is1vmoH2
	XyOW7xoyyo4dLIJJ+weHFld60OuHluvPn19dvLvsHXfbgy9fEAsE4Qusz8Uy
	HMLAUoVRmYhcDXLNHPmvoa1YaLQHM9FimFpN3LjU+iSft7VSiVMfawnO0tiB
	PWZcyU4twqusFtZsQcfb3NCUSafcISPoPil3+QmsLZ/HUAOL+E4qO7QCmp1o
	qft5XDD6cLYqKRs4TsfYrzhKzLpuutRtYQ9WjZFhZtUD6osRQsK1VAz9xNlz
	F9avztDYjlO95BZYfWSMAHYi6SQctS4hAKWvsqi1r10aFSHtdcKjcEJ6UmFR
	Qde2jsX1xtO2qJ92VUcWfpeWvrMW12QLNxLd1roeoBBBCRenCagcb6StVgi7
	SUqoEKmkbKjjGkZbHNLjlgRpTuAr5w8hf9yno7oypd13rH20gs/iMBuBkU81
	YnAz7gK1rjSPYJhet8FWsc+HSndJSGiShv+Qg3JnKYrXXky0+p29WlYP06Te
	yk3M8gTJstFRSU3lIby8XvoW/mBWSHP56QtjSrPERMuVWkCQFWvCVkHIMF/s
	x4KOiyxLoEHFRcpdp0K/SVVPpHD3a/oQUq4OF+0R48UqbwJLW0jutqoiUo+r
	KJPggs9AE64RXMkIGFxLd+srse6mWaJCkDal/8hVZEUrUqO4fRRJA8ObeF66
	GFBX61gUmN2WZNWqomaGQQczRhTX8dUguMg4m9WqKHFtDIEiajHWrICa5wpj
	uB6GtGolekdkXkW1wEcn1FcvsN7nFjA9sasqK00tYCBI6Hz++pLffmE0aamx
	u1GrVX3dWXQEe6qZsJwsYa/iIyQXhHjBhri0gU3sexjmJed14aDxSv9YO82x
	WddU6F5fZOMAM5luLVz51gnoHoNHJvVl9TTVU01/jhzXk0tjkyldqwWbUuNb
	vZfL9/dV4cSmNFOiSy3VVyWguTA4SI1rXypGCTCs4kk7n0wkxRoySZCCGbuK
	UP8QXSp049JmcEULGevEdcW1ReKHoH74JC6NIWlGsyvKVBuUD8sNKSUleEg4
	aWVIuZaSsU3Ev5zGliqp2RguUc8HZ+q1ce5vVkaLBPlG3M/P6hhoLWA0DAWp
	0qugBYadHOCWzkgtHmlt/pCBepBQVLM1mxAXm/vRi40QZirWDmqMqOnpX45b
	ZxmsrIXfQTFKJhVLEdJeJvxWr0pLKzuGWQKIA09nOMxPyQPfqqLIr7nUKj6Q
	OIwE3TiQs+OvGkJHSVTitywMmJFvnk8f6OzAFKUuMBD9Jp2XSsTdqPRDW9TN
	eUzaOt7958u3b2D/W8w0Q9A/46Zu0jGRuaX+1RR3beTvGs6TgGk9oO3zttOn
	jQPvMA+BjVi80VNY5N1jcs927UwD2xwfXOh57NTUHoylXc+CVN7wZBoeCjUS
	cqF1afPLbh2SEVHRSlLbREQt+JDdTtlKHYusEC80oNdqtMnul6KBdz5/RtrZ
	7f6XL3v64wGHB5Q1nGAxBhyAQW8h0lztz6dkhxRO1yKytJlWuLy/2G7FYhy0
	gAnbDoSlSPzdJB4zlZpYC/BrbfUl6arODxnMQSt9l6P5ZoQa/QR+wheCbeI5
	ph2CXiu1bgqTo1+I7xE9UHLLsTThdUpI21LPjrgdeb2aBGE5xNJ2Aqz9N1ru
	Ig82YXtg7ZodDSMu0WNFwZMH30qPgWElaLxJRuumqMHBL7AVxPlwjt6Wxjys
	SptrsbycZtzjWrRZWb4/Tm6YvmCZmXCboeHd2CLUOTxQpz+DAgXccsmDCGNG
	LOfjzpdyE6rtDUmu/r40a+XKSRzXJ3G3EMsMTgg89wNxnQBwZElEjMfxvJKO
	NfBeipE+2gmwGy4FIV2+HSab9EHrdxXmJsp6CceJYc3NcRFFepQvTiizurT/
	eqijp7fyiu/WsRyfryE2TbtbwwS8LXEqSxIWh2nBQjz1eVGaL+JCxwz+Yag1
	snJ9XJyLfWZNpD5QLS6tg8ZH66axh56RvKQG/UGn1+kHE1l1NUvjWpqA3v38
	WXimj7iQlX94/yYI66mFjH/+TF+6OJtS6y0J/zWQhitdvyDNK6tvGSWoMxaq
	eSH6Nk0++iSTXC6G8LQLblxqOOM5rtlWPQqXA8bLLY7lEwHAFke6Rdx3vh/8
	tq8A4FQgCDWLWCvv8/3RnptL0cA7pUspNKnbEsarB8d02HAU3SXTadskk9S6
	YBkYGmlrYsBqii7PnKppVSH+8JfF8wWGi0UWq/t5aAeeiL+mHj3tk479wc4X
	w6kkKEjvZ03UQDRvLXaRVJAM+UYp4ifoG4uQ1goOH97/sCvyVZJIKibL5LR4
	NcZfrTqDUrieZrix4H0rmbZJ9qBQDtBXT9RKWFpyf6IpLmOrK06AAAJ2ohdJ
	lqLlu27X8rVQMOIeYSwupItrKCn8ef/l4vpaiK9oUrl52mbW1UYXA+IKoX6y
	mJrCJ7cwwHdXL4EX/r52I7cFoc3BVz8vxjhBt61wwC1fuGAiBv4ZMA/Fjizu
	WchrcABIisFcdgfr11tYZju1ui5sqtAp+Ii3avH+X00DWZHs4ZM+aGU/Odj8
	RJedLQb++2bWR/gyJviOlpbjnejK85NwgqhHfxmn/Sl6e/kqenH+MtqLLl5e
	vXo8kUEyTOhhcyuv3EHU/9oE5/vdE7F+/P/VXVlvG8kRfheg/zCgH2wnHHlO
	cihgHySS2jg+1rCcXeRJGIlDiTCv5ZCyvcbmt6euvmaGNHVshDBeIaJ6erqr
	q6ur6/iqH4ehTqKQGSD4wPu8Yez6BfHDZiBF9ravgZc87AWEm7B9DvCC9IEz
	KJTBt3G54QWd3S+oJahUuOhf88nXZgZSM+g+7AV9thvuWIPsIS/AZBt7Q6tk
	m5r4kYybTya3RtJudDFUCRFsnSt54Z2QXqLSbNp3SLL5caLMbDLnum5kK+GC
	TK3Xg5ZVJVTcryQgWkKhlg121HKJ1fLE7IincwAtVmT4DFOu06Gictuqi+/f
	iRAhZyCK5wRFWetjIbq8lfJAcnjCBMGkis18Q6gf5IiaIdahrUDb6uM3wXrT
	8TOiROikj5aW6HzxJwMinL0+2W7IiqMKOTZlzNPpfaVQMqF/QyzKIRrns8n0
	G4+UgWhF7WbGYOroVori2DFWUpS7VetkiSZN733/3NBZECBOF4J0tCdszUt+
	5bvJ1WpRLsZr3R+yJF1ieBBcCFxnxOr8W6GFzrXYzHlalAzpBgTuymv1zicw
	5XyFYSImvv+Hi28PVofEkRvJjFrSHdaUGs89oLlRn3cqyQz4QVhHav9M82Vb
	3G50EycwtLHXClv0PsJRII+G8jU7S1EalpLzdA+WUqXSPhcGgmKMlfREuVS4
	fcrCdWQlujHoAs6kuhfbDsfAb3q1W6oDpLYavqoLQRWaVOzP3kuhDK5mOXKN
	jVFfhZqGVsk23a2mxfuqaXave+hq2zIfPqmUMpXgq5jZ1orbsjpcVsNEl4y3
	pEDWI9iszG2JUjPKT+0iraPtdqSeYPaPFLQkfjYIRTdYI4XCZNkO7gQb06bW
	6UOilZKToFTDucqXHHOF9/IXtlXqC4UyzNAsgi4w6J7C+jG6FB0NpKNjIOVg
	UlKJGoIBkBBNne80N9i6LrgVbgSENdVFQb3bzXSuM6WaI+PUTGxSCOhnXn5j
	wKo1SoE5h+cxRyKgCRpyDg/KKaZfUhDNSN+ANcwUDp3tfvaNfKEg9g4P2EeN
	MVcbuLyVCqpPF8OykoKU95rqHLDPW5tgtU8OtQRyC3zzruHudCUGvwnf/N0I
	niVnrtww5IFePgz8L1Xk9XI1uc2veLM1JOqpYHoB7EXrG9uSJFKUHCqWv0mV
	V5KkWr1wVC65Ch5KISBibjYxyE5INcPlVSDfjjxGr67F/7E5ohK12QxnrSMa
	FLiswi60cBxxsYiGucS4zBBbLV+v0ZQCo0Y0apKlNuhvQwlGtKCbF6iqBITN
	Q5KBgUl1oICGE7TRIDnVjYodYKAAWpvL5WI+Uj4FvPZjpFhhp2qi/XPNmGuX
	Ck2FY4LWsFJjVa/OyaxCiy1s46kk9hmpYeNwwhqpMC6K2VGspWOJm9OCdF7C
	hCGhy5t8WVAeAJ+KNzLR2wSvbOQNSGD9DH+JBZPvuMwEoA13wjSUZcYr3Tax
	ydxB7XuJtOcLlJFszhMihk+udFQ9222+P6t+pWtF5Jv1DTrjrtFnw3GluWmr
	st44an8iRRU+on/hPJ/+0YYNDP8/L6beO7TvYGL84cEpEKUPnAVn81R+/ZjP
	ygIjEs6A9xfe28ksh19+Xsz/yOG8h65gX0xWC+yPstGBRxezEk4p+GKzWsFB
	fX7kvdmApFnlX7Cfj1xlGzP7Jtjq4+LS+20yXdMj5wX84W2xmMOx0aZpLka4
	m/4NvF8+X3BzONa8N5OCArTwkdU1HCMfVovPQI5i/hlbvZ0syjccIlySMY+Y
	bTo1OYvK9IsXL2MFJK1y7v08Wf9jc4mCEtjTUBEFhqq6A6fKppTcQStVzLJS
	O3ZS92Y3Alpg7eD8dmJAFpVSVXeAqnj2T9A7ksEERauSYxxjgqe9lfUn/Zr4
	GAre0mDFHOXLEEHQejnNryegY/1hRCpeYshH+EVKDqH4KTe4yeDLF0hPytWy
	4MMUqgldEKgG+BL5nMUmLIwoooyI8lsh6AvlQnOxhiaCv+CvK8EQEqxVfw16
	FBeYQ3bOp2PggCNvOL8upiXwM/Ct98/FDTBRvpqBHLph2+GHHLoCzlwtMU4G
	eGUMwhwoq1odHnzJBR6VfEMblUuBwcfFLZchICIYkeO9Pv/l1ethX1zkvu97
	aEDmjfwJLYW/cmQwbGInUBhb0DWqBrfvYTtP2jnQyYSB0AkoVEIfAMde8DUc
	9ntJmPSjODo5DYLDgxdhnHWSLA3SJAr489L7BIfXKIe7z1lxudqgMyiK2lhg
	PPKi4wj/HXFT78M77+d3n/wgPcbOtg60NjaNMMGQ7xdl8bt4wDFa9Aihgwze
	nXFeVaquusVQzpwipzpcvn23eHhyGDnlAqjCuhXa757hCNWEIS88N4WxwU8G
	X3vDzulg2B8OsqTD8B6M8Y/9w1/PzF+1Rs9pDVQ9XSM7EdwT9yybrcOFTMlI
	5ZZw88IgADFjrGIV2H/YVaJCMvywiDYtbfB9RmO0ksMOD/4DH/IZI89aL1jw
	OH4Zj4F0x8TQGD6pEdRhRD6hjoN2cYsGdxXAT3EpUvioWC6u0CSTRX4Y+GHq
	BcEx/cMWKuqX3iMte93AD0L457TEYV1gs4sFDcf7CQgdhJdROBpFwOxhgnwL
	cwyjKOxFvSgL1If3Ir1CyPveFBHVGtmxbvT+/HiPrVLZI/zsRSe5gBdcAFVw
	fGFn0ImjoB8PkkG/L+PrJGmadrt6XzoDfN9Q3hQXwqwKEd200sTXRIIG/P4X
	7ohewR9e/r1KR373b4vV5+OGHhoGy900UbmBBA1iyK8/+vJvoSICeRIbRlIT
	cUTKWufMy2SIFLOoJYLNWnsfOMcIeZ6tpM+eeUOTNKLTqRjB6vsz0gzDC7mz
	/qk2Dcn7fT9YChw9/PShqDvZt3fqQ8PDeF4cwY/gqxH69LfZBF8RduhvSDGK
	/NMW5IS+D6UxgbdiCVyPKQxtc9OWvr4MoWctzaFxwt+GbXgk7mdcEEL1nvFr
	LQF41/lRlQb6hFF2ZwIj93iKIj5O3w9hXv4pjNR3h1XlFFlyxQYW4+xgkdhl
	kdhiETJ4wu2AUz5Ej0MpX0ki+v79Np6NUgSj00i+iHXWgDikxCW52loVZEyE
	FOIQbBNNMoO7kNKbUFGzvMcGeUGPgp5ha5Dy6IPoGUv2ZAWqgfJyvkj/eLgo
	jwa+S9so6cZ0G9+ijFqJnYkJb6ZHsHzH3l6gbvzcseMUqdDhTjzjsA+sltuz
	l47GSZhlYZwXoyAN0yTLu9E4yeG4uRoHvcLiosnop+e0kM8dhoo100Dvzx8u
	Oe4tOGBkst1lk9pzc2QEi4iYHxFxwhICKOBICCMgsClLpQ5/GQQoH2rkutOQ
	jSy4tyhQk/Rxln4ME/AzGJS/cxF5H2xbx5pg4Kdxq98UXzlwIy9vjl0O4gEg
	D/lJfQC/SgnfX4G2v8BSYCkt4PKv8vHpxzv88V79qj6yVyuMW3vznlPnjbpt
	6jhMHKLa++UOyZi4kjFxJCOIQGmkUjVJiTYpIVbaJhxlUinWFOMjm5IJexZd
	F8ifYzTILJ9qHf/woBf2wiA766bRIIxBG0tPT/pnWdIdnMLpkJ1kR55VzHCu
	olKRgxjH1YhTigkpb9DxxBIzsSTmY8vMpEFm3nEHPFhmMLUvcnOwEy3HQMtR
	2CAzEv3IpZYZQPEtMkOaXhmZQToFXJ/HsDyjS1ye/K77/hFkhpqkj7P0E5iA
	34NB+e6o3I2TNMmM5EcyQ8I1gG+d7WtTmTi2RhLzoCNv3JHjo35aH/lfIWzu
	RbMmYZPYwuaVI2w8Jt0WeZO68iataGJsd91DF0vLmzx8emUsfXxlzGSYo4x7
	hcbLfIX2Q9vrz3TiGYokSv8ftDfewTR6p/+oGHU6aXdU9KJu0sku07QII/gm
	z/Ii7+RRNCqKuIjTKnMSG7ismWquo9c8gjJ3f8mMo3PVOXuiTVe+VB5yFDog
	yLYrHzV2VToSzxX6PcH1Ts3Ux6n6KczB78GofHdYleVsks/pj+Qzb4aaVucO
	ALnKT6sD8A1j/RXydj8aDNQWr3fwo4+/dWM0Se10h9Qm0mlZo/xf1xTOvl19
	7LjivPOItpcHGl941ynrizJLOdYXZX5BO4S7F2Uzdty+ZDeSEcfejc0WmN0m
	mMe1wdx/lyrC+EgEv4PmmH2NMJ3t+3ILt3Rdbuk63ELqvbpnSHPLxaK8GOSH
	xoh/iZgzJmljaWfn+gzrozVZaenKYDwPjDHDNnZUdkGRVrXeQUHGcx8faPZ6
	SJ6q8fKX+7lvHLO0SeqViBo0mXfPomgYdXundXM0U/ipdtcGrcfr8mJWaia2
	R9u4kbqassKt9G2/H2/dSEJ9+jgHW9ZPBv0A/9eNe9nZU+wZNV0f5+t3YRp+
	D4blu+Nq3DPdHYZL77XSFhFmS9qhQxK4T+2UUvRkTmNnDFYBYkHPN4JmTexe
	1GMKRByj9ijpDBMm8D+MK1R1JwT6WCIsMgmFEIAFWI9XFA+Gtb0pkMqFluQw
	bYqvPNK4NPxuhpMlPyLnnpDvaSWVbMUnuZpcLyixcc0FRNpchIjjNtkxrNJ+
	4C2LJfuwBT/SVA6sOvT5tZTDfg1zPXLDMay8aJ1Fjd8b1Odv6BlXoblAHAOz
	AxS+UXXMFWYJIwnpXKSmFLgmuZiJXHxhMvBeKiGZVS0yjojM9hCRtrOyWVKG
	6LLUIrKNeJrzK5VRpv2326oPtEmWULRFRbKyD5yCWZiLRLTKL5cCmFQWaw29
	pm5E9JzlqCwZq1g0Eh2JqpprX3GmhbK6T1FPKMXRHanxiyjIVXprqwFdEUj/
	Tml/Z0lfc9Q3SPsoyXrD3skgGg6j4Tb/o/cCl8kv18VSitQ8jbVJr6S+0lij
	b7A2ZfoRY20aBtusTWolKhZq0FLiaJCedXphFvaD/721SU3Sx1n6GUwAfvR7
	vjuqRpmfGZlv8lmaZP0OPVtLCJPUW5cQF/hHRriRaAnJm6/n13N5aFN0HqNz
	GY+zoRqrqrBQARhW4ZAwOLIx6PoDDurkvPiCta3rvd4DlqtNLWJp+mZYbwib
	D5vhQUX4zuZ1pmC7PoPU098Kjvs60WOxav8pKmox/GeDNSqDazg8x+C6efMZ
	LM9QaBYVdZhoPCgOXFIVHEygp0KHdFcP6C2ooRUMfymGY85UznawjiOLJTTW
	noG2kkx2RQQEzMAsQhwG3QdN2PvdDWUZ3+wVnZ7AXEbrahvMMstgxiU8ESOL
	ypyvOdFJEIgbmJe4aSk5DVxFjo45BzCuhLO4XSkYoCP7iYE5Okqq0BGanNpr
	ArXD6Cn56rpYHdlqf92wx5ryPa179HlEE58SnkL348OD9CpMOpdhEl+lUZKP
	R704y+NuOgpG43B8Oe6MizDKO51LOPbG3WjcCdOsm0KjbpGG4/iqZpWWHfd8
	i6SFF+Nfn9CRWzsmbQrseUwCne52TFaI+gSOXJmkj7P0M5iAjyvtu6OqLKUt
	GrYtqFWsXG3m7Uco939SHU7SOBz/x6x3uq8ZsL8vBQb7mfr2GFuFlk1mv+xO
	Zj8krWP4GxKCHMFUWkJzVyYpJru9xTyDE6eCJGVLqVdQQkHdFWyOJZCGFKOK
	yImSk0l9njp9Nh0Jdq/LRTlZW5HfqjTFQiy862Juuu67w5VEOPIiETKXvPAV
	bkkTFtvY1cDpSlO4TVGf+IQ6LjWYKBwt1/RGRSHLCwb9/hepcOh1yK0BAA==
			<!-- [rfced] Terminology: Please review the following terminology
			questions/comments and let us know how you'd like to proceed.
			a) Please review the following similar terms and let us know if/how
			any of them can be made consistent throughout.
			bit-length counter
			a counter bit-length (other uses of bit length as a noun are not hyphenated)
			fixed bit-length counter
			fixed-length counter method
			fixed-length dedicated counters
			b) We have updated to use "dot notation" (no hyphen) to match use in
			past RFCs. Please let us know any objections.
			c) For the following terms, may we update to use the form on the right
			to make these terms appear consistent throughout the text?
			namespace ID value > Namespace ID value
			namespace IDs > Namespace IDs
			node ID and node identifier > Node ID
			d) For instances of "Name "www.example.com"", is it intentional to
			capitalize "Name"? We ask because this is the only instance where
			"Name" is capitalized.
			e) Please review the use of the following terms with regard to
			capitalization:
			Gregorian epoch
			Epoch time-based
			Unix Epoch timestamp vs. Unix epoch timestamp
			custom timestamp epoch
			Gregorian epoch
			Please consider epoch vs. Epoch and let us know if/how you'd like to
			update for consistency. Please note that the pseudocode may be
			impacted by this choice.
			f) Please let us know if the slashes in the following terms can be
			updated to "and", "or", or "and/or" for clarity.
			application/language
			format/components
			formatting/encoding
			sub-typing/versioning mechanisms
			unicast/multicast
			-->
			<!-- [rfced] Sourcecode / Artwork
			a) We see type="code" was used for the sourcecode element in Appendix
			A. We have updated to use "pseudocode". If this is incorrect, please
			let us know.
			See https://www.rfc-editor.org/materials/sourcecode-types.txt for the
			list of available types if necessary. If the current list does not
			contain an applicable type, feel free to suggest additions for
			consideration. (Note that it is also acceptable to leave the "type"
			attribute not set.)
			b) In addition, please review each artwork element. Specifically,
			should any artwork element be tagged as sourcecode or another element?
			-->
			<!--[rfced] Please review the following expansions we have added for
			abbreviations used throughout the document. Please let us know
			if you would like to add any of these abbreviations to the
			abbreviations list in Section 3.2.
			NCS - Network Control Signaling
			-->
			<!--[rfced] Please review the "Inclusive Language" portion of the
			online Style Guide
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed.
			In addition, please consider whether "tradition" should be updated for
			clarity. While the NIST website
			<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
			uthor-instructions#table1>
			indicates that this term is potentially biased, it is also ambiguous.
			"Tradition" is a subjective term, as it is not the same for everyone.
			Current:
			Low Impact:
			A UUID collision generated a duplicate log entry, which results in
			incorrect statistics derived from the data. Implementations that
			are not negatively affected by collisions may continue with the
			entropy and uniqueness provided by the traditional UUID format.
	-->		-->
	</rfc>		</rfc>
End of changes. 324 change blocks.
	3339 lines changed or deleted		2303 lines changed or added
This html diff was produced by rfcdiff 1.48.