More for ITS#9275 and term cleanup

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}})
 

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

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