ldup urp draft comments

[merrells@xxxxxxxxxxxx (John Merrells)]

Here's some feedback on the URP draft...

1) At first I didn't realise why the distinguished-present and
   distinguished-not-present tags were needed.  There is a paragraph
   which explains this. But, I didn't really get it until I worked
   out the example I mailed out earlier.

2) In the Unique Identifier section it states that both the root and
   lost+found entries will have pre-allocated known UUIDs.  This 
   seems like an implementation detail.

3) The draft states that a replication log will maintaned. The LDUP
   architecture delibrately avoids saying how or where updates should
   be stored.  This is implementation defined.

4) I like the idea of creating a glue entry under the lost+found 
   entry to represent an entry that has been deleted and it's 
   children have become orphaned.  This make it much easier for
   the administrator to recover a whole subtree.

5) The document describes how each LDAP operation is broken down
   into primitives, and provides an algorithm for how each primitive
   is applied to the consumer.  But, I think there's some subtle
   things hidden in the code, which should be explained:

5a) The RenameEntry function assumes that if the entry has children
    that they will move with the parent and not stay where they are.
    I know this may sound odd... but in our server, and I think some
    others, this isn't actually a natural thing to do. Stating the
    obvious here might be the best thing to do.

5b) When an entry is moved or added to the Lost+Found container the
    CheckUniqueness function is called.  This renames the RDN if it's
    found to not be unique. From an implementation point of view it
    would be better to always rename the entry, because there's no
    need to do a search. This also leads into the next point.

5c) If CheckUniqueness changes the RDN then it progagates a rename
    primitive. If we always rename the entry (as in 5b) then I don't
    think this propagation is needed as the same collision will occur
    on all servers and they will all rename the entry to have the same
    name.

One general comment is that these algorithms support Out-Of-Order
replay of changes, which is good. But, if one were to implement
a server that only supported In-Order replay, then the algorithms
can be simplified. Perhaps we should make a note of this.

Overall an excellent document. Steven, Will you be revising the 
draft for the next meeting?  Some of the terminology in the text
doesn't fit with the architecture document. I can help here if
you want.

John