updates from Mark

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>

daprdocs/content/en/concepts/terminology.md

@@ -17,8 +17,8 @@ This page details all of the common terms you may come across in the Dapr docs.
 | Dapr | Distributed Application Runtime. | [Dapr overview]({{< ref overview.md >}})
 | Dapr control plane | A collection of services that are part of a Dapr installation on a hosting platform such as a Kubernetes cluster. This allows Dapr-enabled applications to run on the platform and handles Dapr capabilities such as actor placement, Dapr sidecar injection, or certificate issuance/rollover. | [Self-hosted overview]({{< ref self-hosted-overview >}})<br />[Kubernetes overview]({{< ref kubernetes-overview >}})
 | HTTPEndpoint | HTTPEndpoint is a Dapr resource use to identify non-Dapr endpoints to invoke via the service invocation API. | [Service invocation API]({{< ref service_invocation_api.md >}})
+| Namespacing | Namespacing in Dapr provides isolation, and thus provides multi-tenancy. | Learn more about namespacing [components]({{< ref component-scopes.md >}}), [service invocation]({{< ref service-invocation-namespaces.md >}}), [pub/sub]({{< ref pubsub-scopes.md >}}), and [actors]({{< ref namespaced-actors.md >}})
 | Self-hosted | Windows/macOS/Linux machine(s) where you can run your applications with Dapr. Dapr provides the capability to run on machines in "self-hosted" mode. | [Self-hosted mode]({{< ref self-hosted-overview.md >}})
 | Service | A running application or binary. This can refer to your application or to a Dapr application.
 | Sidecar | A program that runs alongside your application as a separate process or container. | [Sidecar pattern](https://docs.microsoft.com/azure/architecture/patterns/sidecar)
-| Namespacing | Namespacing in Dapr provides isolation, and thus provides multi-tenancy. | Learn more about namespacing [components]({{< ref component-scopes.md >}}), [service invocation]({{< ref service-invocation-namespaces.md >}}), [pub/sub]({{< ref pubsub-scopes.md >}}), and [actors]({{< ref namespaced-actors.md >}})
 

daprdocs/content/en/developing-applications/building-blocks/actors/namespaced-actors.md

@@ -6,12 +6,11 @@ weight: 40
 description: "Learn about namespaced actors"
 ---
 
-Namespaced actors use the multi-tenant Placement service. With this service, in a scenario where each tenant has its own namespace, sidecars belonging to a tenant named "Tenant A" won't receive placement information for "Tenant B". 
 
 Namespacing in Dapr provides isolation, and thus multi-tenancy. With namespacing, the same actor type can be deployed into different namespaces. Instances of actors can call across these namespaces. 
 
 {{% alert title="Note" color="primary" %}}
-Note that the namespace is not part of the actor name (that is an actor id), namespace is used for the isolation of the deployed actor services.
+Each namespaced actor deployment must use its own separate state store, especially if the same actor type is used across namespaces. In other words, no namespace information is written as part of the actor record, and hence separate state stores are required for each namespace. See [Configuring actor state stores for namespacing]({{< ref "#configuring-actor-state-stores-for-namespacing" >}}) section for examples.
 {{% /alert %}}
 
 ## Creating and configuring namespaces
@@ -41,7 +40,9 @@ Then, deploy your actor applications into this namespace (in the example, `names
 
 ## Configuring actor state stores for namespacing
 
-While you could use different physical databases for each actor namespace, some state store components provide a way to logically separate data by table, prefix, collection, and more. This allows you to use the same physical database for multiple namespaces, as long as you provide the logical separation in the Dapr component definition.
+Each namespaced actor deployment **must** use its own separate state store. While you could use different physical databases for each actor namespace, some state store components provide a way to logically separate data by table, prefix, collection, and more. This allows you to use the same physical database for multiple namespaces, as long as you provide the logical separation in the Dapr component definition.
+
+Some examples are provided below.
 
 ### Example 1: By a prefix in etcd
 
@@ -100,10 +101,24 @@ spec:
     value: "true"
   - name: redisDB
     value: "1"
+  - name: redisPassword
+    secretKeyRef:
+      name: redis-secret
+      key:  redis-password
+  - name: actorStateStore
+    value: "true"
+  - name: redisDB
+    value: "1"
+auth:
+  secretStore: <SECRET_STORE_NAME>
 ```
 
 Check your [state store component specs]({{< ref supported-state-stores.md >}}) to see what it provides.
 
+{{% alert title="Note" color="primary" %}}
+Namespaced actors use the multi-tenant Placement service. With this control plane service where each application deployment has its own namespace, sidecars belonging to an application in namespace "ActorA" won't receive placement information for an application in namespace "ActorB".
+{{% /alert %}}
+
 ## Next steps
 - [Learn more about the Dapr Placement service]({{< ref placement.md >}})
 - [Placement API reference guide]({{< ref placement_api.md >}})