diff --git a/doc/guide/admin/appendix-changes.sdf b/doc/guide/admin/appendix-changes.sdf
index 50066727f1da7b96dffbdef4b0bb19e7bf8b501d..0dbd601f7e843d2788001d094628883c3dff8328 100644
--- a/doc/guide/admin/appendix-changes.sdf
+++ b/doc/guide/admin/appendix-changes.sdf
@@ -79,17 +79,16 @@ of the database may in turn be provided to other consumers using the Syncprov
 overlay. The Syncprov overlay works with any number of consumers over a single 
 database or over arbitrarily many glued databases.
 
-H3: N-Way Multimaster Replication
+H3: N-Way Multiprovider Replication
 
 As a consequence of the work to support multiple consumer contexts, the syncrepl 
-system now supports full N-Way multimaster replication with entry-level conflict 
+system now supports full N-Way multiprovider replication with entry-level conflict 
 resolution. There are some important constraints, of course: In order to maintain 
 consistent results across all servers, you must maintain tightly synchronized 
 clocks across all participating servers (e.g., you must use NTP on all servers). 
 
 The entryCSNs used for replication now record timestamps with microsecond resolution, 
-instead of just seconds. The delta-syncrepl code has not been updated to support 
-multimaster usage yet, that will come later in the 2.4 cycle.
+instead of just seconds.
 
 H3: Replicating {{slapd}} Configuration (syncrepl and {{B:cn=config}})
 
diff --git a/doc/guide/admin/intro.sdf b/doc/guide/admin/intro.sdf
index dce26f0d26f9136073f2c9c189c0a902e01ef429..b422278c99d46a0fd8ba06ef6a2914e1d50c09bb 100644
--- a/doc/guide/admin/intro.sdf
+++ b/doc/guide/admin/intro.sdf
@@ -441,7 +441,10 @@ replication scheme is vital in high-volume environments where a
 single {{slapd}} installation just doesn't provide the necessary availability
 or reliability.  For extremely demanding environments where a
 single point of failure is not acceptable, {{multi-provider}} replication
-is also available.  {{slapd}} includes support for {{LDAP Sync}}-based
+is also available. With {{multi-provider}} replication two or more nodes can
+accept write operations allowing for redundancy at the provider level.
+
+{{slapd}} includes support for {{LDAP Sync}}-based
 replication.
 
 {{B:Proxy Cache}}: {{slapd}} can be configured as a caching
diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf
index 935cf49d59fe57c6a9c43f3df91d4e325a9efc04..ef747533d8a1e0df6646144cc8eb806337f285bf 100644
--- a/doc/guide/admin/replication.sdf
+++ b/doc/guide/admin/replication.sdf
@@ -13,16 +13,17 @@ a {{master}} server and some number of {{slave}} servers. A master
 accepted directory updates from other clients, and a slave only
 accepted updates from a (single) master. The replication structure
 was rigidly defined and any particular database could only fulfill
-a single role, either master or slave.
+a single role, either master or slave. Another historic term introduced
+with OpenLDAP 2.4 was multimaster.
 
 As OpenLDAP now supports a wide variety of replication topologies, these
-terms have been deprecated in favor of {{provider}} and
-{{consumer}}: A provider replicates directory updates to consumers; 
-consumers receive replication updates from providers. Unlike the
-rigidly defined master/slave relationships, provider/consumer roles
-are quite fluid: replication updates received in a consumer can be
-further propagated by that consumer to other servers, so a consumer
-can also act simultaneously as a provider. Also, a consumer need not
+terms have been deprecated in favor of {{provider}}/{{multi-provider}} and
+{{consumer}}: A provider can accept external write operations and make them
+available for retrieval by consumers; consumers request replication updates from
+providers. Unlike the rigidly defined master/slave relationships,
+provider/consumer roles are quite fluid: replication updates received in a
+consumer can be further propagated by that consumer to other servers, so a
+consumer can also act simultaneously as a provider. Also, a consumer need not
 be an actual LDAP server; it may be just an LDAP client.
 
 The following sections will describe the replication technology and