Subject: [dispatch] UUID Version 6 Proposal

From: Brad Peabody <[email-masked]>
Date: Thu, 27 Feb 2020 22:34:29 -0800

Hi,

I recently submitted a draft proposal to update the UUID specification. 
https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

The motivation is for a UUID format (version 6) which is suited for use 
as a database key. Modern applications frequently need to create a 
unique identifier to be used as a primary key in a database table that 
is ordered by creation time, difficult to guess and has a compact text 
format.  None of the existing UUID versions fulfill each of these 
requirements.  This document is a proposal to update RFC4122 with a new 
UUID version that addresses these concerns.

I'm new to interacting with the IETF and its processes. I'd like find 
out how this can be considered/discussed and what is needed to move it 
forward.

As I understand it, there is a possibility of doing a brief presentation 
at the appropriate IETF meeting in a few weeks in Vancouver?  I would be 
interested in doing so if possible.

Best, Brad

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 28 Feb 2020 22:52:11 -0500

> https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

The proposal sounds good to me.  But upon skimming the document, I don't
see any single place where it asserts how this format of UUID is created
-- what the fields are and how their values are determined.  You talk
about it but you don't specify it.  Now I think you can do it by
referring to the figure in section 4.1.2 of RFC 4122 and detailing
exactly what goes in the fields it lists.

Dale

---

From: Rick van Rein <[email-masked]>
Date: Sat, 29 Feb 2020 10:08:56 +0100

Hello Brad,

> https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

This sounds useful to me.

> Note for discussion: Another point to consider is that there is no
> known way to fully guarantee that that duplicate identifiers will not
> be created unless some per-determined outside source of uniqueness is
> employed.

You emphasise the useful case if a database on multiple nodes; what you
could do there is this:

- Reserve a few bits for a node identity
- Position those at the high end if you care mostly for routing
- Position those at the low  end if you care mostly for time order
- The bits only reduce the time resolution (rate of UUID creation)
- You might just use order numbers instead of looking at the clock
- Adding nodes can be interpreted from a certain time/orderno onward

I don't know if this should be specified or left open.  Since it seems
like a useful general case, it might be a non-normative example, as a
guide to implementers.

I'm not convinced that more syntax is helpful; 128 bits suffice for
global uniqueness, say cryptography and the net's experience.  A dense
enough notation should make this usable, and I think effort would be
better spent towards compression.  In the example above, the node
identities might follow a variable-bits scheme to which the clock
resolution responds or, as described above, the time/orderno may help to
decide how many of the low bits count as a node identity.

The downside to more syntax is creating incompatibilities with existing
implementations; for instance, fixed-size binary representation.  You
might also create difficulties in software comparing UUIDs if a UUID
looks like it is hex-encoded while it really is a base32-encoded UUID.

If you don't try to call it a UUID you wouldn't cause such problems, and
you might then even go for variable-sized notations.  If you prefix a
simple DER header (or just its length and assume OCTET STRING) you would
even have a self-describing binary format.

I hope I'm not stretching beyond the purposes of DISPATCH by discussing
the contents of a document.  I'm new here.

I hope this helps,
-Rick