Subject: Re: entryUUID

From: "John McMeeking" <[email-masked]>
Date: Mon, 9 Apr 2001 07:36:07 -0500

I don't think that we need the full DCE UUID specification.  Something like
the following ought to work:

EntryUUID is a 16-byte structure defined as:
server-generated ID - 80 bits
IEEE adapter address -- 48 bits

server-generated ID: This field uniquely identifies an entry across all
entries created on a single DSA.  If an entry is deleted, and another entry
later created with the same DN, a different server-generated ID shall be
assigned to the entry.  The algorithm for generating this value is
implementation defined.  A server could generated this value using the
system clock, a counter, or other means.

IEEE adapter adress: This field contains one of the 48-bit IEEE adapter
addresses for this server.  If an adapter address is not available, an
implementation must use a fake adapter address with the first bit (the
multi-cast address bit) set to 1.  A fake adapter address must be unique
across all servers that an entry could be present on.  For example, in a
multi-master replication environment, the address must be unique across all
servers to which the entry is replicated, or a value may need to be unique
across a corporate intranet.  The algorithm for generating a fake adapter
addres is implementation defined, but could be based on data such as the
system name, IP address, or system clock; the adapter address could be
assigned by an administrator.

The combination of server-generated ID and IEEE adapter address ensures
that an entryUUID is unique across all entries on all server.

An example of a widely known algorithm that generates UUIDs like this is
the DCE entry UUID algorithm used for remote remote procedure calls.

EntryUUID has applications outside of replication.  It might be best to
have a separate I-D for just entryUUID.  Two examples of things that could
use entryUUID without replication being present:

- an application that needs to be able to distinguish between two instances
of an entry with the same distinguished name; for example, to distinguish
between "cn=my data" created today, and a future "cn=my data" created two
weeks from now after deleting the existing "cn=my data".  Depending on the
nature of the application, it may be a requirement that the server generate
such values to ensure that a client can not recreate the entry with a
previously used entryUUID.

- a LDAP event notification model that notifies a client of changes to a
DIT subtree in which the client may not be authorized to all entries.  A
server could include the entryUUID in the event notification without
needing to first determine if a client was authorized to the particular
entry.  This is useful in cases where the DN might contain information a
client is not authorized to.

John  McMeeking
[email-masked]
(507)253-4596

"Ed Reed" <[email-masked]>@mail.imc.org on 04/06/2001 11:14:29 AM

Sent by:  [email-masked]

To:   <[email-masked]>, Timothy Hahn/Endicott/IBM@IBMUS
cc:
Fax to:
Subject:  Re: entryUUID

Tim - it's within the proper scope of draft-ietf-ldup-infomod.  ;-)

The value UUIDs and the entryUUID are described there, and are
intended to conform to, the DCE UUID specification used in
DCE (duh) and the corresponding ISO RPC specification.  Generating
an RFC that describes them without treading on copyright
restrictions has hindered publication of an RFC for that purpose to
date, but that's what's intended by LDUP.  Its syntax should be
octet string, in my opinion.

Ed

>>> "Timothy Hahn" <[email-masked]> 04/06/01 08:23AM >>>
Hello all,

We have found a need to use the proposed attribute: entryUUID prior to a
full definition of LDUP replication models.

Has anyone crisply defined this attribute, including an OID?

Would anyone like to do so so that applications could use this definition
prior to having an LDUP set of RFCs?

The alternative could be that each implementation/vendor defines their own
in the mean-time ... not necessarily with the same format.

Does anyone out there care?

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 10 Apr 2001 11:36:56 +1000

John,

A long time ago I suggested that the format for the entry unique identifier
should be prefixed with a mechanism type so that a variety of schemes could
be used. Type 0 could be the full DCE UUID form, type 1 could be a simpler
scheme such as you describe below, and so on. I would find an object
identifier
form particularly useful. The only requirement on the unique identifier is
that it is a globally unique sequence of octets. Servers can compare UUIDs
as OCTET STRINGs using octetStringMatch without regard to which mechanism
was used to generate them. A server only needs to know one of the possible
mechanisms to generate UUIDs. It doesn't need to know any other current or
future defined mechanism. We need to standardize the type numbers and their
corresponding mechanisms of course, but that's no big deal.

Regards,
Steven

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of John McMeeking
> Sent: Monday, 9 April 2001 22:36
> To: Ed Reed
> Cc: [email-masked]; Timothy Hahn
> Subject: Re: entryUUID
>
>
>
>