The background section gives reasons derived from looking at existing implementations. --- Due to the shortcomings of UUIDv1 and UUIDv4 details so far, many w

The background section gives reasons derived from looking at existing implementations. --- Due to the shortcomings of UUIDv1 and UUIDv4 details so far, many widely distributed database applications and large application vendors have sought to solve the problem of creating a better time- based, sortable unique identifier for use as a database key. This has lead to numerous implementations over the past 10+ years solving the same problem in slightly different ways. - Timestamps MUST be k-sortable. That is, values within or close to the same timestamp are ordered properly by sorting algorithms. - Timestamps SHOULD be big-endian with the most-significant bits of the time embedded as-is without reordering. - Timestamps SHOULD utilize millisecond precision and Unix Epoch as timestamp source. Although, there is some variation to this among implementations depending on the application requirements. - The ID format SHOULD be Lexicographically sortable while in the textual representation. - IDs MUST ensure proper embedded sequencing to facilitate sorting when multiple UUIDs are created during a given timestamp. - IDs MUST NOT require unique network identifiers as part of achieving uniqueness. - Distributed nodes MUST be able to create collision resistant Unique IDs without a consulting a centralized resource.