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
- UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Martin Thomson
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Tony Finch
- Re: UUID version 6 proposal, initial feedback Martin Thomson
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Salz, Rich
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Salz, Rich
- Re: UUID version 6 proposal, initial feedback Keith Moore
- Re: UUID version 6 proposal, initial feedback Theodore Y. Ts'o
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Keith Moore
- Re: UUID version 6 proposal, initial feedback Theodore Y. Ts'o
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- Re: UUID version 6 proposal, initial feedback Theodore Y. Ts'o
- Re: UUID version 6 proposal, initial feedback Brad Peabody
- RE: UUID version 6 proposal, initial feedback Rob Wilton (rwilton)
- Re: UUID version 6 proposal, initial feedback Benjamin Kaduk
- UUID version 6 proposal, initial feedback Ben Ramsey
- Re: UUID version 6 proposal, initial feedback Laurence Lundblade
- Re: UUID version 6 proposal, initial feedback George Michaelson