Occasionally, applications want to read back the data that they just wrote.
 If a modification requested to a shadow server was silently chained to its 
-producer, an immediate read could result in receiving data not yet sync'ed.  
+producer, an immediate read could result in receiving data not yet synchronized.  
 In those cases, clients should use the {{B:dontusecopy}} control to ensure 
 they are directed to the authoritative source for that piece of data.
 
 
 H3: Overview
 
-This overlay implements the provider-side support for syncrepl
-replication, including persistent search functionality
-
+This overlay implements the provider-side support for the LDAP Content Synchronization 
+({{REF:RFC4533}}) as well as syncrepl replication support, including persistent search functionality.
 
 H3: Sync Provider Configuration
 
+There is very little configuration needed for this overlay, in fact for many situations merely loading 
+the overlay will suffice.
+
+However, because the overlay creates a contextCSN attribute in the root entry of the database which is
+updated for every write operation performed against the database and only updated in memory, it is 
+recommended to configure a checkpoint so that the contextCSN is written into the underlying database to 
+minimize recovery time after an unclean shutdown:
+
+>       overlay syncprov
+>       syncprov-checkpoint 100 10
+
+For every 100 operations or 10 minutes, which ever is sooner, the contextCSN will be checkpointed.
+
+The four configuration directives available are {{B:syncprov-checkpoint}}, {{B:syncprov-sessionlog}},
+{{B:syncprov-nopresent}} and {{B:syncprov-reloadhint}} which are covered in the man page discussing
+various other scenarios where this overlay can be used. 
 
 H3: Further Information
 
-{{:slapo-syncprov(5)}}
+The {{:slapo-syncprov(5)}} man page and the {{SECT:Configuring the different replication types}} section
 
 
 H2: Translucent Proxy