DOCS-393 added info on arbiter communications

Author: Bob Grabar

source/core/replication.txt

@@ -164,29 +164,20 @@ participate in :term:`elections <election>`.
    Do not run arbiter processes on a system that is an active
    :term:`primary` or :term:`secondary` of its replica set.
 
-Arbiters make the following communications:
+Arbiters never receive the contents of any collection but do have the
+following interactions with the ret of the replica set:
 
-- Exchange keyfiles with replica set. Arbiters
-  replica set servers exchange keyfiles, which are the equivalent of a
-  password for the __system "user".
-
-- The arbiter is authenticated when a connection is created between it
-  and another member of the replica set, and is then trusted until the
-  connection ends.
+- Credential exchanges, which are used to authenticate the arbiter with
+  the replica set. All MongoDB processes within a replica set use
+  keyfiles. These exchanges are encrypted.
 
 - Only the authentication step is encrypted. Replica set configuration
-  data and voting are unencrypted.
-
-- Data other than the authentication step are not encrypted.
-
-
-
-
-
-
-
+  data and voting are not encrypted.
 
-You should always run arbiters on secure networks.
+If your MongoDB deployment uses SSL, then all communications between
+arbiters and the other members of the replica set are secure. See the
+documentation for :doc:`/administration/ssl` for more information. Run
+all arbiters on secure networks, as with all MongoDB components.
 
 .. index:: replica set members; non-voting
 .. _replica-set-non-voting-members:
@@ -332,7 +323,8 @@ apply or decide to ignore the rollback data.
 
 The best strategy for avoiding all rollbacks is to ensure :ref:`write
 propagation <replica-set-write-concern>` to all or some of the
-nodes in the set. Using these kinds of policies prevents situations
+nodes in the set. Using /bin/bash: Using: command not found
+these kinds of policies prevents situations
 that might create rollbacks.
 
 .. warning::

source/faq/replica-sets.txt

@@ -181,21 +181,23 @@ primary.
 
 .. seealso:: :doc:`/administration/replication-architectures`
 
-Do arbiters use encrypted communication?
-----------------------------------------
-
-Arbiters use encryption only when creating a connection with another
-replica-set member. All other communications are unencrypted.
+What information do arbiters exchange with replica sets?
+--------------------------------------------------------
 
-The following rules govern arbiter communications:
+Arbiters never receive the contents of a collection but do exchange the
+following data with the rest of the replica set:
 
-- An arbiter is authenticated when a connection is created between it
-  and another member of the replica set. The arbiter is then trusted
-  until the connection ends.
+- Credentials used to authenticate the arbiter with the replica set. All
+  MongoDB processes within a replica set use keyfiles. These exchanges
+  are encrypted.
 
-- Replica set configuration data and voting are unencrypted.
+- Replica set configuration data and voting data. This information is
+  not encrypted. Only credential exchanges are encrypted.
 
-You must always run arbiters on secure networks.
+If your MongoDB deployment uses SSL, then all communications between
+arbiters and the other members of the replica set are secure. See the
+documentation for :doc:`/administration/ssl` for more information. Run
+all arbiters on secure networks, as with all MongoDB components.
 
 Which members of a replica set vote in elections?
 -------------------------------------------------