Address feedback

Author: zhenlan

articles/azure-app-configuration/howto-geo-replication.md

@@ -88,7 +88,10 @@ To delete a replica in the portal, follow the steps below.
 
 Each replica you create has its dedicated endpoint. If your application resides in multiple geolocations, you can update each deployment of your application in a location to connect to the replica closer to that location, which helps minimize the network latency between your application and App Configuration. Since each replica has its separate request quota, this setup also helps the scalability of your application while it grows to a multi-region distributed service.
 
-When geo-replication is enabled, and if one replica isn't accessible, you can let your application failover to another replica for improved resiliency. App Configuration provider libraries have built-in failover support. The provider library accepts multiple endpoints. You can provide a list of your replica endpoints in the order of how you prefer your application to connect, from the most to the least. When one endpoint isn't accessible, the provider library will fail over to a less preferred endpoint, but it will try to connect to the more preferred endpoints from time to time. When a more preferred endpoint becomes available, it will switch to it for future requests. You can update your application as the sample code below to take advantage of the failover feature.
+When geo-replication is enabled, and if one replica isn't accessible, you can let your application failover to another replica for improved resiliency. App Configuration provider libraries have built-in failover support by accepting multiple replica endpoints. You can provide a list of your replica endpoints in the order of the most preferred to the least preferred endpoint. When the current endpoint isn't accessible, the provider library will fail over to a less preferred endpoint, but it will try to connect to the more preferred endpoints from time to time. When a more preferred endpoint becomes available, it will switch to it for future requests. You can update your application as the sample code below to take advantage of the failover feature.
+
+> [!NOTE]
+> You can only use Azure AD authentication to connect to replicas during the preview.
 
 <!-- ### [.NET](#tab/dotnet) -->
 
@@ -108,16 +111,19 @@ configurationBuilder.AddAzureAppConfiguration(options =>
 ```
 
 > [!NOTE]
-> The failover support is availble in package `Microsoft.Extensions.Configuration.AzureAppConfiguration` version **5.3.0-preview** or later.
+> The failover support is availble if you use version **5.3.0-preview** or later of any of the following packages.
+> - `Microsoft.Extensions.Configuration.AzureAppConfiguration`
+> - `Microsoft.Azure.AppConfiguration.AspNetCore`
+> - `Microsoft.Azure.AppConfiguration.Functions.Worker`
 
 <!-- ### [Java Spring](#tab/spring)
 Placeholder for Java Spring instructions
 --- -->
 
-The failover in the App Configuration provider occurs in the following conditions.
-- Service unavailable responses (HTTP status code 500 or above)
-- Network connectivity issues
-- Throttled requests (HTTP status code 429)
+The App Configuration provider fails over to a different endpoint when it observes the following conditions.
+- Receives responses with service unavailable status (HTTP status code 500 or above).
+- Experiences with network connectivity issues.
+- Requests are throttled (HTTP status code 429).
 
 The failover won't happen for client errors like authentication failures.