Summary

  • RFC 3384 required multi-master replicas to converge, but if conflict resolution would lose directory information, the losing information also had to be stored, disclosed to an administrator and made available for possible override.
  • Arrival order could not determine eventual convergence. A stable live winner and a preserved record of disagreement were separate system obligations.

Two directory servers accept different changes to the same attribute while disconnected. When they meet again, both cannot remain the live answer if every replica must converge. One value will win. The difficult question is what happens to the other.

A simple implementation could overwrite it, celebrate convergence and erase the only evidence that a legitimate change ever existed. RFC 3384 rejected that shortcut at the requirements level. If resolving a multi-master conflict would lose directory information, the replication process had to store the information, notify an administrator about the conflict and the loss, and provide a mechanism for possible administrative override.

Published in October 2002 as an Informational RFC, the document did not define a complete LDAP replication protocol. It gathered the requirements that such an interoperable protocol would need to satisfy. This distinction matters. The document described the boundary of an acceptable design; it did not prove that a named product implemented that boundary or prescribe one universal conflict algorithm.

LDAP already standardized communication between clients and servers. Server-to-server replication remained a separate problem. Distribution could improve fault tolerance and bring directory content closer to clients, but it also introduced questions about topology, partial replicas, schema, access control, session security, replay and conflicting writes.

RFC 3384 defined an area of replication as a configurable portion of the Directory Information Tree. Areas could overlap or nest. A replica was one instance of an area, and a replica-group contained servers holding that area. Replication agreements described the parameters governing exchange: areas, access, credentials, confidentiality and propagation behaviour.

The document considered five consistency models. Transactional consistency offered the familiar ACID properties, but distributed two-phase commit imposed substantial complexity, so that model was not pursued at the time. The requirements focused on eventual consistency and limited-effort eventual consistency. In both, temporary divergence was part of the operating model rather than proof that the protocol had already failed.

Eventual did not mean arbitrary. Requirement M3 said an attribute had to converge to the same set of values in every replica holding the entry. Multi-master requirement MM6 repeated the obligation for attributes and entries. The replicas could disagree during propagation, but the protocol needed a path toward a common state.

Multi-master replication made conflict possible by design. Several master replicas could accept writes without first contacting the others. That preserved availability and local operation, but two writes could touch the same directory data before either reached the other server. Convergence then required a deterministic decision.

Determinism alone was insufficient. A rule such as “last arrival wins” might give a repeatable local answer only when every replica happened to observe the same order. Networks do not promise that. MM7 therefore said conflict resolution could not depend on changes arriving in order to assure eventual convergence. Authority could not be outsourced to packet timing.

The document did not choose one replacement rule, timestamp system or logical clock. Its requirement was more fundamental: independent replicas had to reach the same result under the supported model. That left room for later protocol work while preventing a design whose correctness depended on an arrival sequence it could not control.

The surviving live value and the losing information occupied different reality layers. MM5 required multi-master replication not to lose information. When a resolution would nonetheless remove directory information from the converged state, the process had to preserve that information elsewhere, explain the conflict and loss to an administrator, and make reversal possible.

The requirement did not say that both values stayed in the live entry. That would avoid making a decision rather than resolve the conflict. It required a converged directory view plus an evidence channel. The administrator could inspect what the automatic rule displaced and decide whether the live choice should be overridden.

This is a more demanding notion of consistency than visual equality. Five replicas can show the same value and still be operationally deficient if they destroyed the path by which the value became authoritative. Equality answers what readers see now. Retained conflict evidence answers whether that state can be audited and responsibly reconsidered.

Replay provided another boundary. Requirement M12 said an update received more than once could not produce a different result from receiving it once. Connections fail, acknowledgements disappear and suppliers retry. A replication protocol that counted a replay as a second independent mutation would turn recovery into corruption.

Atomicity also survived transport. P6 required preservation of the atomicity promised by LDAP operations. If several changes belonged to one operation, replication could not expose a partial application merely because the changes travelled between servers. In a multi-master system, preserving each atomic operation could still create an unresolvable conflict between two complete operations. Atomicity prevented torn updates; it did not eliminate competing valid histories.

Replication-initiation conflicts had a separate deterministic requirement. If several masters tried to start a cycle with the same replica simultaneously, the system needed an automatic way to resolve or avoid that contention. Recovery and rescheduling also had to handle a busy consumer or lost connection. Session coordination and data conflict were related, but not identical, problems.

Administration was part of interoperability. Every replica had to maintain audit history about which servers it had exchanged data with. Implementations should be able to compare two replicas and repair differences without triggering new replication cycles. A blank replica had to be initializable from a full update. These requirements made reconciliation observable rather than leaving it as an invisible background promise.

Update order mattered where policy controlled data. AM6 required replication to preserve the sequence between access-control information and the data governed by it. A data change arriving before the rule that authorizes or protects it could create a temporary state with different security meaning. General arrival order could not choose conflict winners, yet some causal relationships still had to be carried explicitly.

Schema mismatches also had to be handled and reported. Replication included schema definitions, attribute names and values, access-control information, knowledge information and namespace information. It excluded DSA-specific operational attributes as such. A replica could be partial, but partial did not mean undefined: the agreement needed to say what area, entries and attributes belonged in the copy.

The security requirements kept authentication, authorization, integrity and confidentiality distinct. A replication session needed support for mutual authentication and mutual authorization checking, as well as protected transfer. The document also required support for anonymous replication sessions. That did not make anonymous exchange equivalent to an authenticated one; it meant the protocol had to represent both cases and their policy consequences.

The later LDAP technical specification in RFC 4510, RFC 4511 and RFC 4512 provides chronology. RFC 4533 defined an LDAP content synchronization operation, and RFC 5805 later defined transactions. Neither may be treated as proof that all of RFC 3384's multi-master requirements were implemented wholesale. Adjacency is not identity.

RFC 3383, published just before RFC 3384, organized registration of LDAP extension identifiers. The two documents governed different surfaces. One kept new names from colliding in shared protocol space. The other asked how copies of directory state should reconcile when legitimate changes collided in time.

Lu Heng's minimum-initial-specification lens helps explain why a requirements document could be valuable without selecting every algorithm. It fixed the non-negotiable boundary—convergence, preserved loss evidence, notification and override—while leaving implementation choices to later work. The future decision remained local, but the harm it could not cause was already named.

His reality-layers lens exposes the central distinction. Accepted write, propagated update, conflict decision, converged live entry, stored losing information, administrator awareness and final human override are separate facts. A dashboard that shows all replicas green proves only one layer. It does not prove that disagreement was retained or reviewed.

RFC 3384's enduring lesson is that convergence can be too clean. A distributed system may reach one answer by deleting the history that made the answer contestable. The requirement to preserve the losing value turned a silent overwrite into an auditable decision. The replicas could agree without pretending they had never disagreed.

Sources