apply some suggestions from review

Author: renetapopova

modules/ROOT/pages/database-administration/aliases/remote-database-alias-configuration.adoc

@@ -10,12 +10,12 @@ Although remote database aliases do not store any data, they enable users or app
 All configurations can be done using xref:database-administration/aliases/manage-aliases-standard-databases.adoc[administrative commands] on a running system.
 Any changes are automatically synchronized across all members of a cluster.
 
-The following steps describe the setup required to define a remote database alias for both local and remote DBMSs.
-They assume that you have already installed and started both DBMSs: a local *DBMS A* and a remote *DBMS B*, and that you have administrator access to both systems.
+The following examples describe how to set up a remote database alias in two different ways: using stored native credentials and using OIDC credential forwarding.
+It is assumed that you have two separate DBMS instances: a local *DBMS A* and a remote *DBMS B*.
 
 By creating a remote alias, you define:
 
-* Which user of the remote *DBMS B* is used.
+* Which user of the remote *DBMS B* can access the remote alias.
 * Where the remote database is located.
 * How to connect to the remote database using driver settings.
 
@@ -31,7 +31,7 @@ The user needs to be logged in with an identity provider supporting OIDC.
 
 In this example, _Alice_ is an administrator and _Carol_ is a user who needs access to a database managed by _Bob_.
 
-image::remote-alias-overview.svg[title="Overview of the required remote database alias setup when using stored credentials", role="middle"]
+image::remote-alias-overview.svg[title="Overview of the required remote database alias setup when using stored native credentials", role="middle"]
 
 A remote database alias is only accessible to users with appropriate privileges.
 In this example, _Bob_ is the administrator responsible for deciding which database (`db1` or `db2`) the remote aliases can write and/or read.
@@ -211,14 +211,14 @@ See the xref:authentication-authorization/sso-integration.adoc[SSO integration]
 
 In this example, _Alice_ is an administrator and _Carol_ is a user who needs access to a database managed by _Bob_.
 
-image::remote-alias-credential-forwarding-overview.svg[title="Overview of the required remote database alias setup when using oidc credential forwarding", role="middle"]
+image::remote-alias-credential-forwarding-overview.svg[title="Overview of the required remote database alias setup when using OIDC credential forwarding", role="middle"]
 
-_Carol_ logs into *DBMS A* through an OIDC-compliant identity provider by offering a token from the provider.
+_Carol_ logs into the local *DBMS A* through an OIDC-compliant identity provider by offering a token from the provider.
 The token is used to set the username and determine the identity provider groups to which the user belongs.
 
-_Alice_ is the admin of *DBMS A* and has set up SSO for the identity provider and configured the mapping of the identity provider groups to the Neo4j roles, such that _Carol_ can use the remote database alias, `db1-remote-alias`, to connect to the remote database `db1`.
+_Alice_ is the admin of the local *DBMS A* and has set up SSO for the identity provider and configured the mapping of the identity provider groups to the Neo4j roles, such that _Carol_ can use the remote database alias, `db1-remote-alias`, to connect to the remote database `db1`.
 
-_Bob_ configures the *DBMS B* to support SSO with the same identity provider used by _Carol_ to log in to *DBMS A*.
+_Bob_ configures the remote *DBMS B* to support SSO with the same identity provider used by _Carol_ to log in to *DBMS A*.
 He also configures the mapping of the identity provider groups to the Neo4j roles such that the _Carol's_ identity provider groups grant the appropriate privileges to access `db1` on the *DBMS B*.
 
 [CAUTION]