Clarify namespace sameness wrt policy

After many discussions with customers and implementors, I think we need
to clarify that implementations DO have an axis of freedom around
implementation-defined control of sameness.

E.g. "Sameness applies to <this namespace> only in <these clusters>,
and to <that namespace> in <those clusters>."

Author: thockin

sig-multicluster/namespace-sameness-position-statement.md

@@ -1,38 +1,42 @@
 # Namespace Sameness - SIG Multicluster Position Statement
 
 Author: Jeremy Olmsted-Thompson (**[@jeremyot](https://github.com/jeremyot)**), Google  
-Last Edit: 2020/04/20  
+Last Edit: 2022/07/18
 Status: RELEASED
 
 ## Goal
+
 To establish a normative statement for multi-cluster namespace semantics and
 governance as a building block for further development which will require
 specifying behaviors across clusters.
 
 ## Context
+
 Users are reaching for multi-cluster deployments for a
 [variety of reasons](http://bit.ly/k8s-multicluster-conversation-starter-doc).
-However, Kubernetes treats the cluster boundary as the edge of the universe.
-There are currently no standard practices for how to extend the Kubernetes
-resource model across multiple clusters. Without common patterns we can’t build
-portable tooling to facilitate multi-cluster capabilities and know that behavior
-will be consistent for each user.
+However, Kubernetes has historically treated the cluster boundary as the edge
+of the universe.  Without common patterns we can’t build portable tooling to
+facilitate multi-cluster capabilities and know that behavior will be consistent
+for each user.
 
 ## Scope
+
 A single organization may need multiple, disjoint sets of clusters. They may,
 for example, represent different phases of the development lifecycle (dev,
 staging, prod) or support unrelated projects. Each organization governs their
 own clusters in isolation, so the scope of a namespace can only reasonably be
 declared within the organizational boundary. The scope of namespace identity is
-defined as the union of clusters, governed by a single authority, that are
+defined as the set of all clusters, governed by a single authority, that are
 expected to work together.  An authority is a company, organization, team,
 individual, or other entity which is entrusted to manage these clusters and, in
 particular, to create namespaces in them.
 
 ## Position
+
 **For a set of related clusters governed by a single authority, all namespaces of
-a given name are considered to be the same namespace. A single namespace should
-have a consistent owner across the set of clusters.**
+a given name are considered to be the same namespace, unless otherwise dictated
+by the authority's policy. A single namespace should have a consistent owner
+across the set of clusters.**
 
 ## Appendix
 
@@ -48,7 +52,7 @@ healthy.  They also have app-teams, "foo" and "bar" which use those clusters.
 
 Cluster-ops owns the creation of namespaces in both clusters. They can choose
 to delegate the ability to create namespaces to foo-team and bar-team, but any
-namespace name that is allocated in "reserved" in all clusters.  How the
+namespace name that is allocated is "reserved" in all clusters.  How the
 delegation works is an area for innovation, but some possible examples
 include:
   * A self-service portal which allocate a name in a global database and
@@ -92,10 +96,29 @@ thus namespce sameness applies), the implementation of multi-cluster services
 probably should not be on-by-default.  The details of how multi-cluster
 services will work are an area for innovation, but ideas include:
   * Opt-in: services must be "exported" to be merged across clusters
-  * Opt-out: services or namespace can be opted out of service merging
+  * Opt-out: services or namespaces can be opted out of sameness
   * Different discovery: merged services and "raw" services use different names
     or other discovery mechanisms
 
 However the implementation works, the metrics service is not automatically
 merged across clusters, though the LDAP-to-RBAC sync from example 2 can still
 apply consistent policies.
+
+### Example 4: Authority sameness policy
+
+Consider the same organization from previous examples, but with more clusters:
+A, B, C, and D.  They want to assign foo-team's namespaces to clusters A and B,
+and bar-team's namespaces to clusters C and D.  They also want to ensure that
+the opposite is never true - foo-team's namespaces cannot be used in clusters C
+or D, and bar-team's namespaces cannot be used from clusters A or B.
+
+As an implementation choice, the authority may offers controls which govern
+which cluster-namespaces are considered for sameness.  For example, it could
+express "all namespaces prefixed with 'foo-' may be merged from clusters A and
+B" and "all namespaces prefixed with 'bar-' may be merged from clusters C and
+D".  If a "foo-something" namespace is found in cluster C it would _not_ be
+considered for sameness.  The details of how these policies might be expressed
+are an area for innovation, but ideas include:
+  * In-cluster namespace labels or annotations
+  * In-cluster custom-resources
+  * An external control-plane API