GEP-1619: Review Updates

- Changed anticipated support for route rule section into full support
  since GEP-713 was updated.
- Various typos.
- Added sentence on implementations handling persistence on requests
  from the same browser page.

geps/gep-1619.md

@@ -71,7 +71,7 @@ Header-based stateful sessions are achieved by a backend or gateway providing an
 
 **3. URL-Encoded Session Persistence**
 
-Session information can be also encoded into the request URL to establish a persistent session. The server rewrites the client's URL to encode the new session information automatically. The server then decodes the session information from the URL to identify the session.
+Session information can be also encoded into the request URL to establish a persistent session. The server rewrites the client's URL to encode the new session information automatically. The server or the gateway then decodes the session information from the URL to identify the session.
 
 ### Session Persistence Initiation
 
@@ -81,7 +81,7 @@ component.
 
 Let's consider a simple implementation comprised of gateways and backends. The following rules apply based on who initiates the session:
 - If the gateway initiates the session, the backend will be presented with session attributes regardless if it enabled them.
-- If the backend initiates the session, the gateway should allow this and not force persistence connections, unless
+- If the backend initiates the session, the gateway should allow this and not force persistent connections, unless
   specifically configured to[^1]. The gateway may decode and alter the cookie established by the backend to achieve
   session persistence.
 
@@ -318,7 +318,8 @@ type SessionPersistencePolicy struct {
 // Note: there is no Override or Default policy configuration.
 type SessionPersistencePolicySpec struct {
     // TargetRef identifies an API object to apply policy to.
-    // The TargetRef may be a Service, HTTPRoute, or GRPCRoute.
+    // The TargetRef may be a Service, HTTPRoute, GRPCRoute,
+    // or a HTTPRouteRule or GRPCRouteRule section.
     // At least one of these targets must be supported for
     // core-level compliance.
     //
@@ -453,25 +454,27 @@ for more details).
 
 ### API Attachment Points
 
-The `SessionPersistencePolicy` metaresource can target both a service and route object. The core functionality of
-attaching it to either is generally identical. The distinction lies in where the configuration gets propagated: when
-attached to a route, it can define session persistence for multiple services, whereas attaching it to a service defines
-it for a single service. Enabling session persistence doesn't require configuration on both the route and service;
-configuring it on either one is sufficient.
+The `SessionPersistencePolicy` metaresource can target a service, route, and a route rule section (e.g. [HTTPRouteRule](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1.HTTPRouteRule)).
+The core functionality of attaching it any of these is generally identical. The distinction lies in where the
+configuration gets propagated: when attached to a route or a route rule, it can define session persistence for multiple
+services, whereas attaching it to a service defines it for a single service. Enabling session persistence doesn't
+require configuration on the route, route rule, and service; configuring it on any one is sufficient.
 
 Given that certain implementations will only support attaching to services, and considering that some implementations
 might want to solely support attachment to routes, implementations must provide support for at least one of the options
-(route or service) to be compliant with this GEP.
+(route, route rule, or service) to be compliant with this GEP.
 
-Edge cases will arise when providing supporting both routes and services. For guidance on addressing conflicting
-attachments, please consult the [Expected API Behavior](#expected-api-behavior) section, which outlines API use cases.
+Attaching `SessionPersistencePolicy` to a route ensures session persistence for all possible paths the route can take.
+Conversely, attaching to a route rule section provides session persistence exclusively for that route rule. Without the
+capability to target a specific rule section within a route, users might be required to decompose their route into
+multiple routes to satisfy different session persistence requirements for each individual route path.
 
-We are anticipating the possibility of future enhancements in supporting the selection of the route rule (e.g. [HTTPRouteRule](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1.HTTPRouteRule))
-section within xRoutes, contingent upon updates to [GEP-713](/geps/gep-713) for incorporating section targeting (PR [#2283](https://github.com/kubernetes-sigs/gateway-api/pull/2283)).
-Enabling the attachment to the route rule sections will enable a more granular association of session persistence to
-route paths. Without the capability to target a specific rule section within a route, users might be required to
-decompose their route into multiple routes to satisfy different session persistence requirements for each individual
-route path.
+Edge cases will arise when providing supporting services, routes, and the route rule section. For guidance on addressing
+conflicting attachments, please consult the [Expected API Behavior](#expected-api-behavior) section, which outlines API
+use cases.
+
+To learn more about the process of attaching to services, routes, and the route rule section, please refer to
+[GEP-713](/geps/gep-713).
 
 ### Traffic Splitting
 
@@ -550,6 +553,8 @@ session won't be shared between these two paths.
 Conversely, if the `SessionPersistencePolicy` policy is attached to a service, the `Path` attribute should be left
 unset. This is because multiple routes can target a single service. If the `Path` cookie attribute is configured in this
 scenario, it could result in problems due to the possibility of different paths being taken for the same cookie.
+Implementations should also handle the case where client is a browser making requests to multiple persistent services
+from the same page.
 
 #### Secure, HttpOnly, SameSite
 
@@ -727,14 +732,12 @@ The following are items that we intend to resolve before we consider this GEP im
 
 - We need to identify and document requirements regarding session draining and migration. How do implementations drain established sessions during backend upgrades without disruption?
   - Do we need a "session draining timeout" as documented by [A55: xDS-Based Stateful Session Affinity for Proxyless gRPC](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md#background)
-    define in this API?
+    defined in this API?
 - We need to document sessions with Java in greater detail. Java standardized the API and behavior of session persistence long ago and would be worth examining.
 - We need to add a small section on compliance regarding the browser and client relationship.
 - We need to finish enumerating all the edge cases in [Expected API Behavior](#expected-api-behavior) and identify
-potential scenarios where session persistence could break so implementation can implement session persistence in a
+potential scenarios where session persistence could break so an implementation can implement session persistence in a
 predicable way.
-- Update the GEP for targeting a route rule section when [#2283](https://github.com/kubernetes-sigs/gateway-api/pull/2283)
-gets merged in [GEP-713](/geps/gep-713).
 
 ## Alternatives