Subject: [dispatch] An update on the status of the new UUID draft work

From: "Kyzer Davis (kydavis)" <[email-masked]>
Date: Mon, 24 May 2021 13:01:50 +0000

Hello Group,

Apologies for the delay but Brad and I have just re-submitted the New UUID
draft for review by the community.

In the time between version 00 and 01 we have made a tremendous effort to
bring this draft into a state which we believe is very close to being
complete.

If possible we would like to secure 5-10 minutes of the next meeting to
discuss this new draft in an effort to get more eyes on it for review and
additional feedback.

A summary of those changes are below:

- The current 01 draft is a complete rewrite from the ground up in almost
every section after the introduction
(https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01)

- The format, flow and verbiage used in the specification has been reworked
to mirror the original RFC 4122 and current IETF standards.

- This draft cuts some of the noise from the original 00 draft removing the
topics of UUID length modification, alternate UUID text formats, and
alternate UUID encoding techniques which are no longer related the scope of
this specification.

- A renewed focus on security has been applied to all sections of the draft.

- Research into 16 different historical and current implementations of
time-based universal identifiers was completed at the end of 2020 in attempt
to identify trends which have directly influenced design decisions in this
draft document
(https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)

- The specification is now comprised of three new UUID versions based on the
research and solutions to the problem we are trying to solve with this
draft. Section 3. Summary of Changes discussed these three versions but in
short: 

   + UUIDv6 aims to be the easiest to implement for those already utilizing
RFC 4122 UUIDv1 and keeps everything except the timestamp as-is.

   + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as the
timestamp and other techniques for sub-second precision encoding, timestamp
and other bit layouts

   + UUIDv8 offers a relaxed time-based UUID which caters to implementations
that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one reason or another.
This also future-proofs this specification by allowing time-based UUID
formats from timestamp sources that are not yet defined.

- Prototype implementation have been completed for UUIDv6, UUIDv7, and
UUIDv8 in various languages by many GitHub community members.
(https://github.com/uuid6/prototypes)

- We have also received and implemented lots of great feedback from the
community on GitHub who are eager implement the final RFC into their
products assuming we can get this to that point.
(https://github.com/uuid6/uuid6-ietf-draft)

Thanks,

---

Kyzer Davis

---

From: Tim Bray <[email-masked]>
Date: Mon, 24 May 2021 09:48:01 -0700

Haven't been following this discussion so I may be covering well-traveled
ground, but, wanted to say that over the last few years a few system
designs have crossed my desk where such a thing would be useful.

Should this be adopted as a work item, I'd probably argue for fairly
massive simplification and removal of options; I'm hard-put to think of a
case where someone using this is going to care about compatibility with
existing sub-UUID structures, they just want a 128-bit key with the
properties this offers.  Not obvious that the rich 6/7/8 options really add
that much value. Assume a millisecond clock, add an absurd number of
sub-click sequence bits (you don't have to use them all) and you still have
lots of randomness bits left.

On Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) <kydavis=
[email-masked]> wrote:

> every section after the introduction (
> https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01)
>
> - The format, flow and verbiage used in the specification has been
> reworked to mirror the original RFC 4122 and current IETF standards.
>
> - This draft cuts some of the noise from the original 00 draft removing
> the topics of UUID length modification, alternate UUID text formats, and
> time-based universal identifiers was completed at the end of 2020 in
> attempt to identify trends which have directly influenced design decisions
> in this draft document (
> https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)
>
> - The specification is now comprised of three new UUID versions based on
> the research and solutions to the problem we are trying to solve with this
>    + UUIDv6 aims to be the easiest to implement for those already
> utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp as-is.
>
>    + UUIDv8 offers a relaxed time-based UUID which caters to
> implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one
> reason or another. This also future-proofs this specification by allowing
> time-based UUID formats from timestamp sources that are not yet defined.
>
> UUIDv8 in various languages by many GitHub community members. (
> https://github.com/uuid6/prototypes)
>
> products assuming we can get this to that point. (
> https://github.com/uuid6/uuid6-ietf-draft)
>
>
>
> Thanks,
>
>
>
> ---
>
> Kyzer Davis
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Kyzer Davis (kydavis)" <[email-masked]>
Date: Mon, 24 May 2021 17:45:23 +0000

Thanks for the input Tim!

To be honest 6/7/8 are pretty similar under the hood. The main different being the timestamp usage (Gregorian, Unix, and any other type).

v7 of our specification describes exactly what you are detailing while v6 was included with idea that systems with v1 only need to copy and change a few lines of code to implement.

Meanwhile v8 is an even more laid back approach which lays out some example creation scenarios. Otherwise all 128 bits of v8 are of use for the application implementation while still being a “Spec based UUID”.

Lastly, there are some best practices included from our prototype testing and research within each of these three versions.

All three of these are all made up of the same core components: Timestamp Data, Clock Sequence Counter, Random or application specific Data (defined as the Node in the specification) along with static UUID version/variants bits.

Thanks,

From: Tim Bray <[email-masked]> 
Sent: Monday, May 24, 2021 12:48 PM
To: Kyzer Davis (kydavis) <[email-masked]>
Cc: [email-masked]; Brad Peabody <[email-masked]>
Subject: Re: [dispatch] An update on the status of the new UUID draft work

Haven't been following this discussion so I may be covering well-traveled ground, but, wanted to say that over the last few years a few system designs have crossed my desk where such a thing would be useful.

Should this be adopted as a work item, I'd probably argue for fairly massive simplification and removal of options; I'm hard-put to think of a case where someone using this is going to care about compatibility with existing sub-UUID structures, they just want a 128-bit key with the properties this offers.  Not obvious that the rich 6/7/8 options really add that much value. Assume a millisecond clock, add an absurd number of sub-click sequence bits (you don't have to use them all) and you still have lots of randomness bits left.

On Mon, May 24, 2021 at 8:35 AM Kyzer Davis (kydavis) <kydavis=[email-masked] <mailto:[email-masked]> > wrote:

Hello Group,

Apologies for the delay but Brad and I have just re-submitted the New UUID draft for review by the community.

In the time between version 00 and 01 we have made a tremendous effort to bring this draft into a state which we believe is very close to being complete.

If possible we would like to secure 5-10 minutes of the next meeting to discuss this new draft in an effort to get more eyes on it for review and additional feedback.

- The current 01 draft is a complete rewrite from the ground up in almost every section after the introduction (https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-01)

- The format, flow and verbiage used in the specification has been reworked to mirror the original RFC 4122 and current IETF standards.

- This draft cuts some of the noise from the original 00 draft removing the topics of UUID length modification, alternate UUID text formats, and alternate UUID encoding techniques which are no longer related the scope of this specification.

- Research into 16 different historical and current implementations of time-based universal identifiers was completed at the end of 2020 in attempt to identify trends which have directly influenced design decisions in this draft document (https://github.com/uuid6/uuid6-ietf-draft/tree/master/research)

- The specification is now comprised of three new UUID versions based on the research and solutions to the problem we are trying to solve with this draft. Section 3. Summary of Changes discussed these three versions but in short: 

   + UUIDv6 aims to be the easiest to implement for those already utilizing RFC 4122 UUIDv1 and keeps everything except the timestamp as-is.

   + UUIDv7 is a fresh take on a time-based UUID with Unix Epoch as the timestamp and other techniques for sub-second precision encoding, timestamp and other bit layouts

   + UUIDv8 offers a relaxed time-based UUID which caters to implementations that cannot utilize UUIDv1, UUIDv6, or UUIDv7 for one reason or another. This also future-proofs this specification by allowing time-based UUID formats from timestamp sources that are not yet defined.

- Prototype implementation have been completed for UUIDv6, UUIDv7, and UUIDv8 in various languages by many GitHub community members. (https://github.com/uuid6/prototypes)

- We have also received and implemented lots of great feedback from the community on GitHub who are eager implement the final RFC into their products assuming we can get this to that point. (https://github.com/uuid6/uuid6-ietf-draft)

Thanks,

---

Kyzer Davis

_______________________________________________
dispatch mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/dispatch