Conversation
✅ Deploy Preview will be available once build job completes!
|
There was a problem hiding this comment.
Thanks for surfacing the acceptance status, @mpalav08 — this is a genuinely useful confirmation step for anyone waiting to see whether their connection went through. I ran the F5 Technical Writing Style Guide check that the gardening rotation expects before a writer picks this up. One style point applies to both new confirmation bullets, and I have a couple of technical-accuracy questions for a subject matter expert to confirm before merge.
Style
Both new sub-bullets read ... should be in an accepted state, indicating that the deployment accepted the connection. Two things there:
shouldis ambiguous — a reader can't tell if it's expected behavior or a recommendation (may-can-might). State the result directly in present tense (hedging,tense).- Written as one sentence it runs past the 20-word task limit and uses the
-ingformindicating(sentence-length,gerunds). Splitting into two short sentences fixes both.
I've left an inline suggestion on each line with wording that keeps your meaning. Please confirm the exact on-screen label with an SME (see below) before accepting — I don't want the suggested wording to lock in a state name I can't verify.
Technical accuracy (for an SME to verify — I have not changed any of this)
- Immediacy after Save. Both bullets imply the ID reaches the accepted state right after Save Changes. If acceptance is asynchronous (the console may take a moment, or the user may need to refresh), the step should say so.
- Exact status label. Please confirm the console shows the wording "accepted" (versus, for example, "Accepted" or "Available") so the prose matches the UI.
- Menu path for the read-only view. The new peering bullet points readers to
Cloud Settings>Upstream Network, while the Edit step just above usesCloud Details>Upstream Network. This matches the private-endpoint pattern earlier in the page (Cloud Settingsfor the read-only Details view,Cloud Detailsinside Edit), so it's likely correct — just worth an SME confirming the read-only path isCloud Settings.
Reading level
The surrounding steps are clean and imperative. The only complexity the change adds is the single long, hedged sentence flagged above; splitting it brings both bullets back in line with the rest of the procedure.
| 1. Ensure your deployment's **PrivateLink Connection Allow List** includes the AWS account ID or VPC endpoint ID to accept the PrivateLink connection. | ||
| - To add an entry to the allow list, go to your deployment's Details tab, select **Edit**, and add the VPC endpoint ID or AWS account ID to the allow list. | ||
| 1. Select **Save Changes** to allow NGINXaaS to accept the PrivateLink connection request. | ||
| - The corresponding VPC endpoint ID under **Cloud Settings** > **Service Frontend** > **PrivateLink Connection Allow List** should be in an accepted state, indicating that the deployment accepted the connection. |
There was a problem hiding this comment.
should is ambiguous here, and stating a verification result as one long -ing sentence trips sentence-length, hedging, and gerunds. Suggested direct, present-tense wording (please confirm the exact status label with an SME before accepting):
| - The corresponding VPC endpoint ID under **Cloud Settings** > **Service Frontend** > **PrivateLink Connection Allow List** should be in an accepted state, indicating that the deployment accepted the connection. | |
| - The VPC endpoint ID under **Cloud Settings** > **Service Frontend** > **PrivateLink Connection Allow List** changes to an accepted state. This confirms the deployment accepted the connection. |
Style topics: may-can-might, hedging, tense, gerunds, sentence-length.
| 1. Note the resulting **VPC Peering Connection ID**, for example `pcx-0123456789abcdef0`, shown in the AWS VPC console **Peering Connections** list. | ||
| 1. On your deployment's Details tab, select **Edit**, go to **Cloud Details** > **Upstream Network**, select **+ Add Entry**, and add the VPC Peering Connection ID. | ||
| 1. Select **Save Changes** to allow NGINXaaS to accept the peering connection request. | ||
| - The corresponding VPC peering connection ID under **Cloud Settings** > **Upstream Network** should be in an accepted state, indicating that the deployment accepted the connection. |
There was a problem hiding this comment.
Same finding as the PrivateLink bullet: replace should be ... indicating with a direct present-tense statement. Suggested wording (confirm the exact status label with an SME first):
| - The corresponding VPC peering connection ID under **Cloud Settings** > **Upstream Network** should be in an accepted state, indicating that the deployment accepted the connection. | |
| - The VPC peering connection ID under **Cloud Settings** > **Upstream Network** changes to an accepted state. This confirms the deployment accepted the connection. |
Style topics: may-can-might, hedging, tense, gerunds, sentence-length.
Proposed changes
Update network connectivity docs to include the following information:
Users can now confirm the vpce ID / peer connection ID acceptance status indicating if it has been accepted by the deployment after they apply their update to the AWS deployment.
Checklist
Before sharing this pull request, I completed the following checklist:
Footnotes
Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩