Clarified diff between child and downstream

Author: w-azure

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

@@ -14,7 +14,10 @@ services: iot-edge
 
 [!INCLUDE [iot-edge-version-all-supported](../../includes/iot-edge-version-all-supported.md)]
 
-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.
+In a transparent gateway scenario, downstream devices (sometimes called 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. 
+
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
 
 There are three general steps to set up a successful transparent gateway connection. This article covers the second step:
 

articles/iot-edge/how-to-collect-and-transport-metrics.md

@@ -35,7 +35,7 @@ To configure monitoring on your IoT Edge device follow the [Tutorial: Monitor Io
 |  2️ | The [metrics-collector module](https://aka.ms/edgemon-metrics-collector) is a Microsoft-supplied IoT Edge module that collects workload module metrics and transports them off-device. Metrics collection uses a *pull* model. Collection frequency, endpoints, and filters can be configured to control the data egressed from the module. For more information, see [metrics collector configuration section](#metrics-collector-configuration) later in this article. |
 |  3️ | You have two options for sending metrics from the metrics-collector module to the cloud. *Option 1* sends the metrics to Log Analytics.<sup>1</sup> The collected metrics are ingested into the specified Log Analytics workspace using a fixed, native table called `InsightsMetrics`. This table's schema is compatible with the Prometheus metrics data model.<br><br> This option requires access to the workspace on outbound port 443. The Log Analytics workspace ID and key must be specified as part  of the module configuration. To enable in restricted networks, see [Enable in restricted network access scenarios](#enable-in-restricted-network-access-scenarios) later in this article.
 |  4️ | Each metric entry contains the `ResourceId` that was specified as part of [module configuration](#metrics-collector-configuration). This association automatically  links the metric with the specified resource (for example, IoT Hub). As a result, the [curated IoT Edge workbook templates](how-to-explore-curated-visualizations.md) can retrieve metrics by issuing queries against the resource. <br><br> This approach also allows multiple IoT hubs to safely share a single Log Analytics workspace as a metrics database. |
-|  5️ | *Option 2* sends the metrics to IoT Hub.<sup>1</sup> The collector module can be configured to send the collected metrics as UTF-8 encoded JSON [device-to-cloud messages](../iot-hub/iot-hub-devguide-messages-d2c.md) via the `edgeHub` module. This option unlocks monitoring of locked-down IoT Edge devices that are allowed external access to only the  IoT Hub endpoint. It also enables monitoring of downstream IoT Edge devices in a nested configuration where downstream devices can only access their parent device. |
+|  5️ | *Option 2* sends the metrics to IoT Hub.<sup>1</sup> The collector module can be configured to send the collected metrics as UTF-8 encoded JSON [device-to-cloud messages](../iot-hub/iot-hub-devguide-messages-d2c.md) via the `edgeHub` module. This option unlocks monitoring of locked-down IoT Edge devices that are allowed external access to only the  IoT Hub endpoint. It also enables monitoring of downstream IoT Edge devices in a nested configuration where child devices can only access their parent device. |
 |  6️ | When metrics are routed via IoT Hub, a (one-time) cloud workflow needs to be set up. The workflow processes messages arriving from the metrics-collector module and sends them to the Log Analytics workspace. The workflow enables the [curated visualizations](how-to-explore-curated-visualizations.md) and [alerts](how-to-create-alerts.md) functionality even for metrics arriving via this optional path. See the [Route metrics through IoT Hub](#route-metrics) section for details on how to set up this cloud workflow. |
 
 <sup>1</sup> Currently, using *option 1* to directly transport metrics to Log Analytics from the IoT Edge device is the simpler path that requires minimal setup. The first option is preferred unless your specific scenario demands the *option 2* approach so that the IoT Edge device communicates only with IoT Hub.
@@ -50,7 +50,7 @@ To configure monitoring on your IoT Edge device follow the [Tutorial: Monitor Io
 |  2️ | The [metrics-collector module](https://aka.ms/edgemon-metrics-collector) is a Microsoft-supplied IoT Edge module that collects workload module metrics and transports them off-device. Metrics collection uses a *pull* model. Collection frequency, endpoints, and filters can be configured to control the data egressed from the module. For more information, see [metrics collector configuration section](#metrics-collector-configuration) later in this article. |
 |  3️ | You have two options for sending metrics from the metrics-collector module to the cloud. *Option 1* sends the metrics to Log Analytics. The collected metrics are ingested into the specified Log Analytics workspace using a fixed, native table called `InsightsMetrics`. This table's schema is compatible with the Prometheus metrics data model.<br><br> This option requires access to the workspace on outbound port 443. The Log Analytics workspace ID and key must be specified as part  of the module configuration. To enable in restricted networks, see [Enable in restricted network access scenarios](#enable-in-restricted-network-access-scenarios) later in this article.
 |  4️ | Each metric entry contains the `ResourceId` that was specified as part of [module configuration](#metrics-collector-configuration). This association automatically  links the metric with the specified resource (for example, IoT Central). As a result, the [curated IoT Edge workbook templates](how-to-explore-curated-visualizations.md) can retrieve metrics by issuing queries against the resource. <br><br> This approach also allows multiple IoT Central applications to safely share a single Log Analytics workspace as a metrics database. |
-|  5️ | *Option 2* sends the metrics to IoT Central. This option lets an operator view the metrics and device telemetry in a single location. The collector module can be configured to send the collected metrics as UTF-8 encoded JSON [device-to-cloud messages](../iot-hub/iot-hub-devguide-messages-d2c.md) via the `edgeHub` module. This option unlocks monitoring of locked-down IoT Edge devices that are allowed external access to only the IoT Central endpoint. It also enables monitoring of downstream IoT Edge devices in a nested configuration where downstream devices can only access their parent device. |
+|  5️ | *Option 2* sends the metrics to IoT Central. This option lets an operator view the metrics and device telemetry in a single location. The collector module can be configured to send the collected metrics as UTF-8 encoded JSON [device-to-cloud messages](../iot-hub/iot-hub-devguide-messages-d2c.md) via the `edgeHub` module. This option unlocks monitoring of locked-down IoT Edge devices that are allowed external access to only the IoT Central endpoint. It also enables monitoring of downstream IoT Edge devices in a nested configuration where child devices can only access their parent device. |
 
 ---
 
@@ -263,7 +263,7 @@ Set `NO_PROXY` value to a comma-separated list of hostnames that should be exclu
 
 # [IoT Hub](#tab/iothub)
 
-Sometimes it's necessary to ingest metrics though IoT Hub instead of sending them directly to Log Analytics. For example, when monitoring [IoT Edge devices in a nested configuration](tutorial-nested-iot-edge.md) where downstream devices have access only to the IoT Edge hub of their parent device. Another example is when deploying an IoT Edge device with outbound network access only to IoT Hub.
+Sometimes it's necessary to ingest metrics though IoT Hub instead of sending them directly to Log Analytics. For example, when monitoring [IoT Edge devices in a nested configuration](tutorial-nested-iot-edge.md) where child devices have access only to the IoT Edge hub of their parent device. Another example is when deploying an IoT Edge device with outbound network access only to IoT Hub.
 
 To enable monitoring in this scenario, the metrics-collector module can be configured to send metrics as device-to-cloud (D2C) messages via the edgeHub module. The capability can be turned on by setting the `UploadTarget` environment variable to `IoTMessage` in the collector [configuration](#metrics-collector-configuration).
 
@@ -281,7 +281,7 @@ A cloud workflow that delivers metrics messages from IoT Hub to Log Analytics is
 
 # [IoT Central](#tab/iotcentral)
 
-Sometimes it's necessary to ingest metrics though IoT Central instead of sending them directly to Log Analytics. For example, when monitoring [IoT Edge devices in a nested configuration](tutorial-nested-iot-edge.md) where downstream devices have access only to the IoT Edge hub of their parent device. Another example is when deploying an IoT Edge device with outbound network access only to IoT Central.
+Sometimes it's necessary to ingest metrics though IoT Central instead of sending them directly to Log Analytics. For example, when monitoring [IoT Edge devices in a nested configuration](tutorial-nested-iot-edge.md) where child devices have access only to the IoT Edge hub of their parent device. Another example is when deploying an IoT Edge device with outbound network access only to IoT Central.
 
 To enable monitoring in this scenario, the metrics-collector module can be configured to send metrics as device-to-cloud (D2C) messages via the edgeHub module. The capability can be turned on by setting the `UploadTarget` environment variable to `IoTMessage` in the collector [configuration](#metrics-collector-configuration).
 

articles/iot-edge/how-to-configure-api-proxy-module.md

@@ -22,7 +22,10 @@ The API proxy module simplifies communication for IoT Edge devices when multiple
 
 For example, to allow downstream IoT Edge devices to pull Docker images requires deploying a Docker registry module. To allow uploading blobs requires deploying an Azure Blob Storage module on the same IoT Edge device. Both these services use HTTPS for communication. The API proxy enables such deployments on an IoT Edge device. Instead of each service, the API proxy module binds to port 443 on the host device and routes the request to the correct service module running on that device per user-configurable rules. The individual services are still responsible for handling the requests, including authenticating and authorizing the clients.
 
-Without the API proxy, each service module would have to bind to a separate port on the host device, requiring a tedious and error-prone configuration change on each downstream device that connects to the parent IoT Edge device.
+Without the API proxy, each service module would have to bind to a separate port on the host device, requiring a tedious and error-prone configuration change on each child device that connects to the parent IoT Edge device.
+
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
 
 ## Deploy the proxy module
 

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

@@ -31,6 +31,9 @@ This article discusses basic concepts for downstream device connections and guid
 
 In this article, the terms *gateway* and *IoT Edge gateway* refer to an IoT Edge device configured as a transparent gateway.
 
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+
 ## Prerequisites
 
 * Have the root CA certificate file that was used to generate the device CA certificate in [Configure an IoT Edge device to act as a transparent gateway](how-to-create-transparent-gateway.md) available on your downstream device. Your downstream device uses this certificate to validate the identity of the gateway device. If you used the demo certificates, the root CA certificate is called **azure-iot-test-only.root.ca.cert.pem**.

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 (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.
+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 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 (parent) device and any downstream (child) 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 device and any downstream 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/iot-edge-as-gateway.md

@@ -63,6 +63,9 @@ Beginning with version 1.2 of IoT Edge, transparent gateways can handle connecti
 
 You declare transparent gateway relationships in IoT Hub by setting the IoT Edge gateway as the *parent* of a downstream device *child* that connects to it.
 
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+
 The parent/child relationship is established at three points in the gateway configuration:
 
 #### Cloud identities

articles/iot-edge/offline-capabilities.md

@@ -59,6 +59,9 @@ A device's *EdgeAgent* updates its reported properties whenever there is a chang
 
 By default, a parent device can have up to 100 children. You can change this limit by setting the **MaxConnectedClients** environment variable in the edgeHub module. A child device only has one parent.
 
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+
 <!-- 1.1 -->
 :::moniker range="iotedge-2018-06"
 

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

@@ -47,6 +47,9 @@ This tutorial uses a two device hierarchy for simplicity, pictured below. One de
 
 ![Diagram that shows the structure of the tutorial hierarchy, containing two devices: the top layer device and the lower layer device.](./media/tutorial-nested-iot-edge/tutorial-hierarchy-diagram.png)
 
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+
 ## Prerequisites
 
 To create a hierarchy of IoT Edge devices, you'll need:

articles/iot-edge/tutorial-nested-iot-edge.md

@@ -48,6 +48,9 @@ This tutorial uses a two device hierarchy for simplicity, pictured below. One de
 
 ![Structure of the tutorial hierarchy, containing two devices: the top layer device and the lower layer device](./media/tutorial-nested-iot-edge/tutorial-hierarchy-diagram.png)
 
+>[!NOTE]
+>A downstream device is a lockdown device that emits data directly to the Internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+
 ## Prerequisites
 
 To create a hierarchy of IoT Edge devices, you will need: