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=
40cisco.com@dmarc.ietf.org> 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.
>
>
>
> 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
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>