[389-devel] USN Design Document

[Andrey Ivanov]

I've seen some changes in the USN design document, so i'll add my two
cents. Overall it's well written, the architecture seems to be rather
robust.  There are some scenarious that are interesting for us as for
the behaviour of the usn plugin and some questions/reflections :

* The USNs seem to be unique within a suffix/backend. Should we enable
the uniqueness plug-in for them? If not can we be sure that a manual
change of entryUSN will not interfere with the correct functioning of
the plug-in?
* When the plug-in is activated no entry has entryUSN or maybe some
entries do already have it in some desorder. Maybe we should
initialise (while plug-in in started for the VERY first time) all the
entries without entryUSN with entryUSN=-1 or smth like that?
* Maybe it's a good idea to desactivate the replication of entryUSN
attribute during the server installation by default?
* When we do an export with a utility like db2ldif.pl - should the
entryUSN attributes be exported or not?
* What happens during the import of a whole ldif subtree by smth like
"ldif2db -n userRoot -i /tmp/current_prod_database.ldif"  if the
entryUSNs are already present in the imported ldif? If they are not
present? if they are present only in a part of the entries?
* Should usn-tombstone-cleanup be integrated in the server core with
the thread purging the tombstones ot not? Should it be configurable bo
some attributes like nsds5ReplicaPurgeDelay and
nsds5ReplicaTombstonePurgeInterval?

And thank you for your work!