Subject: RE: LCUP Issue: UUID

From: "Liben, Michael (GTS)" <[email-masked]>
Date: Tue, 3 Sep 2002 13:37:36 -0400

My vote is to leave it as directory string. I do not see any significant server-side benefit from storing as an octet string. And a directory string is far easier to debug.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2002 12:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: LCUP Issue: UUID

The syntax of UUID is directory string, and moreover, the matching rule
is case ignore match. I see this as overly limiting and suggest that the
syntax be changed to octet string. This is made even more apparent by
the fact that this document leaves standardization of the value
generation to a future specification.

---

From: "Liben, Michael (GTS)" <[email-masked]>
Date: Wed, 4 Sep 2002 09:18:57 -0400

I don't think specifying a UUID algorithm is necessary. If the durn thing is universally unique--as its name implies--then specifying the algorithm should be irrelevant. 

Specifying a 'well-defined sting representation' would be exremely useful.

Mike

-----Original Message-----
From: Steven Legg [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2002 2:31 AM
To: 'John McMeeking'; [email-masked]
Subject: RE: LCUP Issue: UUID

John,

John McMeeking wrote:
> I think that some reasonable uses of the attribute warrant a string
> representation.  For example, an application may want to search for an
> entry with a specific entryuuid.  And some LDUP conflict resolution
> procedures call for renaming an entry to have a DN like 
> "cn=some value +
> entryuuid=xxxx".  Constructing such search filters and DNs is 
> much cleaner
> if entryuuid has a string syntax.

I agree.

> Granted, a well-written application
> should be able to construct search filters and DNs containing binary
> values.  Case ignore match may be too restrictive.

The allComponentsMatch matching rule, already referenced by URP,
performs a character by character code-point comparison when applied
to a string type (there are some caveats on DirectoryString).
This avoids all the letter case, white-space and other normalization
that comes with caseIgnoreMatch and caseExactMatch.

> Certainly, there is no
> reason why an application can't use the entry uuid in the 
> case provided by
> the originating server.
> 
> That aside, don't we have to define what an entry uuid looks 
> like?

Yes.

> A maximum size would probably be helpful to 
> server vendors so
> as to not have to provide a search and storage mechanism (DB table for
> example) that has to support arbirary length values generated by other
> servers.

Speaking as a vendor, I already support arbitrary length attribute values.
A maximum size for entry uuids would be an irritation rather than an
advantage to me.

> Just to get things started, I propose that we use the DCE 
> UUID algorithms,
> which have a well defined string representation.  And we 
> should be able to
> define a entryuuid syntax with a string representation, which 
> is probably a
> bit cleaner than using "directory string" or "octet string."

What character set does the DCE algorithm use ? Would PrintableString
or IA5String be sufficient ? Otherwise we can just define an LDAP syntax
OID for UTF8String.

Regards,
Steven

---

From: John McMeeking <[email-masked]>
Date: Wed, 4 Sep 2002 10:00:37 -0500

Michael,

If the UUID has to be unique across all entries on all servers (as required
by LDUP), then you do need to have an algorithm or combination of algorithm
and value.  As single server could use any algorithm it wants and guarantee
uniqueness across all entries on that server.  It cannot guarantee that any
given value it generates does not conflict with a value generated on
another server using the same or different algorithm.

Even if the algorithm generates universally unique values (the DCE UUID
algorithm, for example), those values are unique only if everyone uses the
same algorithm.  The "foo" algorithm could generate universally unique
values, but if it happens to generate values that are the same size as DCE
UUIDs, they will eventually collide.

John  McMeeking

                      "Liben, Michael                                                                                        
                      (GTS)"                   To:       "[email-masked]'" <[email-masked]>, John     
                      <mliben@exchange.         McMeeking/Rochester/IBM@IBMUS, [email-masked]                             
                      ml.com>                  cc:                                                                           
                      Sent by: owner-          Subject:  RE: LCUP Issue: UUID                                                
                      ietf-ldup@mail.                                                                                        
                      imc.org                                                                                                

                      09/04/2002 08:18                                                                                       
                      AM                                                                                                     

I don't think specifying a UUID algorithm is necessary. If the durn thing
is universally unique--as its name implies--then specifying the algorithm
should be irrelevant.

Mike

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 2:31 AM
To: 'John McMeeking'; [email-masked]
Subject: RE: LCUP Issue: UUID

John,

I agree.

Yes.

Regards,
Steven

---

From: "Liben, Michael (GTS)" <[email-masked]>
Date: Wed, 4 Sep 2002 15:25:44 -0400

The UUID only needs to be unique in the DIT in which it has meaning (the context). As long as the server(s) holding the DIT create the UUID using a consistent algorithm (server-assigned per the spec),
we shouldn't care which algorithm is employed. Combined with a server-assigned LCUP cookie, the opportunity of collision is academic at best. 

-----Original Message-----
From: John McMeeking [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2002 11:01 AM
To: Liben, Michael (GTS)
Cc: [email-masked]; [email-masked]; [email-masked]'
Subject: RE: LCUP Issue: UUID

Michael,

John  McMeeking

                      "Liben, Michael                                                                                        

                      09/04/2002 08:18                                                                                       
                      AM                                                                                                     

Mike

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 2:31 AM
To: 'John McMeeking'; [email-masked]
Subject: RE: LCUP Issue: UUID

John,

I agree.

Yes.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Sep 2002 12:54:08 -0700

At 12:25 PM 2002-09-04, Liben, Michael (GTS) wrote:
>The UUID only needs to be unique in the DIT in which it has meaning (the context).

LDAP and X.500 are designed to support a global DIT.

>As long as the server(s) holding the DIT create the UUID using a consistent algorithm (server-assigned per the spec),
>we shouldn't care which algorithm is employed.

Consider a server which masters one context and shadows a subordinate
context.  UUIDs in the spanning LCUP context must be unique.  This
requires that both servers (this one and the own who masters the
shadowed context) need to agree on the algorithm to be employed.
To ensure interoperability, a standard algorithm should be implemented
by both.  A REQUIRED algorithm is needed.

In my opinion, UUIDs in LDAP should conform to ISO/IEC 11578:1996.

>Combined with a server-assigned LCUP cookie, the opportunity of collision is academic at best. 

If entryUUID were only to be used by LCUP, I might agree
with you.  But I believe the desire is to define entryUUID
so that they have broader applicability.  (Which is one of
the reasons why I believe entryUUID and entryCSN should be
detailed in a separate document.)

Kurt

---

From: "Liben, Michael (GTS)" <[email-masked]>
Date: Wed, 4 Sep 2002 16:07:21 -0400

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2002 3:54 PM
To: Liben, Michael (GTS)
Cc: 'John McMeeking'; Liben, Michael (GTS); [email-masked]; [email-masked]; [email-masked]'
Subject: RE: LCUP Issue: UUID

>LDAP and X.500 are designed to support a global DIT.

Is that a global DIT or a global namespace? I believe the DIT would be appropriately partitioned into administrative contexts.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Sep 2002 13:30:51 -0700

At 01:07 PM 2002-09-04, Liben, Michael (GTS) wrote:
>Is that a global DIT or a global namespace?

Global DIT.

>I believe the DIT would be appropriately partitioned into administrative contexts.

The global DIT can be appropriately partitioned into
administrative contexts. 

Bring this back to UUIDs... the universe of an entry
UUIDs is the global DIT.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 04 Sep 2002 21:28:33 -0600

I agree. if the attribute is called entryUUID it should be unique within
the universe of the global DIT. Otherwise, call it an lcupUID.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 09/04/02 01:54PM >>>

>As long as the server(s) holding the DIT create the UUID using a
consistent algorithm (server-assigned per the spec),

Kurt

---

From: "Liben, Michael (GTS)" <[email-masked]>
Date: Thu, 5 Sep 2002 12:18:44 -0400

Now I understand. Your desire is for a unique identifier in the universal namespace--the (currently) 128 bit namespace known as a UUID/GUID. I believe this poses a rather significant challenge. 

Most algorithms depend on an IEEE 802.1 node address--commonly referred to as a MAC address--as a unique value. In theory, this is spatially unique. In practice, it is not.

IP networks over Ethernet have emerged as the dominant network combination. These networks do not depend on the universal uniqueness of the node address. The node address need only be unique on the
Ethernet router segment. In our 100,000 node network, we currently have at least 30 cases of multiple host instances 'sharing' node addresses, most courtesy of VM-Ware. Similarly, every LPAR on a
mainframe utilizes the same small handful of available network nodes. Highly reconfigurable systems, such as the Unisys ES7000 series, can freely associate up to 96 PCI channels with any of up to 8
independent partitions, each running a different OS.

We regularly acquire Sun machines with quad network cards. By default, all four ports are configured with the same node address. Very often, each of these nodes is connected to a separate IP/Ethernet
segment so the namespace collision is irrelevant. The node address can be overridden in software when necessary.

In a nutshell, I believe the node address component is no longer sufficient to guarantee uniqueness of a uuid.

Mike Liben

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Wednesday, September 04, 2002 4:31 PM
To: Liben, Michael (GTS)
Cc: Liben, Michael (GTS); 'John McMeeking'; Liben, Michael (GTS); [email-masked]; [email-masked]; [email-masked]'
Subject: RE: LCUP Issue: UUID

Global DIT.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Sep 2002 09:42:22 -0700

>In a nutshell, I believe the node address component is no longer sufficient to guarantee uniqueness of a uuid.

By itself, yes...  however, I believe ISO/IEC 11578:1996
adequately addresses this very old UUID issue.

Kurt