A few tweaks from Pat's review

Author: w-azure

articles/iot-edge/how-to-authenticate-downstream-device.md

@@ -14,7 +14,7 @@ services: iot-edge
 
 [!INCLUDE [iot-edge-version-all-supported](../../includes/iot-edge-version-all-supported.md)]
 
-In a transparent gateway scenario, downstream devices need identities in IoT Hub like any other device. This article walks through the options for authenticating a downstream device to IoT Hub, and then demonstrates how to declare the gateway connection.
+In a transparent gateway scenario, downstream devices (sometimes called leaf devices or child devices) need identities in IoT Hub like any other device. This article walks through the options for authenticating a downstream device to IoT Hub, and then demonstrates how to declare the gateway connection.
 
 There are three general steps to set up a successful transparent gateway connection. This article covers the second step:
 

articles/iot-edge/how-to-connect-downstream-iot-edge-device.md

@@ -18,11 +18,11 @@ monikerRange: ">=iotedge-2020-11"
 
 This article provides instructions for establishing a trusted connection between an IoT Edge gateway and a downstream IoT Edge device. This setup is also known as "nested edge".
 
-In a gateway scenario, an IoT Edge device can be both a gateway and a downstream device. Multiple IoT Edge gateways can be layered to create a hierarchy of devices. The downstream downstream devices can authenticate and send or receive messages through their gateway (parent) device.
+In a gateway scenario, an IoT Edge device can be both a gateway and a downstream (child) device. Multiple IoT Edge gateways can be layered to create a hierarchy of devices. The downstream downstream devices can authenticate and send or receive messages through their gateway (parent) device.
 
 There are two different configurations for IoT Edge devices in a gateway hierarchy, and this article address both. The first is the **top layer** IoT Edge device. When multiple IoT Edge devices are connecting through each other, any device that doesn't have a parent device but connects directly to IoT Hub is considered to be in the top layer. This device is responsible for handling requests from all the devices below it. The other configuration applies to any IoT Edge device in a **lower layer** of the hierarchy. These devices may be a gateway for other downstream IoT and IoT Edge devices, but also need to route any communications through their own parent devices.
 
-Some network architectures require that only the top IoT Edge device in a hierarchy can connect to the cloud. In this configuration, all IoT Edge devices in lower layers of a hierarchy can only communicate with their gateway (or parent) device and any downstream devices.
+Some network architectures require that only the top IoT Edge device in a hierarchy can connect to the cloud. In this configuration, all IoT Edge devices in lower layers of a hierarchy can only communicate with their gateway (parent) device and any downstream (child) devices.
 
 All the steps in this article build on [Configure an IoT Edge device to act as a transparent gateway](how-to-create-transparent-gateway.md), which sets up an IoT Edge device to be a gateway for downstream IoT devices. The same basic steps apply to all gateway scenarios:
 

articles/iot-edge/tutorial-nested-iot-edge-for-linux-on-windows.md

@@ -367,7 +367,7 @@ You can also view these messages through the [Azure Cloud Shell](https://shell.a
 
 Run the `iotedge check` command to verify the configuration and to troubleshoot errors.
 
-You can run `iotedge check` in a nested hierarchy, even if the downstream machines don't have direct internet access.
+You can run `iotedge check` in a nested hierarchy, even if the downstream devices don't have direct internet access.
 
 When you run `iotedge check` from the lower layer, the program tries to pull the image from the parent through port 443.