Update reference-command-line-arguments.md

[delema98]

The edited cli-arguments specify the behavior for outgoing messages. Therefore it should be named "downstream" and not "upstream"

[prmerger-automator[bot]]

@delema98 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[learn-build-service-prod[bot]]

Learn Build status updates of commit 31746c5:

:white_check_mark: Validation status: passed

File	Status	Preview URL	Details
articles/industrial-iot/reference-command-line-arguments.md	:white_check_mark:Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[Court72]

@hansgschossmann

Can you review the proposed changes?

When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team

[hansgschossmann]

replied

From: Courtney Wales @.> Sent: Friday, June 2, 2023 5:27 PM To: MicrosoftDocs/azure-docs @.> Cc: Hans Gschoßmann @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update reference-command-line-arguments.md (PR #110395)

@hansgschossmannhttps://github.com/hansgschossmann

Can you review the proposed changes?

When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-teamhttps://github.com/orgs/MicrosoftDocs/teams/public-repo-pr-review-team

Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/110395#issuecomment-1573926849, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6F5FQZYV2ZIL4527C3SYLXJIA5FANCNFSM6AAAAAAYYFTQYQ. You are receiving this because you were mentioned.Message ID: @.@.>>

[hansgschossmann]

I have a different opinion on this. Looking at the examples of https://reflectoring.io/upstream-downstream/:

1. Example OPC Publisher (C) depends on IoT Edge Hub (B) depends on IoT Hub (C): downstream is OPC Publisher, upstream is IoT Hub in the cloud

2. Example

Same here OPC Publisher is in this picture the User (downstream) and cloud is upstream.

Thx Hans

From: delema98 @.> Sent: Monday, June 5, 2023 8:05 AM To: MicrosoftDocs/azure-docs @.> Cc: Hans Gschoßmann @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update reference-command-line-arguments.md (PR #110395)

@delema98 commented on this pull request.

---

In articles/industrial-iot/reference-command-line-arguments.mdhttps://github.com/MicrosoftDocs/azure-docs/pull/110395#discussion_r1217548888:

@@ -145,9 +145,9 @@ The Alternative field, when it's present, refers to the applicable CLI argumen

| LogFileFlushTimeSpan=VALUE | The timespan, in seconds, when the log file should be flushed in the storage account.
Alternative: --lt, --logflushtimespan
Mode: Standalone only
Environment variable
Type: timespan string {[d.]hh:mm:ss[.fffffff]}
Alternative argument type: integer, in seconds
Default: {00:00:30} |

| loglevel=Value | The level for logs to be persisted in the log file.
Alternative: --ll --loglevel
Mode: Standalone only
Type: string enum - fatal, error, warning, information, debug, verbose
Default: info |

| EdgeHubConnectionString=VALUE | An IoT Edge Device or IoT Edge module connection string to use. When it's deployed as a module in IoT Edge, the environment variable is already set as part of the container deployment.
Alternative: --dc, --deviceconnectionstring | --ec, --edgehubconnectionstring
Mode: Standalone, orchestrated
Type: connection string
Default: <not set> <set by iotedge run time> |

-| Transport=VALUE | The protocol to use for upstream communication to the IoT Edge hub or the IoT hub.
Alternative: --ih, --iothubprotocol
Mode: Standalone, orchestrated
Type: string enum - Any, Amqp, Mqtt, AmqpOverTcp, AmqpOverWebsocket, MqttOverTcp, MqttOverWebsocket, Tcp, Websocket
Default: MqttOverTcp |

-| BypassCertVerification=VALUE | Enables/disables the bypassing of certificate verification for upstream communication to EdgeHub.
Alternative: N/A
Mode: Standalone, orchestrated
Type: Boolean
Default: false |

-| EnableMetrics=VALUE | Enables/disables upstream metrics propagation.
Alternative: N/A
Mode: Standalone, orchestrated
Type: Boolean
Default: true |

+| Transport=VALUE | The protocol to use for downstream communication to the IoT Edge hub or the IoT hub.
Alternative: --ih, --iothubprotocol
Mode: Standalone, orchestrated
Type: string enum - Any, Amqp, Mqtt, AmqpOverTcp, AmqpOverWebsocket, MqttOverTcp, MqttOverWebsocket, Tcp, Websocket
Default: MqttOverTcp |

I could not find a suitable example in the MSFT documents. When describing a data flow, "upstream" usually refers to the phases before the service to be consumed, while "downstream" refers to the subsequent phases.

E.g.: https://reflectoring.io/upstream-downstream/

To prevent confusion,I think it's better to change it.

Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/110395#discussion_r1217548888, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6F5FX3EVMCUPSZX7FTT5DXJVZKFANCNFSM6AAAAAAYYFTQYQ. You are receiving this because you were mentioned.Message ID: @.@.>>

[delema98]

Ok yeah, I can see where you are coming from. You're looking at it in terms of dependencies, and I'm looking at the data flow where the source is e.g. a sensor and the sink is some cloud service. But am I right that e.g. the cli argument "Transport" specifies how the messages are sent towards the cloud? And if yes, could we maybe add that these arguments configure "outgoing" messages?

[hansgschossmann]

Using ‘outgoing’ instead of ‘upstream’ will add a lot of clarity. 😊

From: delema98 @.> Sent: Tuesday, June 6, 2023 9:15 AM To: MicrosoftDocs/azure-docs @.> Cc: Hans Gschoßmann @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Update reference-command-line-arguments.md (PR #110395)

Ok yeah, I can see where you are coming from. You're looking at it in terms of dependencies, and I'm looking at the data flow where the source is e.g. a sensor and the sink is some cloud service. But am I right that e.g. the cli argument "Transport" specifies how the messages are sent towards the cloud? And if yes, could we maybe add that these arguments configure "outgoing" messages?

— Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/110395#issuecomment-1578055518, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB6F5FXUXCGS64LXDCSCAQ3XJ3KFZANCNFSM6AAAAAAYYFTQYQ. You are receiving this because you were mentioned.Message ID: @.@.>>

[learn-build-service-prod[bot]]

Learn Build status updates of commit bcc1f57:

:white_check_mark: Validation status: passed

File	Status	Preview URL	Details
articles/industrial-iot/reference-command-line-arguments.md	:white_check_mark:Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[hansgschossmann]

#sign-off