edits

Author: ktoliver

articles/batch/batch-pools-without-public-ip-addresses-classic-retirement-migration-guide.md

@@ -10,22 +10,22 @@ ms.date: 09/01/2022
 
 # Migrate pools without public IP addresses (classic) in Batch
 
-The Azure Batch feature pools without public IP addresses (classic) will retire on *March 31, 2023*. Learn how to migrate eligible pools to simplified compute node communication (preview) pools without public IP addresses. You must opt in to migrate your Batch pools.
+The Azure Batch feature pools without public IP addresses (classic) will be retired on *March 31, 2023*. Learn how to migrate eligible pools to simplified compute node communication (preview) pools without public IP addresses. You must opt in to migrate your Batch pools.
 
 ## About the feature
 
 By default, all the compute nodes in an Azure Batch virtual machine (VM) configuration pool are assigned a public IP address. The Batch service uses the IP address to schedule tasks and for communication with compute nodes, including outbound access to the internet. To restrict access to these nodes and reduce public discoverability of the nodes, we released the Batch feature [pools without public IP addresses (classic)](./batch-pool-no-public-ip-address.md). Currently, the feature is in preview.
 
 ## Feature end of support
 
-In late 2021, we launched a simplified compute node communication model for Azure Batch. The new communication model improves security and simplifies the user experience. Batch pools no longer require inbound internet access and outbound access to Azure Storage. Batch pools now need only outbound access to the Batch service. As a result, on March 31, 2023, we will retire the Batch feature pools without public IP addresses (classic). The feature will be replaced in Batch with simplified compute node communication for pools without public IP addresses.
+In late 2021, we launched a simplified compute node communication model for Azure Batch. The new communication model improves security and simplifies the user experience. Batch pools no longer require inbound internet access and outbound access to Azure Storage. Batch pools now need only outbound access to the Batch service. As a result, on March 31, 2023, we'll retire the Batch feature pools without public IP addresses (classic). The feature will be replaced in Batch with simplified compute node communication for pools without public IP addresses.
 
 ## Alternative: Use simplified node communication
 
 The alternative to using a Batch pool without a public IP address (classic) requires using [simplified node communication](./simplified-node-communication-pool-no-public-ip.md). The option gives you enhanced security for your workload environments on network isolation and data exfiltration to Batch accounts. The key benefits include:
 
 - You can create simplified node communication pools without public IP addresses.
-- You can create a Batch private pool by using a new private endpoint (in the nodeManagement sub-resource) for an Azure Batch account.
+- You can create a Batch private pool by using a new private endpoint (in the nodeManagement subresource) for an Azure Batch account.
 - Use a simplified private link DNS zone for Batch account private endpoints. The private link changes from `privatelink.<region>.batch.azure.com` to `privatelink.batch.azure.com`.
 - Use mutable public network access for Batch accounts.
 - Get firewall support for Batch account public endpoints. You can configure IP address network rules to restrict public network access to your Batch account.
@@ -60,11 +60,11 @@ When the Batch feature pools without public IP addresses (classic) retires on Ma
 
 - What differences will I see in billing?
 
-  Compared to Batch pools without public IP addresses (classic), the simplified compute node communication pools without public IPs support reduces cost because it doesn't create the following network resources with Batch pool deployments: load balancer, network security groups, and private link service. However, you'll see a cost associated with [Azure Private Link](https://azure.microsoft.com/pricing/details/private-link/) or other outbound network connectivity that your pools use for communication with the Batch service.
+  Compared to Batch pools without public IP addresses (classic), the simplified compute node communication pools without public IP addresses support reduces cost because it doesn't create the following network resources with Batch pool deployments: load balancer, network security groups, and private link service. However, you'll see a cost associated with [Azure Private Link](https://azure.microsoft.com/pricing/details/private-link/) or other outbound network connectivity that your pools use for communication with the Batch service.
 
 - Will I see any changes in performance?
 
-  No known performance differences exist for simplified compute node communication pools without public IPs compared to Batch pools without public IP addresses (classic).
+  No known performance differences exist for simplified compute node communication pools without public IP addresses compared to Batch pools without public IP addresses (classic).
 
 - How can I connect to my pool nodes for troubleshooting?
 

articles/batch/batch-tls-101-migration-guide.md

@@ -1,6 +1,6 @@
 ---
 title: Migrate client code to TLS 1.2 in Azure Batch
-description: Learn how to migrate client code to TLS 1.2 in Azure Batch to prepare for end of support for TLS 1.0 and TLS 1.1.
+description: Learn how to migrate client code to TLS 1.2 in Azure Batch to plan for end of support for TLS 1.0 and TLS 1.1.
 author: harperche
 ms.author: harpercheng
 ms.service: batch
@@ -14,13 +14,13 @@ To support security best practices and remain in compliance with industry standa
 
 ## End of support for TLS 1.0 and TLS 1.1 in Batch
 
-TLS versions 1.0 and 1.1 are known to be susceptible to BEAST and POODLE attacks and to have other Common Vulnerabilities and Exposures (CVE) weaknesses. TLS 1.0 and 1.1 don't support the modern encryption methods and cipher suites that the Payment Card Industry (PCI) compliance standards recommends. Microsoft is participating in an industry-wide push toward the exclusive use of TLS version 1.2 or later.
+TLS versions 1.0 and TLS 1.1 are known to be susceptible to BEAST and POODLE attacks and to have other Common Vulnerabilities and Exposures (CVE) weaknesses. TLS 1.0 and TLS 1.1 don't support the modern encryption methods and cipher suites that the Payment Card Industry (PCI) compliance standards recommends. Microsoft is participating in an industry-wide push toward the exclusive use of TLS version 1.2 or later.
 
-Most customers have already migrated to TLS 1.2. Customers who continue to use TLS 1.0 or 1.1 can be identified via existing BatchOperation telemetry. If you're using TLS 1.0 or 1.1, to avoid disruption to your Batch workflows, you must adjust existing workflows to ensure that you're using TLS 1.2.
+Most customers have already migrated to TLS 1.2. Customers who continue to use TLS 1.0 or TLS 1.1 can be identified via existing BatchOperation data. If you're using TLS 1.0 or TLS 1.1, to avoid disruption to your Batch workflows, update existing workflows to use TLS 1.2.
 
-## Alternative: Migrate to TLS 1.2
+## Alternative: Use TLS 1.2
 
-To avoid disruption to your Batch workflows, you must update your client code to use TLS 1.2 before the TLS 1.0 and 1.1 retirement in Batch on March 31, 2023.
+To avoid disruption to your Batch workflows, you must update your client code to use TLS 1.2 before the TLS 1.0 and TLS 1.1 retirement in Batch on March 31, 2023.
 
 For specific development use cases, see the following information:
 
@@ -46,7 +46,7 @@ For more information, see [TLS best practices for the .NET Framework](/dotnet/fr
 
    Upgrading to TLS 1.2 won't affect your application's performance.
 
-- How do I know if I’m using TLS 1.0/1.1?
+- How do I know if I’m using TLS 1.0 or TLS 1.1?
 
    To determine the TLS version you're using, check the audit log for your Batch deployment.