PR feedback

website/content/docs/connect/ca/index.mdx

@@ -35,21 +35,21 @@ services.
 client agents for HTTP API TLS, and for mTLS for RPC requests to servers.
 
 Any secondary datacenters use their CA provider to generate an intermediate certificate
-signing request (CSR) to be signed by the Primary Root CA. They receive an intermediate
-CA certificate which is used to sign leaf certificates in the secondary datacenter.
+signing request (CSR) to be signed by the primary root CA. They receive an intermediate
+CA certificate, which is used to sign leaf certificates in the secondary datacenter.
 
-It is possible to use different providers across primary and secondary datacenters.
+You can use different providers across primary and secondary datacenters.
 For example, an operator may use a Vault CA provider for extra security in the primary
-datacenter but choose to use the built-in CA provider in the secondary datacenter which
-may not have a reachable Vault cluster. The pros and cons of both providers are listed below.
+datacenter but choose to use the built-in CA provider in the secondary datacenter, which
+may not have a reachable Vault cluster. The following table compares the built-in and Vault providers.
 
 ## CA Provider Comparison
 
 |            | Consul built-in                    | Vault                                                                             |
 |------------|------------------------------------|-----------------------------------------------------------------------------------|
 | Security   | CA private keys are stored on disk | CA private keys are stored in Vault and are never exposed to Consul server agents |
-| Resiliency | No dependency on external systems. If Consul is available, it can sign certificates | Dependent on Vault availability         |
-| Latency    | Consul signs certificates locally           | A network call to Vault is required to sign certificates                           |
+| Resiliency | No dependency on external systems. If Consul is available, it can sign certificates | Dependent on Vault availability  |
+| Latency    | Consul signs certificates locally  | A network call to Vault is required to sign certificates                          |
 
 ## CA Bootstrapping
 

website/content/docs/connect/ca/vault.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Vault as a Service Mesh Certificate Authority
 
-You can configure Consul to use [Vault](https://www.vaultproject.io/) as the certificate authority (CA) so that Vault can manage and sign certificates distributed to services in the mesh.
+You can configure Consul to use [Vault](/vault) as the certificate authority (CA) so that Vault can manage and sign certificates distributed to services in the mesh.
 The Vault CA provider uses the [Vault PKI secrets engine](/vault/docs/secrets/pki) to generate and sign certificates.
 This page describes how configure the Vault CA provider.
 
@@ -25,8 +25,9 @@ This page describes how configure the Vault CA provider.
 
 - For best performance and resiliency, every datacenter should have a Vault cluster local to its Consul cluster.
 
-- In WAN-federated environments, Vault Enterprise users using [performance secondaries](/vault/docs/enterprise/replication#performance-replication) in their secondary datacenters
-  are recommended to use [`local`](/vault/docs/enterprise/replication#local) mounts for their [`intermediate_pki_path`](/consul/docs/connect/ca/vault#intermediatepkipath).
+- If your Consul datacenters are WAN-federated and the secondary datacenter uses Vault Enterprise
+  [performance secondaries](/vault/docs/enterprise/replication#performance-replication), we recommend
+  configuring [`local`](/vault/docs/enterprise/replication#local) mounts for their [`intermediate_pki_path`](/consul/docs/connect/ca/vault#intermediatepkipath).
 
 ## Enable Vault as the CA