First round of feedback

Author: NicoletaComan

content/en/docs/control-center/security/private-connectivity/best-practices.md

@@ -14,9 +14,13 @@ Private Connectivity is currently in Public Beta, and will be out of Public Beta
 
 This page provides best practices for configuring and using Private Connectivity networks, agents, and resources. Following these guidelines helps ensure secure, efficient, and maintainable connections between your Mendix apps and internal infrastructure.
 
+{{% alert color="info" %}}
+Mendix uses Tailscale subnet routers to access routes in your network. In a Mendix context, these are called agents. 
+{{% /alert %}}
+
 ## Authentication Key Security 
 
-Creating an agent involves creating an authentication key. Agents registered with that authentication key join the agent's network. If you have a production network, only use the generated authentication key for agents placed in your production network. Apply the same principle for development networks.
+Creating an agent involves creating an authentication key. An agent registered with that authentication key can join the agent's network. If you have a production network, only use the generated authentication key for agents placed in your production network. Apply the same principle for development networks.
 
 ## When to Create Networks 
 
@@ -33,25 +37,21 @@ Agents determine what parts of your infrastructure are accessible. While creatin
 
 ### Where to Place Agents 
 
-An agent forwards traffic to the advertised subnets. Place it where it can access those addresses:
-
-* AWS – Place the agent in your VPC.
-* Azure – Place the agent in your VNet.
-* On-premises – Place the agent where it has network access to the target resources.
+Place the agent where it has network access to the target resources.
 
 ### Infrastructure Requirements 
 
-Install agents on infrastructure that has direct network reachability to the resources you want to advertise. Typically, a virtual machine (VM) or other host inside the relevant VPC or VNet is the best fit.
+Install agents on infrastructure that has direct network reachability to the resources you want to advertise, i.e. provide access to. Typically, a virtual machine (VM) or other host inside the relevant VPC or VNet is the best fit.
 
 Tailscale supports both Linux and Windows. For the best results and performance, use Linux due to its [kernel integration](https://tailscale.com/docs/reference/kernel-vs-userspace-routers). 
 
 For recommendations on operating system tweaks and machine sizing for the main cloud providers, refer to [Tailscale's performance best practices](https://tailscale.com/docs/reference/best-practices/performance#operating-system-recommendations).
 
-Suitable infrastructure for agents includes EC2 instances, VMs, and containers with privileged access on EKS or AKS.
+Suitable infrastructure for agents includes EC2 instances and VMs.
 
-### Recommended Number of Agents
+### Agent Placement Strategy
 
-It is more efficient to use one agent with multiple advertised subnets. You can advertise as wide a CIDR range as you need, or as many subnets as necessary on one agent. Using one agent requires less effort to install and is cheaper in both time and maintenance cost.
+It is more efficient to use one agent with multiple advertised subnets. You can advertise as wide a subnet range as you need, or as many subnets as necessary on one agent. Using one agent requires less effort to install and is cheaper in both time and maintenance cost.
 
 However, you need to consider these trade-offs:
 
@@ -60,9 +60,9 @@ However, you need to consider these trade-offs:
 
 ### High Availability 
 
-Subnet routers support high availability. To set this up, create two or more agents that advertise the same routes. For example, if you set up two routers that both advertise `10.0.0.0/16`, the first agent acts as the primary and the second as the failover.
+Agents support high availability. To set this up, create two or more agents that advertise the same routes. For example, if you set up two routers that both advertise `10.0.0.0/16`, the first agent acts as the primary and the second as the failover.
 
-This setup provides a simple active/passive failover, not load balancing. When Tailscale detects that your primary subnet router is offline, routing immediately switches to the failover device.
+This setup provides a simple active/passive failover, not load balancing. When Tailscale detects that your primary agent is offline, routing immediately switches to the failover device.
 
 For more information, refer to [Subnet Router High Availability](https://tailscale.com/docs/how-to/set-up-high-availability#subnet-router-high-availability).
 
@@ -79,11 +79,10 @@ Use these parameters to avoid authentication failure issues:
 * Use the `TS_AUTHKEY` parameter to supply the authentication key to your container. For more information, refer to [TS_AUTHKEY](https://tailscale.com/docs/features/containers/docker/docker-params#ts_authkey).
 * Use the `TS_AUTH_ONCE` parameter to ensure the container only attempts authentication once. This helps avoid *API key not found* errors on container restarts. For more information, refer to [TS_AUTH_ONCE](https://tailscale.com/docs/features/containers/docker/docker-params#ts_auth_once).
 * Use the `TS_STATE_DIR` parameter to declare a space to save the state, then mount it as a volume. For more information, refer to [TS_STATE_DIR](https://tailscale.com/docs/features/containers/docker/docker-params#ts_state_dir).
-* On Kubernetes, use the `TS_KUBE_SECRET` parameter to store the state in a secret. The value is the name you want to give that secret. If it is not set, it defaults to `tailscale`. For more information, refer to [TS_KUBE_SECRET](https://tailscale.com/docs/features/containers/docker/docker-params#ts_kube_secret).
 
 ### Privilege Requirements 
 
-Tailscale typically runs in kernel (TUN) mode. If your environment allows privileged containers or host networking, that is the better choice for a subnet router. If it does not, you can run the subnet router in userspace mode, but this is better suited for lighter-duty use, and is not the first recommendation for higher-throughput production routing.
+Tailscale typically runs in kernel (TUN) mode. If your environment allows privileged containers or host networking, that is the better choice for an agent. If it does not, you can run the agent in userspace mode, but this is better suited for lighter-duty use, and is not the first recommendation for higher-throughput production routing.
 
 For example, Azure Container Apps do not have privileged container access, so you need to enable userspace mode. For more information, refer to the following pages in the Tailscale documentation:
 
@@ -98,6 +97,6 @@ Mendix uses Tailscale subnet routers to advertise routes to your network. This g
 
 The routes you advertise depend on what your Mendix Cloud app needs to access and what you want to share:
 
-* Single resource – If your app only needs to reach one specific resource, advertise that single address via a `/32` subnet mask (for example, `192.168.1.10/32`).
-* App subnet – If you host all apps in one specific subnet, use the subnet CIDR (for example, `192.168.1.0/24`).
-* Entire network – If you want to share the entire network to avoid repeatedly opening new routes, use the entire VPC or VNet CIDR (for example, `192.168.0.0/16`).
+* Single resource – If your app only needs to reach one specific resource, advertise it as a `/32` route (for example, `192.168.1.10/32`).
+* App subnet – If you host all apps in one specific subnet, use the subnet router (for example, `192.168.1.0/24`).
+* Entire network – If you want to share the entire network to avoid repeatedly opening new routes, use the entire VPC or VNet subnet router (for example, `192.168.0.0/16`).