[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ldup urp draft comments
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
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