Apparently, according to slurpd's replog, no operational attrs are modified on modrdn. In fact, modrdn is replicated as a plain modrdn, which does not alter the write-related operational attrs (nor it is allowed to, according to LDIF, as per RFC 2849). Rep-logging an additional modify that only changes the write-related operational attrs could fix the problem, at the cost of not making it atomical. A "cleaner" solution would be to wrap a modify with a control that gets added to the modrdn operation by slurpd, which modifies modifiersName, modifyTimestamp and entryCSN using the "relax" control. Or, the (yet unpublished) "relax" control could be redefined to allow an optional control value that contains a modification required to maintain consistency of the final entry, or something like that.

This definitely needs investigation, but it could be considered yet another reason for dropping slurpd.

p.