Additional GEP cleanup, including new hierarcy diagram

site-src/geps/gep-713.md

@@ -24,6 +24,11 @@ portable.
 * Provide a consistent way that both included and implementation-specific
   policies can be interpreted
 
+## Out of scope
+
+* Define all potential policies that may be attached to resources
+* Design the full structure and configuration of policies
+
 ## API
 
 This approach is building on concepts from all of the alternatives discussed
@@ -138,25 +143,15 @@ type PolicyTargetReference struct {
 ```
 
 ### Hierarchy
-Policy precedence is determined in the same direction a request flows. For
-ingress, that means from Gateway to Backend, and for mesh that means from
-Consumer to Backend. 
-
-| Ingress | Sidecar Consumer |
-|-|-|
-| GatewayClass* | GatewayClass* |
-| Gateway Namespace | Consumer Namespace |
-| Gateway | Consumer Route |
-| Route Namespace | Consumer |
-| Route | Backend Namespace |
-| Backend Namespace | Backend Route |
-| Backend | Backend |
-
 Each policy may include default or override values. Default values are given
 precedence from the bottom up, while override values are top down. That means
 that a default attached to a Backend will have the highest precedence among
 default values while an override value attached will have the highest precedence
-overall. To illustrate this, consider 3 resources with the following hierarchy:
+overall.
+
+![Ingress and Sidecar Hierarchy](images/713-hierarchy.png)
+
+To illustrate this, consider 3 resources with the following hierarchy:
 A > B > C. When attaching the concept of defaults and overrides to that, the
 hierarchy would be expanded to this:
 
@@ -240,7 +235,7 @@ spec:
   targetRef:
     group: networking.acme.io
     kind: ExternalService
-    hostname: foo.com
+    name: foo.com
 ```
 
 ### Apply Policies to Specific Matches
@@ -393,6 +388,13 @@ controller implementation:
 ### Disadvantages
 * May be difficult to understand which policies apply to a request
 
+## Removing BackendPolicy
+BackendPolicy represents the initial attempt to cover policy attachment for
+Gateway API. Although this proposal ended up with a similar structure to
+BackendPolicy, it is not clear that we ever found sufficient value or use cases
+for BackendPolicy. Given that this proposal provides more powerful ways to
+attach policy, it makes sense to remove BackendPolicy until we have a better
+alternative.
 
 ## Alternatives
 
@@ -466,11 +468,24 @@ defaults and allow overrides at different levels.
 * May be difficult to modify Routes and Services if other components/roles are
   managing them (eg Knative)
 
-
-## Out of scope
-
-* Define all potential policies that may be attached to resources
-* Design the full structure and configuration of policies
+### 3. Shared Policy Resource
+This is really just a slight variation or extension of the main proposal in this
+GEP. We would introduce a shared policy resource. This resource would follow the
+guidelines described above, including the `targetRef` as defined as well as
+`default` and `override` fields. Instead of carefully crafted CRD schemas for
+each of the `default` and `override` fields, we would use more generic
+`map[string]string` values. This would allow similar flexibility to annotations
+while still enabling the default and override concepts that are key to this
+proposal.
+
+Unfortunately this would be difficult to validate and would come with many of
+the downsides of annotations. A validating webhook would be required for any
+validation which could result in just as much or more work to maintain than
+CRDs. At this point we believe that the best experience will be from
+implementations providing their own policy CRDs that follow the patterns
+described in this GEP. We may want to explore tooling or guidance to simplify
+the creation of these policy CRDs to help simplify implementation and extension
+of this API.
 
 ## References