[DOCS] More minor edits

Author: lcawl

docs/reference/ccr/auto-follow.asciidoc

@@ -1,33 +1,32 @@
 [role="xpack"]
 [testenv="platinum"]
 [[ccr-ov-auto-follow]]
-=== Automatically Following Indices
+=== Automatically following indices
 
 beta[]
 
-In time-series use-cases where new indices that you want to follow are
-periodically created (e.g., daily Beats indices), manually configuring follower
+In time series use cases where you want to follow new indices that are
+periodically created (such as daily Beats indices), manually configuring follower
 indices for each new leader index can be an operational burden. The auto-follow
 functionality in {ccr} is aimed at easing this burden. With the auto-follow
-functionality, you can configure that newly created indices in a remote cluster
-with a name that matches a pattern are automatically followed as they are
-created.
+functionality, you can specify that new indices in a remote cluster that have a 
+name that matches a pattern are automatically followed.
 
 ==== Managing auto-follow patterns
 
-You can add a new auto-follow pattern configuration using the
+You can add a new auto-follow pattern configuration with the
 {ref}/ccr-put-auto-follow-pattern.html[create auto-follow pattern API].  When you create
 a new auto-follow pattern configuration, you are configuring a collection of
-patterns against a single remote cluster. Any time a new index with a name
-matching one of the patterns in the collection is created in the remote cluster,
-a follower index will be configured in the local cluster to replicate with the
+patterns against a single remote cluster. Any time a new index with a name that 
+matches one of the patterns in the collection is created in the remote cluster,
+a follower index is configured in the local cluster. The follower index uses the 
 new index as its leader index.
 
-You can inspect all configured auto-follow pattern collections using the
-{ref}/ccr-get-auto-follow-pattern.html[get auto-follow pattern API], and delete a
-configured auto-follow pattern collection using the
+You can inspect all configured auto-follow pattern collections with the
+{ref}/ccr-get-auto-follow-pattern.html[get auto-follow pattern API]. To delete a
+configured auto-follow pattern collection, use the
 {ref}ccr-delete-auto-follow-pattern.html[delete auto-follow pattern API].
 
 Since auto-follow functionality is handled automatically in the background on
-your behalf, error reporting is done through logs on the elected master node,
+your behalf, error reporting is done through logs on the elected master node
 and through the {ref}/ccr-get-stats.html[{ccr} stats API].

docs/reference/ccr/index.asciidoc

@@ -18,7 +18,7 @@ local cluster. This functionality can be used in some common production use case
 This guide provides an overview of {ccr}:
 
 * <<ccr-overview>>
-* <<ccr-ov-soft-deletes>>
+* <<ccr-requirements>>
 * <<ccr-ov-auto-follow>>
 * <<ccr-getting-started>>
 

docs/reference/ccr/overview.asciidoc

@@ -29,7 +29,7 @@ Replication can be configured in two ways:
 * Automatically using
   <<ccr-ov-auto-follow,auto-follow patterns>>
 
-NOTE: You must also <<ccr-ov-soft-deletes,configure the leader index>>.
+NOTE: You must also <<ccr-requirements,configure the leader index>>.
 
 [float]
 === The mechanics of replication

docs/reference/ccr/requirements.asciidoc

@@ -1,40 +1,44 @@
 [role="xpack"]
 [testenv="platinum"]
-[[ccr-ov-soft-deletes]]
-=== Requirements for Leader Indices
+[[ccr-requirements]]
+=== Requirements for leader indices
 
 beta[]
 
 Cross-cluster replication works by replaying the history of individual write
-operations performed on the shards of the leader index. This means that the
+operations that were performed on the shards of the leader index. This means that the
 history of these operations needs to be retained on the leader shards so that
 they can be pulled by the follower shard tasks. The underlying mechanism used to
-retain these operations is soft deletes. A soft delete occurs whenever an
+retain these operations is _soft deletes_. A soft delete occurs whenever an
 existing document is deleted or updated. By retaining these soft deletes up to
 configurable limits, the history of operations can be retained on the leader
 shards and made available to the follower shard tasks as it replays the history
 of operations.
 
 Soft deletes must be enabled for indices that you want to use as leader
 indices. Enabling soft deletes requires the addition of some index settings at
-index creation time. You will need to add these settings to your create index
-requests, or to the index templates that you use to manage creation of new
+index creation time. You must add these settings to your create index
+requests or to the index templates that you use to manage the creation of new
 indices.
 
-NOTE: This means that {ccr} can not be used on existing indices. If you have
+IMPORTANT: This means that {ccr} can not be used on existing indices. If you have
 existing data that you want to replicate from another cluster, you must
-{ref}/docs-reindex.html[reindex] your data into a new index with soft-deletes enabled.
+{ref}/docs-reindex.html[reindex] your data into a new index with soft deletes 
+enabled.
 
 [float]
-==== Soft-delete settings
+[[ccr-ov-soft-deletes]]
+==== Soft delete settings
 
 `index.soft_deletes.enabled`::
 
 Whether or not soft deletes are enabled on the index. Soft deletes can only be
-configured at index creation, and only on indices created on or after 6.5.0.
+configured at index creation and only on indices created on or after 6.5.0.
 
 `index.soft_deletes.retention.operations`::
 
 The number of soft deletes to retain. Soft deletes are collected during merges
 on the underlying Lucene index yet retained up to the number of operations
 configured by this setting.
+
+For more information about index settings, see {ref}/index-modules.html[Index modules].