Re: UUID version 6 proposal, initial feedback

"Theodore Y. Ts'o" <tytso@mit.edu> Sat, 01 February 2020 22:04 UTC

Return-Path: <tytso@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82448120103 for <ietf@ietfa.amsl.com>; Sat, 1 Feb 2020 14:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5hBUs-THQNT for <ietf@ietfa.amsl.com>; Sat, 1 Feb 2020 14:04:00 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B861512004A for <ietf@ietf.org>; Sat, 1 Feb 2020 14:04:00 -0800 (PST)
Received: from callcc.thunk.org (75-104-86-204.mobility.exede.net [75.104.86.204] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 011M3n9d022781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Feb 2020 17:03:56 -0500
Received: by callcc.thunk.org (Postfix, from userid 15806) id B67ED420324; Sat, 1 Feb 2020 17:03:48 -0500 (EST)
Date: Sat, 01 Feb 2020 17:03:48 -0500
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Brad Peabody <bradgareth@gmail.com>
Cc: IETF discussion list <ietf@ietf.org>, "Salz, Rich" <rsalz@akamai.com>
Subject: Re: UUID version 6 proposal, initial feedback
Message-ID: <20200201220348.GD528198@mit.edu>
References: <D0894516-3F20-4545-BD7D-BE4FA96FAF75@gmail.com> <CABkgnnXSxqqinyK4QiwVv-VuzAraHFUGCrm0K0e9dJX_F80bWg@mail.gmail.com> <D3517A2C-1FCC-42D2-9AB6-248680BE89E1@gmail.com> <c5ba6f5d-7c61-bfdf-63e6-be7d640ee50c@gmail.com> <6E165220-7D1F-4AD8-B4F3-DDCB8F1DA6E2@akamai.com> <b4b73e11-7e21-03ae-0ebf-badcc2bf9d7e@gmail.com> <20200201060733.GD454818@mit.edu> <418aac22-5686-8877-da0f-12fce0a28d40@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <418aac22-5686-8877-da0f-12fce0a28d40@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xfDNzi-HbT3MLiJRMog5zrCeW9A>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 22:04:03 -0000

On Sat, Feb 01, 2020 at 01:29:06PM -0800, Brad Peabody wrote:
> I do need to give more thought to the uniqueness property.  One observation
> is that uniqueness guarantees can be somewhat application-specific, and
> specific cases can significantly reduce the complexity of implementation. 
> Examples: Applications deployed on a cluster where each machine already has
> a unique number can simply include that number to ensure uniqueness. 
> Applications only concerned about uniqueness in a single process can easily
> do this using the clock and a counter.

For very specialized use cases (e.g., where 16 binary bytes is too
long), I'm not sure it makes sense to create a fully general
specification which is so abstract that it becomes hard to use, since
you have to customize it for a particular application.

Past a certain point, you might as well say that you want to
standardize "b-trees" --- and that's something which belongs in an
algorithms book, and not an I-D or an RFC.

I will note that created distributed unique id's for applications
running in a cluster is very common system design interview question.
(Or at least, it used to be, until it got leaked and now there tons
and tons of pages on callicoder, topcoder, describing solutions and
how to approach it in interviews, such that at least at $WORK, it's
been blacklisted as an interview question.  :-)

So I'm not sure I'd consider it a "hard problem"; just as I'm not at
all convinced this is something that needs to be standardized.

    	      	      		     	      - Ted