diff --git a/cinder/volume/driver.py b/cinder/volume/driver.py
index de3a0d183df..97817155a8b 100644
--- a/cinder/volume/driver.py
+++ b/cinder/volume/driver.py
@@ -215,7 +215,7 @@ volume_opts = [
                       "times in a single config section to specify multiple "
                       "replication target devices.  Each entry takes the "
                       "standard dict config form: replication_device = "
-                      "device_target_id:<required>,"
+                      "target_device_id:<required>,"
                       "managed_backend_name:<host@backend_name>,"
                       "key1:value1,key2:value2..."),
     cfg.BoolOpt('image_upload_use_cinder_backend',
diff --git a/cinder/volume/manager.py b/cinder/volume/manager.py
index 2a637cfd88f..efe42f362e0 100644
--- a/cinder/volume/manager.py
+++ b/cinder/volume/manager.py
@@ -3323,28 +3323,22 @@ class VolumeManager(manager.SchedulerDependentManager):
 
         This method is used to query a backend to get the current
         replication config info for the specified volume.
-
         In the case of a volume that isn't being replicated,
         the driver should return an empty list.
 
+        There is one required field for configuration of
+        replication, (target_device_id).  As such we
+        use that for the response in list_replication_targets.
 
-        Example response for replicating to a managed backend:
+        Internal methods can be added to extract additional
+        details if needed, but the only detail that should be
+        exposed to an end user is the identifier.  In the case
+        of an Admin, (s)he can always cross check the cinder.conf
+        file that they have configured for additional info.
+
+        Example response:
             {'volume_id': volume['id'],
-             'targets':[{'remote_device_id': 'vendor-id-for-target-device',
-                         'managed_host': 'backend_name'}...]
-
-        Example response for replicating to an unmanaged backend:
-            {'volume_id': volume['id'], 'targets':[
-                {'remote_device_id': 'vendor-id-for-target-device',
-                                      'san_ip': '1.1.1.1',
-                                      'san_login': 'admin'},
-                                      ....]}
-
-        NOTE: It's the responsibility of the driver to mask out any
-        passwords or sensitive information.
-
-        `remote_device_id` is required and is used for drivers to identify
-        the devices they have in use.
+             'targets':[<target-device-id>,...]'
 
         """
         # NOTE(hemna) We intentionally don't enforce the driver being
diff --git a/doc/source/devref/replication.rst b/doc/source/devref/replication.rst
index 46a7595995a..bd1371e675b 100644
--- a/doc/source/devref/replication.rst
+++ b/doc/source/devref/replication.rst
@@ -31,9 +31,12 @@ like to configure.
 There are two standardized keys in the config
 entry, all others are vendor-unique:
 
-* device_target_id:<vendor-identifier-for-rep-target>
+* target_device_id:<vendor-identifier-for-rep-target>
 * managed_backend_name:<cinder-backend-host-entry>,"
 
+target_device_id is REQUIRED in all configurations
+
+
 
 An example config entry for a managed replication device
 would look like this::
@@ -209,17 +212,14 @@ act as a toggle, allowing to switch back and forth betweeen primary and secondar
 
 **list_replication_targets**
 
-Used by the admin to query a volume for a list of configured replication targets
-The expected return for this call is expected to mimic the form used in the config file.
+Used by the admin to query a volume for a list of configured replication targets.
 
-For a volume replicating to managed replication targets::
-
-    {'volume_id': volume['id'], 'targets':[{'type': 'managed',
-                                            'backend_name': 'backend_name'}...]
-
-For a volume replicating to external/unmanaged targets::
-
-    {'volume_id': volume['id'], 'targets':[{'type': 'unmanaged',
-                                            'san_ip': '127.0.0.1',
-                                            'san_login': 'admin'...}...]
+The expected response is simply the single required field in replication-device
+configuration.  It's possible that in the future we may want to add a show
+command that provides all the various details about a target replication
+device.  This would be of the form:
+`show_replication_target <target_device_id>`
 
+Example response:
+    {'volume_id': volume['id'],
+     'targets':[<target-device-id>,...]'