Repository: kubernetes-sigs/gateway-api

Issue:
GEP: Backend Protocol Selection
/kind gep

This is an attempt to separate out the backend protocol selection from [GEP-1282](https://github.com/kubernetes-sigs/gateway-api/issues/1282). This is similar to how TLS use-cases are being split out into [GEP-1897](https://github.com/kubernetes-sigs/gateway-api/issues/1897)


<!-- Please only use this template for submitting enhancement requests -->

**What would you like to be added**:

The ability to express the protocols supported by backends.

**Why this is needed**:

Not all implementation support automatic protocol selection. Even in some cases protocols are disabled without an explicit opt-in (ie. websockets). Thus application developers need the ability specify the protocol of their applications.



Hints from issue comments:
@dprotaso: /assign @dprotaso @dprotaso: For those following GEP PR is out - https://github.com/kubernetes-sigs/gateway-api/pull/1979@shaneutt: Since the GEP already exists and _because_ it's a GEP it seems reasonable to consider this accepted:

/triage accepted

However, it doesn't seem clear to me that this is something we _must_ sort out prior to GA (though I invite arguments to the contrary) so at least for now we wont consider this a blocker for GA and it will have a lower priority than GA-oriented work:

/priority backlog@dprotaso: @shaneutt the GA backlog has #1282 -  you could say this GEP and #1897 are part the fallout of that original GEP
@shaneutt: ACK

Ultimately it's just not clear that this is something we _must_ have for GA :thinking: 

Since you're working on it anyway, let's go ahead and track it on the board. But we should probably take another look at what it's gonna take to implement and do some planning and prioritization then.@robscott: Leaving this open until this GEP either graduates to standard or is removed from the API.

/kind gep
/reopen@k8s-ci-robot: @robscott: Reopened this issue.

<details>

In response to [this](https://github.com/kubernetes-sigs/gateway-api/issues/1911#issuecomment-1836963386):

>Leaving this open until this GEP either graduates to standard or is removed from the API.
>
>/kind gep
>/reopen


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
</details>@k8s-triage-robot: This issue has not been updated in over 1 year, and should be re-triaged.

You can:
- Confirm that this issue is still relevant with `/triage accepted` (org members only)
- Close this issue with `/close`

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted@k8s-triage-robot: The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity, `lifecycle/stale` is applied
- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed

You can:
- Mark this issue as fresh with `/remove-lifecycle stale`
- Close this issue with `/close`
- Offer to help out with [Issue Triage][1]

Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community).

/lifecycle stale

[1]: https://www.kubernetes.dev/docs/guide/issue-triage/@aviallon: /close
Implemented by https://github.com/kubernetes-sigs/gateway-api/pull/1979@k8s-ci-robot: @aviallon: Closing this issue.

<details>

In response to [this](https://github.com/kubernetes-sigs/gateway-api/issues/1911#issuecomment-2748596744):

>/close
>Implemented by https://github.com/kubernetes-sigs/gateway-api/pull/1979


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>

Solution patch:
diff --git a/apis/v1beta1/gateway_types.go b/apis/v1beta1/gateway_types.go
index 3aae68f6..7cf810fa 100644
--- a/apis/v1beta1/gateway_types.go
+++ b/apis/v1beta1/gateway_types.go
@@ -85,38 +85,55 @@ type GatewaySpec struct {
 	//
 	// Port and protocol combinations not listed above are considered Extended.
 	//
-	// An implementation MAY group Listeners by Port and then collapse each
-	// group of Listeners into a single Listener if the implementation
-	// determines that the Listeners in the group are "compatible". An
-	// implementation MAY also group together and collapse compatible
-	// Listeners belonging to different Gateways.
-	//
-	// For example, an implementation might consider Listeners to be
-	// compatible with each other if all of the following conditions are
-	// met:
-	//
-	// 1. Either each Listener within the group specifies the "HTTP"
-	//    Protocol or each Listener within the group specifies either
-	//    the "HTTPS" or "TLS" Protocol.
-	//
-	// 2. Each Listener within the group specifies a Hostname that is unique
-	//    within the group.
-	//
-	// 3. As a special case, one Listener within a group may omit Hostname,
-	//    in which case this Listener matches when no other Listener
-	//    matches.
-	//
-	// If the implementation does collapse compatible Listeners, the
-	// hostname provided in the incoming client request MUST be
-	// matched to a Listener to find the correct set of Routes.
-	// The incoming hostname MUST be matched using the Hostname
-	// field for each Listener in order of most to least specific.
-	// That is, exact matches must be processed before wildcard
-	// matches.
-	//
-	// If this field specifies multiple Listeners that have the same
-	// Port value but are not compatible, the implementation must raise
-	// a "Conflicted" condition in the Listener status.
+	// A Gateway's Listeners are considered "compatible" if:
+	//
+	// 1. The implementation can serve them in compliance with the Addresses
+	//    requirement that all Listeners are available on all assigned
+	//    addresses.
+	// 2. The implementation can match inbound requests to a single distinct
+	//    Listener. When multiple Listeners share values for fields (for
+	//    example, two Listeners with the same Port value), the implementation
+	//    can can match requests to only one of the Listeners using other
+	//    Listener fields.
+	//
+	// Compatible combinations in Extended support are expected to vary across
+	// implementations. A combination that is compatible for one implementation
+	// may not be compatible for another.
+	//
+	// If this field specifies multiple Listeners that are not compatible, the
+	// implementation MUST set the "Conflicted" condition in the Listener
+	// Status to "True".
+	//
+	// Implementations MAY choose to still accept a Gateway with conflicted
+	// Listeners if they accept a partial Listener set that contains no
+	// incompatible Listeners. They MUST set a "ListenersNotValid" condition
+	// the Gateway Status when the Gateway contains incompatible Listeners
+	// whether or not they accept the Gateway.
+	//
+	// For example, the following Listener scenarios may be compatible
+	// depending on implementation capabilities:
+	//
+	// 1. Multiple Listeners with the same Port that all use the "HTTP"
+	//    Protocol that all have unique Hostname values.
+	// 2. Multiple Listeners with the same Port that use either the "HTTPS" or
+	//    "TLS" Protocol that all have unique Hostname values.
+	// 3. A mixture of "TCP" and "UDP" Protocol Listeners, where no Listener
+	//    with the same Protocol has the same Port value.
+	//
+	// An implementation that cannot serve both TCP and UDP listeners on the same
+	// address, or cannot mix HTTPS and generic TLS listens on the same port
+	// would not consider those cases compatible.
+	//
+	// Implementations using the Hostname value to select between same-Port
+	// Listeners MUST match inbound request hostnames from the most specific
+	// to least specific Hostname values to find the correct set of Routes.
+	// Exact matches must be processed before wildcard matches, and wildcard
+	// matches must be processed before fallback (empty Hostname value)
+	// matches. For example, `"foo.example.com"` takes precedence over
+	// `"*.example.com"`, and `"*.example.com"` takes precedence over `""`.
+	//
+	// Implementations MAY merge separate Gateways onto a single set of
+	// Addresses if all Listeners across all Gateways are compatible.
 	//
 	// Support: Core
 	//
diff --git a/apis/v1beta1/httproute_types.go b/apis/v1beta1/httproute_types.go
index fb6809dd..665758a7 100644
--- a/apis/v1beta1/httproute_types.go
+++ b/apis/v1beta1/httproute_types.go
@@ -1134,12 +1134,17 @@ type HTTPBackendRef struct {
 	//   case, the Reason must be set to `RefNotPermitted` and the Message of the
 	//   Condition must explain which cross-namespace reference is not allowed.
 	//
+	// * It refers to a Kubernetes Service that has an incompatible appProtocol
+	//   for the given Route type
+	//
 	// Support: Core for Kubernetes Service
 	//
 	// Support: Implementation-specific for any other resource
 	//
 	// Support for weight: Core
 	//
+	// Support for Kubernetes Service appProtocol: Extended
+	//
 	// +optional
 	BackendRef `json:",inline"`
 
diff --git a/apis/v1beta1/object_reference_types.go b/apis/v1beta1/object_reference_types.go
index 4ef1c378..8ef008db 100644
--- a/apis/v1beta1/object_reference_types.go
+++ b/apis/v1beta1/object_reference_types.go
@@ -62,7 +62,7 @@ type SecretObjectReference struct {
 	// Name is the name of the referent.
 	Name ObjectName `json:"name"`
 
-	// Namespace is the namespace of the backend. When unspecified, the local
+	// Namespace is the namespace of the referenced object. When unspecified, the local
 	// namespace is inferred.
 	//
 	// Note that when a namespace different than the local namespace is specified,
diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go
index b879d3a1..369328b5 100644
--- a/apis/v1beta1/shared_types.go
+++ b/apis/v1beta1/shared_types.go
@@ -66,6 +66,7 @@ type ParentReference struct {
 	// Gateway has the AllowedRoutes field, and ReferenceGrant provides a
 	// generic way to enable any other kind of cross-namespace reference.
 	//
+	// <gateway:experimental:description>
 	// ParentRefs from a Route to a Service in the same namespace are "producer"
 	// routes, which apply default routing rules to inbound connections from
 	// any namespace to the Service.
@@ -75,6 +76,7 @@ type ParentReference struct {
 	// connections originating from the same namespace as the Route, for which
 	// the intended destination of the connections are a Service targeted as a
 	// ParentRef of the Route.
+	// </gateway:experimental:description>
 	//
 	// Support: Core
 	//
@@ -127,9 +129,11 @@ type ParentReference struct {
 	// and SectionName are specified, the name and port of the selected listener
 	// must match both specified values.
 	//
+	// <gateway:experimental:description>
 	// When the parent resource is a Service, this targets a specific port in the
 	// Service spec. When both Port (experimental) and SectionName are specified,
 	// the name and port of the selected port must match both specified values.
+	// </gateway:experimental:description>
 	//
 	// Implementations MAY choose to support other parent resources.
 	// Implementations supporting other types of parent resources MUST clearly
@@ -167,8 +171,9 @@ type CommonRouteSpec struct {
 	// There are two kinds of parent resources with "Core" support:
 	//
 	// * Gateway (Gateway conformance profile)
+	// <gateway:experimental:description>
 	// * Service (Mesh conformance profile, experimental, ClusterIP Services only)
-	//
+	// </gateway:experimental:description>
 	// This API may be extended in the future to support additional kinds of parent
 	// resources.
 	//
@@ -189,6 +194,7 @@ type CommonRouteSpec struct {
 	// Gateway has the AllowedRoutes field, and ReferenceGrant provides a
 	// generic way to enable other kinds of cross-namespace reference.
 	//
+	// <gateway:experimental:description>
 	// ParentRefs from a Route to a Service in the same namespace are "producer"
 	// routes, which apply default routing rules to inbound connections from
 	// any namespace to the Service.
@@ -198,6 +204,7 @@ type CommonRouteSpec struct {
 	// connections originating from the same namespace as the Route, for which
 	// the intended destination of the connections are a Service targeted as a
 	// ParentRef of the Route.
+	// </gateway:experimental:description>
 	//
 	// +optional
 	// +kubebuilder:validation:MaxItems=32
diff --git a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml
index 42bd3bbc..0cdd5616 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml
@@ -140,28 +140,43 @@ spec:
                   the TLS Conformance Profile, the below combinations of port and
                   protocol are considered Core and MUST be supported: \n 1. Port:
                   443, Protocol: TLS \n Port and protocol combinations not listed
-                  above are considered Extended. \n An implementation MAY group Listeners
-                  by Port and then collapse each group of Listeners into a single
-                  Listener if the implementation determines that the Listeners in
-                  the group are \"compatible\". An implementation MAY also group together
-                  and collapse compatible Listeners belonging to different Gateways.
-                  \n For example, an implementation might consider Listeners to be
-                  compatible with each other if all of the following conditions are
-                  met: \n 1. Either each Listener within the group specifies the \"HTTP\"
-                  Protocol or each Listener within the group specifies either the
-                  \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener within the group
-                  specifies a Hostname that is unique within the group. \n 3. As a
-                  special case, one Listener within a group may omit Hostname, in
-                  which case this Listener matches when no other Listener matches.
-                  \n If the implementation does collapse compatible Listeners, the
-                  hostname provided in the incoming client request MUST be matched
-                  to a Listener to find the correct set of Routes. The incoming hostname
-                  MUST be matched using the Hostname field for each Listener in order
-                  of most to least specific. That is, exact matches must be processed
-                  before wildcard matches. \n If this field specifies multiple Listeners
-                  that have the same Port value but are not compatible, the implementation
-                  must raise a \"Conflicted\" condition in the Listener status. \n
-                  Support: Core"
+                  above are considered Extended. \n A Gateway's Listeners are considered
+                  \"compatible\" if: \n 1. The implementation can serve them in compliance
+                  with the Addresses requirement that all Listeners are available
+                  on all assigned addresses. 2. The implementation can match inbound
+                  requests to a single distinct Listener. When multiple Listeners
+                  share values for fields (for example, two Listeners with the same
+                  Port value), the implementation can can match requests to only one
+                  of the Listeners using other Listener fields. \n Compatible combinations
+                  in Extended support are expected to vary across implementations.
+                  A combination that is compatible for one implementation may not
+                  be compatible for another. \n If this field specifies multiple Listeners
+                  that are not compatible, the implementation MUST set the \"Conflicted\"
+                  condition in the Listener Status to \"True\". \n Implementations
+                  MAY choose to still accept a Gateway with conflicted Listeners if
+                  they accept a partial Listener set that contains no incompatible
+                  Listeners. They MUST set a \"ListenersNotValid\" condition the Gateway
+                  Status when the Gateway contains incompatible Listeners whether
+                  or not they accept the Gateway. \n For example, the following Listener
+                  scenarios may be compatible depending on implementation capabilities:
+                  \n 1. Multiple Listeners with the same Port that all use the \"HTTP\"
+                  Protocol that all have unique Hostname values. 2. Multiple Listeners
+                  with the same Port that use either the \"HTTPS\" or \"TLS\" Protocol
+                  that all have unique Hostname values. 3. A mixture of \"TCP\" and
+                  \"UDP\" Protocol Listeners, where no Listener with the same Protocol
+                  has the same Port value. \n An implementation that cannot serve
+                  both TCP and UDP listeners on the same address, or cannot mix HTTPS
+                  and generic TLS listens on the same port would not consider those
+                  cases compatible. \n Implementations using the Hostname value to
+                  select between same-Port Listeners MUST match inbound request hostnames
+                  from the most specific to least specific Hostname values to find
+                  the correct set of Routes. Exact matches must be processed before
+                  wildcard matches, and wildcard matches must be processed before
+                  fallback (empty Hostname value) matches. For example, `\"foo.example.com\"`
+                  takes precedence over `\"*.example.com\"`, and `\"*.example.com\"`
+                  takes precedence over `\"\"`. \n Implementations MAY merge separate
+                  Gateways onto a single set of Addresses if all Listeners across
+                  all Gateways are compatible. \n Support: Core"
                 items:
                   description: Listener embodies the concept of a logical endpoint
                     where a Gateway accepts network connections.
@@ -410,14 +425,14 @@ spec:
                                 minLength: 1
                                 type: string
                               namespace:
-                                description: "Namespace is the namespace of the backend.
-                                  When unspecified, the local namespace is inferred.
-                                  \n Note that when a namespace different than the
-                                  local namespace is specified, a ReferenceGrant object
-                                  is required in the referent namespace to allow that
-                                  namespace's owner to accept the reference. See the
-                                  ReferenceGrant documentation for details. \n Support:
-                                  Core"
+                                description: "Namespace is the namespace of the referenced
+                                  object. When unspecified, the local namespace is
+                                  inferred. \n Note that when a namespace different
+                                  than the local namespace is specified, a ReferenceGrant
+                                  object is required in the referent namespace to
+                                  allow that namespace's owner to accept the reference.
+                                  See the ReferenceGrant documentation for details.
+                                  \n Support: Core"
                                 maxLength: 63
                                 minLength: 1
                                 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -933,28 +948,43 @@ spec:
                   the TLS Conformance Profile, the below combinations of port and
                   protocol are considered Core and MUST be supported: \n 1. Port:
                   443, Protocol: TLS \n Port and protocol combinations not listed
-                  above are considered Extended. \n An implementation MAY group Listeners
-                  by Port and then collapse each group of Listeners into a single
-                  Listener if the implementation determines that the Listeners in
-                  the group are \"compatible\". An implementation MAY also group together
-                  and collapse compatible Listeners belonging to different Gateways.
-                  \n For example, an implementation might consider Listeners to be
-                  compatible with each other if all of the following conditions are
-                  met: \n 1. Either each Listener within the group specifies the \"HTTP\"
-                  Protocol or each Listener within the group specifies either the
-                  \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener within the group
-                  specifies a Hostname that is unique within the group. \n 3. As a
-                  special case, one Listener within a group may omit Hostname, in
-                  which case this Listener matches when no other Listener matches.
-                  \n If the implementation does collapse compatible Listeners, the
-                  hostname provided in the incoming client request MUST be matched
-                  to a Listener to find the correct set of Routes. The incoming hostname
-                  MUST be matched using the Hostname field for each Listener in order
-                  of most to least specific. That is, exact matches must be processed
-                  before wildcard matches. \n If this field specifies multiple Listeners
-                  that have the same Port value but are not compatible, the implementation
-                  must raise a \"Conflicted\" condition in the Listener status. \n
-                  Support: Core"
+                  above are considered Extended. \n A Gateway's Listeners are considered
+                  \"compatible\" if: \n 1. The implementation can serve them in compliance
+                  with the Addresses requirement that all Listeners are available
+                  on all assigned addresses. 2. The implementation can match inbound
+                  requests to a single distinct Listener. When multiple Listeners
+                  share values for fields (for example, two Listeners with the same
+                  Port value), the implementation can can match requests to only one
+                  of the Listeners using other Listener fields. \n Compatible combinations
+                  in Extended support are expected to vary across implementations.
+                  A combination that is compatible for one implementation may not
+                  be compatible for another. \n If this field specifies multiple Listeners
+                  that are not compatible, the implementation MUST set the \"Conflicted\"
+                  condition in the Listener Status to \"True\". \n Implementations
+                  MAY choose to still accept a Gateway with conflicted Listeners if
+                  they accept a partial Listener set that contains no incompatible
+                  Listeners. They MUST set a \"ListenersNotValid\" condition the Gateway
+                  Status when the Gateway contains incompatible Listeners whether
+                  or not they accept the Gateway. \n For example, the following Listener
+                  scenarios may be compatible depending on implementation capabilities:
+                  \n 1. Multiple Listeners with the same Port that all use the \"HTTP\"
+                  Protocol that all have unique Hostname values. 2. Multiple Listeners
+                  with the same Port that use either the \"HTTPS\" or \"TLS\" Protocol
+                  that all have unique Hostname values. 3. A mixture of \"TCP\" and
+                  \"UDP\" Protocol Listeners, where no Listener with the same Protocol
+                  has the same Port value. \n An implementation that cannot serve
+                  both TCP and UDP listeners on the same address, or cannot mix HTTPS
+                  and generic TLS listens on the same port would not consider those
+                  cases compatible. \n Implementations using the Hostname value to
+                  select between same-Port Listeners MUST match inbound request hostnames
+                  from the most specific to least specific Hostname values to find
+                  the correct set of Routes. Exact matches must be processed before
+                  wildcard matches, and wildcard matches must be processed before
+                  fallback (empty Hostname value) matches. For example, `\"foo.example.com\"`
+                  takes precedence over `\"*.example.com\"`, and `\"*.example.com\"`
+                  takes precedence over `\"\"`. \n Implementations MAY merge separate
+                  Gateways onto a single set of Addresses if all Listeners across
+                  all Gateways are compatible. \n Support: Core"
                 items:
                   description: Listener embodies the concept of a logical endpoint
                     where a Gateway accepts network connections.
@@ -1203,14 +1233,14 @@ spec:
                                 minLength: 1
                                 type: string
                               namespace:
-                                description: "Namespace is the namespace of the backend.
-                                  When unspecified, the local namespace is inferred.
-                                  \n Note that when a namespace different than the
-                                  local namespace is specified, a ReferenceGrant object
-                                  is required in the referent namespace to allow that
-                                  namespace's owner to accept the reference. See the
-                                  ReferenceGrant documentation for details. \n Support:
-                                  Core"
+                                description: "Namespace is the namespace of the referenced
+                                  object. When unspecified, the local namespace is
+                                  inferred. \n Note that when a namespace different
+                                  than the local namespace is specified, a ReferenceGrant
+                                  object is required in the referent namespace to
+                                  allow that namespace's owner to accept the reference.
+                                  See the ReferenceGrant documentation for details.
+                                  \n Support: Core"
                                 maxLength: 63
                                 minLength: 1
                                 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml
index 0137c127..911c3758 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml
@@ -134,8 +134,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -150,14 +150,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -205,7 +205,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -213,7 +213,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -228,11 +228,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -1601,7 +1601,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -1609,7 +1609,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -1626,11 +1626,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml
index 285e6acb..32b38440 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml
@@ -121,8 +121,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -137,14 +137,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -192,7 +192,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -200,7 +200,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -215,11 +215,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -2368,7 +2368,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -2376,7 +2376,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -2393,11 +2393,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
@@ -2562,8 +2562,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -2578,14 +2578,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -2633,7 +2633,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -2641,7 +2641,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -2656,11 +2656,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -4809,7 +4809,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -4817,7 +4817,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -4834,11 +4834,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml
index fb0b930c..7bdce82e 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml
@@ -56,8 +56,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -72,14 +72,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -127,7 +127,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -135,7 +135,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -150,11 +150,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -510,7 +510,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -518,7 +518,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -535,11 +535,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml
index fffeebd8..5d139640 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml
@@ -102,8 +102,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -118,14 +118,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -173,7 +173,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -181,7 +181,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -196,11 +196,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -559,7 +559,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -567,7 +567,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -584,11 +584,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml
index f6ac6388..9cab8036 100644
--- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml
+++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml
@@ -56,8 +56,8 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
+                  support: \n * Gateway (Gateway conformance profile)  * Service (Mesh
+                  conformance profile, experimental, ClusterIP Services only)  This
                   API may be extended in the future to support additional kinds of
                   parent resources. \n It is invalid to reference an identical parent
                   more than once. It is valid to reference multiple distinct sections
@@ -72,14 +72,14 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
+                  kinds of cross-namespace reference. \n  ParentRefs from a Route
+                  to a Service in the same namespace are \"producer\" routes, which
+                  apply default routing rules to inbound connections from any namespace
                   to the Service. \n ParentRefs from a Route to a Service in a different
                   namespace are \"consumer\" routes, and these routing rules are only
                   applied to outbound connections originating from the same namespace
                   as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  are a Service targeted as a ParentRef of the Route.  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -127,7 +127,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
+                        \n  ParentRefs from a Route to a Service in the same namespace
                         are \"producer\" routes, which apply default routing rules
                         to inbound connections from any namespace to the Service.
                         \n ParentRefs from a Route to a Service in a different namespace
@@ -135,7 +135,7 @@ spec:
                         applied to outbound connections originating from the same
                         namespace as the Route, for which the intended destination
                         of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        the Route.  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -150,11 +150,11 @@ spec:
                         a Route must apply to a specific port as opposed to a listener(s)
                         whose port(s) may be changed. When both Port and SectionName
                         are specified, the name and port of the selected listener
-                        must match both specified values. \n When the parent resource
+                        must match both specified values. \n  When the parent resource
                         is a Service, this targets a specific port in the Service
                         spec. When both Port (experimental) and SectionName are specified,
                         the name and port of the selected port must match both specified
-                        values. \n Implementations MAY choose to support other parent
+                        values.  \n Implementations MAY choose to support other parent
                         resources. Implementations supporting other types of parent
                         resources MUST clearly document how/if Port is interpreted.
                         \n For the purpose of status, an attachment is considered
@@ -510,7 +510,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
+                            reference. \n  ParentRefs from a Route to a Service in
                             the same namespace are \"producer\" routes, which apply
                             default routing rules to inbound connections from any
                             namespace to the Service. \n ParentRefs from a Route to
@@ -518,7 +518,7 @@ spec:
                             and these routing rules are only applied to outbound connections
                             originating from the same namespace as the Route, for
                             which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
+                            a Service targeted as a ParentRef of the Route.  \n Support:
                             Core"
                           maxLength: 63
                           minLength: 1
@@ -535,11 +535,11 @@ spec:
                             a specific port as opposed to a listener(s) whose port(s)
                             may be changed. When both Port and SectionName are specified,
                             the name and port of the selected listener must match
-                            both specified values. \n When the parent resource is
+                            both specified values. \n  When the parent resource is
                             a Service, this targets a specific port in the Service
                             spec. When both Port (experimental) and SectionName are
                             specified, the name and port of the selected port must
-                            match both specified values. \n Implementations MAY choose
+                            match both specified values.  \n Implementations MAY choose
                             to support other parent resources. Implementations supporting
                             other types of parent resources MUST clearly document
                             how/if Port is interpreted. \n For the purpose of status,
diff --git a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
index d7411cc7..de241d1d 100644
--- a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
+++ b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
@@ -140,28 +140,43 @@ spec:
                   the TLS Conformance Profile, the below combinations of port and
                   protocol are considered Core and MUST be supported: \n 1. Port:
                   443, Protocol: TLS \n Port and protocol combinations not listed
-                  above are considered Extended. \n An implementation MAY group Listeners
-                  by Port and then collapse each group of Listeners into a single
-                  Listener if the implementation determines that the Listeners in
-                  the group are \"compatible\". An implementation MAY also group together
-                  and collapse compatible Listeners belonging to different Gateways.
-                  \n For example, an implementation might consider Listeners to be
-                  compatible with each other if all of the following conditions are
-                  met: \n 1. Either each Listener within the group specifies the \"HTTP\"
-                  Protocol or each Listener within the group specifies either the
-                  \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener within the group
-                  specifies a Hostname that is unique within the group. \n 3. As a
-                  special case, one Listener within a group may omit Hostname, in
-                  which case this Listener matches when no other Listener matches.
-                  \n If the implementation does collapse compatible Listeners, the
-                  hostname provided in the incoming client request MUST be matched
-                  to a Listener to find the correct set of Routes. The incoming hostname
-                  MUST be matched using the Hostname field for each Listener in order
-                  of most to least specific. That is, exact matches must be processed
-                  before wildcard matches. \n If this field specifies multiple Listeners
-                  that have the same Port value but are not compatible, the implementation
-                  must raise a \"Conflicted\" condition in the Listener status. \n
-                  Support: Core"
+                  above are considered Extended. \n A Gateway's Listeners are considered
+                  \"compatible\" if: \n 1. The implementation can serve them in compliance
+                  with the Addresses requirement that all Listeners are available
+                  on all assigned addresses. 2. The implementation can match inbound
+                  requests to a single distinct Listener. When multiple Listeners
+                  share values for fields (for example, two Listeners with the same
+                  Port value), the implementation can can match requests to only one
+                  of the Listeners using other Listener fields. \n Compatible combinations
+                  in Extended support are expected to vary across implementations.
+                  A combination that is compatible for one implementation may not
+                  be compatible for another. \n If this field specifies multiple Listeners
+                  that are not compatible, the implementation MUST set the \"Conflicted\"
+                  condition in the Listener Status to \"True\". \n Implementations
+                  MAY choose to still accept a Gateway with conflicted Listeners if
+                  they accept a partial Listener set that contains no incompatible
+                  Listeners. They MUST set a \"ListenersNotValid\" condition the Gateway
+                  Status when the Gateway contains incompatible Listeners whether
+                  or not they accept the Gateway. \n For example, the following Listener
+                  scenarios may be compatible depending on implementation capabilities:
+                  \n 1. Multiple Listeners with the same Port that all use the \"HTTP\"
+                  Protocol that all have unique Hostname values. 2. Multiple Listeners
+                  with the same Port that use either the \"HTTPS\" or \"TLS\" Protocol
+                  that all have unique Hostname values. 3. A mixture of \"TCP\" and
+                  \"UDP\" Protocol Listeners, where no Listener with the same Protocol
+                  has the same Port value. \n An implementation that cannot serve
+                  both TCP and UDP listeners on the same address, or cannot mix HTTPS
+                  and generic TLS listens on the same port would not consider those
+                  cases compatible. \n Implementations using the Hostname value to
+                  select between same-Port Listeners MUST match inbound request hostnames
+                  from the most specific to least specific Hostname values to find
+                  the correct set of Routes. Exact matches must be processed before
+                  wildcard matches, and wildcard matches must be processed before
+                  fallback (empty Hostname value) matches. For example, `\"foo.example.com\"`
+                  takes precedence over `\"*.example.com\"`, and `\"*.example.com\"`
+                  takes precedence over `\"\"`. \n Implementations MAY merge separate
+                  Gateways onto a single set of Addresses if all Listeners across
+                  all Gateways are compatible. \n Support: Core"
                 items:
                   description: Listener embodies the concept of a logical endpoint
                     where a Gateway accepts network connections.
@@ -410,14 +425,14 @@ spec:
                                 minLength: 1
                                 type: string
                               namespace:
-                                description: "Namespace is the namespace of the backend.
-                                  When unspecified, the local namespace is inferred.
-                                  \n Note that when a namespace different than the
-                                  local namespace is specified, a ReferenceGrant object
-                                  is required in the referent namespace to allow that
-                                  namespace's owner to accept the reference. See the
-                                  ReferenceGrant documentation for details. \n Support:
-                                  Core"
+                                description: "Namespace is the namespace of the referenced
+                                  object. When unspecified, the local namespace is
+                                  inferred. \n Note that when a namespace different
+                                  than the local namespace is specified, a ReferenceGrant
+                                  object is required in the referent namespace to
+                                  allow that namespace's owner to accept the reference.
+                                  See the ReferenceGrant documentation for details.
+                                  \n Support: Core"
                                 maxLength: 63
                                 minLength: 1
                                 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -933,28 +948,43 @@ spec:
                   the TLS Conformance Profile, the below combinations of port and
                   protocol are considered Core and MUST be supported: \n 1. Port:
                   443, Protocol: TLS \n Port and protocol combinations not listed
-                  above are considered Extended. \n An implementation MAY group Listeners
-                  by Port and then collapse each group of Listeners into a single
-                  Listener if the implementation determines that the Listeners in
-                  the group are \"compatible\". An implementation MAY also group together
-                  and collapse compatible Listeners belonging to different Gateways.
-                  \n For example, an implementation might consider Listeners to be
-                  compatible with each other if all of the following conditions are
-                  met: \n 1. Either each Listener within the group specifies the \"HTTP\"
-                  Protocol or each Listener within the group specifies either the
-                  \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener within the group
-                  specifies a Hostname that is unique within the group. \n 3. As a
-                  special case, one Listener within a group may omit Hostname, in
-                  which case this Listener matches when no other Listener matches.
-                  \n If the implementation does collapse compatible Listeners, the
-                  hostname provided in the incoming client request MUST be matched
-                  to a Listener to find the correct set of Routes. The incoming hostname
-                  MUST be matched using the Hostname field for each Listener in order
-                  of most to least specific. That is, exact matches must be processed
-                  before wildcard matches. \n If this field specifies multiple Listeners
-                  that have the same Port value but are not compatible, the implementation
-                  must raise a \"Conflicted\" condition in the Listener status. \n
-                  Support: Core"
+                  above are considered Extended. \n A Gateway's Listeners are considered
+                  \"compatible\" if: \n 1. The implementation can serve them in compliance
+                  with the Addresses requirement that all Listeners are available
+                  on all assigned addresses. 2. The implementation can match inbound
+                  requests to a single distinct Listener. When multiple Listeners
+                  share values for fields (for example, two Listeners with the same
+                  Port value), the implementation can can match requests to only one
+                  of the Listeners using other Listener fields. \n Compatible combinations
+                  in Extended support are expected to vary across implementations.
+                  A combination that is compatible for one implementation may not
+                  be compatible for another. \n If this field specifies multiple Listeners
+                  that are not compatible, the implementation MUST set the \"Conflicted\"
+                  condition in the Listener Status to \"True\". \n Implementations
+                  MAY choose to still accept a Gateway with conflicted Listeners if
+                  they accept a partial Listener set that contains no incompatible
+                  Listeners. They MUST set a \"ListenersNotValid\" condition the Gateway
+                  Status when the Gateway contains incompatible Listeners whether
+                  or not they accept the Gateway. \n For example, the following Listener
+                  scenarios may be compatible depending on implementation capabilities:
+                  \n 1. Multiple Listeners with the same Port that all use the \"HTTP\"
+                  Protocol that all have unique Hostname values. 2. Multiple Listeners
+                  with the same Port that use either the \"HTTPS\" or \"TLS\" Protocol
+                  that all have unique Hostname values. 3. A mixture of \"TCP\" and
+                  \"UDP\" Protocol Listeners, where no Listener with the same Protocol
+                  has the same Port value. \n An implementation that cannot serve
+                  both TCP and UDP listeners on the same address, or cannot mix HTTPS
+                  and generic TLS listens on the same port would not consider those
+                  cases compatible. \n Implementations using the Hostname value to
+                  select between same-Port Listeners MUST match inbound request hostnames
+                  from the most specific to least specific Hostname values to find
+                  the correct set of Routes. Exact matches must be processed before
+                  wildcard matches, and wildcard matches must be processed before
+                  fallback (empty Hostname value) matches. For example, `\"foo.example.com\"`
+                  takes precedence over `\"*.example.com\"`, and `\"*.example.com\"`
+                  takes precedence over `\"\"`. \n Implementations MAY merge separate
+                  Gateways onto a single set of Addresses if all Listeners across
+                  all Gateways are compatible. \n Support: Core"
                 items:
                   description: Listener embodies the concept of a logical endpoint
                     where a Gateway accepts network connections.
@@ -1203,14 +1233,14 @@ spec:
                                 minLength: 1
                                 type: string
                               namespace:
-                                description: "Namespace is the namespace of the backend.
-                                  When unspecified, the local namespace is inferred.
-                                  \n Note that when a namespace different than the
-                                  local namespace is specified, a ReferenceGrant object
-                                  is required in the referent namespace to allow that
-                                  namespace's owner to accept the reference. See the
-                                  ReferenceGrant documentation for details. \n Support:
-                                  Core"
+                                description: "Namespace is the namespace of the referenced
+                                  object. When unspecified, the local namespace is
+                                  inferred. \n Note that when a namespace different
+                                  than the local namespace is specified, a ReferenceGrant
+                                  object is required in the referent namespace to
+                                  allow that namespace's owner to accept the reference.
+                                  See the ReferenceGrant documentation for details.
+                                  \n Support: Core"
                                 maxLength: 63
                                 minLength: 1
                                 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
index eaf33f3c..a8aa849e 100644
--- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
+++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
@@ -121,15 +121,14 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
-                  API may be extended in the future to support additional kinds of
-                  parent resources. \n It is invalid to reference an identical parent
-                  more than once. It is valid to reference multiple distinct sections
-                  within the same parent resource, such as two separate Listeners
-                  on the same Gateway or two separate ports on the same Service. \n
-                  It is possible to separately reference multiple distinct objects
-                  that may be collapsed by an implementation. For example, some implementations
+                  support: \n * Gateway (Gateway conformance profile)  This API may
+                  be extended in the future to support additional kinds of parent
+                  resources. \n It is invalid to reference an identical parent more
+                  than once. It is valid to reference multiple distinct sections within
+                  the same parent resource, such as two separate Listeners on the
+                  same Gateway or two separate ports on the same Service. \n It is
+                  possible to separately reference multiple distinct objects that
+                  may be collapsed by an implementation. For example, some implementations
                   may choose to merge compatible Gateway Listeners together. If that
                   is the case, the list of routes attached to those resources should
                   also be merged. \n Note that for ParentRefs that cross namespace
@@ -137,14 +136,7 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
-                  to the Service. \n ParentRefs from a Route to a Service in a different
-                  namespace are \"consumer\" routes, and these routing rules are only
-                  applied to outbound connections originating from the same namespace
-                  as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  kinds of cross-namespace reference. \n  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -192,15 +184,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
-                        are \"producer\" routes, which apply default routing rules
-                        to inbound connections from any namespace to the Service.
-                        \n ParentRefs from a Route to a Service in a different namespace
-                        are \"consumer\" routes, and these routing rules are only
-                        applied to outbound connections originating from the same
-                        namespace as the Route, for which the intended destination
-                        of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        \n  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -2291,16 +2275,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
-                            the same namespace are \"producer\" routes, which apply
-                            default routing rules to inbound connections from any
-                            namespace to the Service. \n ParentRefs from a Route to
-                            a Service in a different namespace are \"consumer\" routes,
-                            and these routing rules are only applied to outbound connections
-                            originating from the same namespace as the Route, for
-                            which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
-                            Core"
+                            reference. \n  \n Support: Core"
                           maxLength: 63
                           minLength: 1
                           pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -2453,15 +2428,14 @@ spec:
                   for governing ParentRefs to Services - it is not possible to create
                   a \"producer\" route for a Service in a different namespace from
                   the Route. \n There are two kinds of parent resources with \"Core\"
-                  support: \n * Gateway (Gateway conformance profile) * Service (Mesh
-                  conformance profile, experimental, ClusterIP Services only) \n This
-                  API may be extended in the future to support additional kinds of
-                  parent resources. \n It is invalid to reference an identical parent
-                  more than once. It is valid to reference multiple distinct sections
-                  within the same parent resource, such as two separate Listeners
-                  on the same Gateway or two separate ports on the same Service. \n
-                  It is possible to separately reference multiple distinct objects
-                  that may be collapsed by an implementation. For example, some implementations
+                  support: \n * Gateway (Gateway conformance profile)  This API may
+                  be extended in the future to support additional kinds of parent
+                  resources. \n It is invalid to reference an identical parent more
+                  than once. It is valid to reference multiple distinct sections within
+                  the same parent resource, such as two separate Listeners on the
+                  same Gateway or two separate ports on the same Service. \n It is
+                  possible to separately reference multiple distinct objects that
+                  may be collapsed by an implementation. For example, some implementations
                   may choose to merge compatible Gateway Listeners together. If that
                   is the case, the list of routes attached to those resources should
                   also be merged. \n Note that for ParentRefs that cross namespace
@@ -2469,14 +2443,7 @@ spec:
                   are only valid if they are explicitly allowed by something in the
                   namespace they are referring to. For example, Gateway has the AllowedRoutes
                   field, and ReferenceGrant provides a generic way to enable other
-                  kinds of cross-namespace reference. \n ParentRefs from a Route to
-                  a Service in the same namespace are \"producer\" routes, which apply
-                  default routing rules to inbound connections from any namespace
-                  to the Service. \n ParentRefs from a Route to a Service in a different
-                  namespace are \"consumer\" routes, and these routing rules are only
-                  applied to outbound connections originating from the same namespace
-                  as the Route, for which the intended destination of the connections
-                  are a Service targeted as a ParentRef of the Route. \n "
+                  kinds of cross-namespace reference. \n  \n "
                 items:
                   description: "ParentReference identifies an API object (usually
                     a Gateway) that can be considered a parent of this resource (usually
@@ -2524,15 +2491,7 @@ spec:
                         the namespace they are referring to. For example: Gateway
                         has the AllowedRoutes field, and ReferenceGrant provides a
                         generic way to enable any other kind of cross-namespace reference.
-                        \n ParentRefs from a Route to a Service in the same namespace
-                        are \"producer\" routes, which apply default routing rules
-                        to inbound connections from any namespace to the Service.
-                        \n ParentRefs from a Route to a Service in a different namespace
-                        are \"consumer\" routes, and these routing rules are only
-                        applied to outbound connections originating from the same
-                        namespace as the Route, for which the intended destination
-                        of the connections are a Service targeted as a ParentRef of
-                        the Route. \n Support: Core"
+                        \n  \n Support: Core"
                       maxLength: 63
                       minLength: 1
                       pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
@@ -4623,16 +4582,7 @@ spec:
                             in the namespace they are referring to. For example: Gateway
                             has the AllowedRoutes field, and ReferenceGrant provides
                             a generic way to enable any other kind of cross-namespace
-                            reference. \n ParentRefs from a Route to a Service in
-                            the same namespace are \"producer\" routes, which apply
-                            default routing rules to inbound connections from any
-                            namespace to the Service. \n ParentRefs from a Route to
-                            a Service in a different namespace are \"consumer\" routes,
-                            and these routing rules are only applied to outbound connections
-                            originating from the same namespace as the Route, for
-                            which the intended destination of the connections are
-                            a Service targeted as a ParentRef of the Route. \n Support:
-                            Core"
+                            reference. \n  \n Support: Core"
                           maxLength: 63
                           minLength: 1
                           pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
diff --git a/conformance/reports/v0.7.1/nginxinc-nginx-kubernetes-gateway.yaml b/conformance/reports/v0.7.1/nginxinc-nginx-gateway-fabric.yaml
similarity index 83%
rename from conformance/reports/v0.7.1/nginxinc-nginx-kubernetes-gateway.yaml
rename to conformance/reports/v0.7.1/nginxinc-nginx-gateway-fabric.yaml
index 7693ef8c..f5155a1c 100644
--- a/conformance/reports/v0.7.1/nginxinc-nginx-kubernetes-gateway.yaml
+++ b/conformance/reports/v0.7.1/nginxinc-nginx-gateway-fabric.yaml
@@ -3,10 +3,10 @@ date: "2023-07-25T20:48:53Z"
 gatewayAPIVersion: v0.7.1
 implementation:
   contact:
-  - https://github.com/nginxinc/nginx-kubernetes-gateway/discussions/new/choose
+  - https://github.com/nginxinc/nginx-gateway-fabric/discussions/new/choose
   organization: nginxinc
-  project: nginx-kubernetes-gateway
-  url: github.com/nginxinc/nginx-kubernetes-gateway
+  project: nginx-gateway-fabric
+  url: github.com/nginxinc/nginx-gateway-fabric
   version: "v0.5.0"
 kind: ConformanceReport
 profiles:
diff --git a/conformance/reports/v0.8.0/nginxinc-nginx-kubernetes-gateway.yaml b/conformance/reports/v0.8.0/nginxinc-nginx-gateway-fabric.yaml
similarity index 81%
rename from conformance/reports/v0.8.0/nginxinc-nginx-kubernetes-gateway.yaml
rename to conformance/reports/v0.8.0/nginxinc-nginx-gateway-fabric.yaml
index a90847c1..6dd6d045 100644
--- a/conformance/reports/v0.8.0/nginxinc-nginx-kubernetes-gateway.yaml
+++ b/conformance/reports/v0.8.0/nginxinc-nginx-gateway-fabric.yaml
@@ -3,10 +3,10 @@ date: "2023-08-31T16:40:14Z"
 gatewayAPIVersion: v0.8.0
 implementation:
   contact:
-  - https://github.com/nginxinc/nginx-kubernetes-gateway/discussions/new/choose
+  - https://github.com/nginxinc/nginx-gateway-fabric/discussions/new/choose
   organization: nginxinc
-  project: nginx-kubernetes-gateway
-  url: https://github.com/nginxinc/nginx-kubernetes-gateway
+  project: nginx-gateway-fabric
+  url: https://github.com/nginxinc/nginx-gateway-fabric
   version: v0.6.0
 kind: ConformanceReport
 profiles:
diff --git a/conformance/reports/v0.8.1/kong-kubernetes-ingress-controller.yaml b/conformance/reports/v0.8.1/kong-kubernetes-ingress-controller.yaml
new file mode 100644
index 00000000..f037fda0
--- /dev/null
+++ b/conformance/reports/v0.8.1/kong-kubernetes-ingress-controller.yaml
@@ -0,0 +1,39 @@
+apiVersion: gateway.networking.k8s.io/v1alpha1
+date: "2023-09-25T14:43:27Z"
+gatewayAPIVersion: v0.8.1
+implementation:
+  contact:
+  - github.com/kong/kubernetes-ingress-controller/issues/new/choose
+  organization: Kong
+  project: kubernetes-ingress-controller
+  url: github.com/kong/kubernetes-ingress-controller
+  version: v2.12.0
+kind: ConformanceReport
+profiles:
+- core:
+    result: success
+    statistics:
+      Failed: 0
+      Passed: 29
+      Skipped: 0
+    summary: ""
+  extended:
+    result: success
+    statistics:
+      Failed: 0
+      Passed: 2
+      Skipped: 0
+    summary: ""
+    supportedFeatures:
+    - HTTPResponseHeaderModification
+    - HTTPRouteMethodMatching
+    unsupportedFeatures:
+    - HTTPRouteSchemeRedirect
+    - HTTPRoutePathRedirect
+    - HTTPRouteHostRewrite
+    - HTTPRoutePathRewrite
+    - HTTPRouteRequestMirror
+    - HTTPRouteRequestMultipleMirrors
+    - HTTPRouteQueryParamMatching
+    - HTTPRoutePortRedirect
+  name: HTTP
diff --git a/conformance/utils/config/timeout.go b/conformance/utils/config/timeout.go
index dbaf2bec..43900635 100644
--- a/conformance/utils/config/timeout.go
+++ b/conformance/utils/config/timeout.go
@@ -39,6 +39,10 @@ type TimeoutConfig struct {
 	// Max value for conformant implementation: None
 	GatewayStatusMustHaveListeners time.Duration
 
+	// GatewayListenersMustHaveCondition represents the maximum time for a Gateway to have all listeners with a specific condition.
+	// Max value for conformant implementation: None
+	GatewayListenersMustHaveCondition time.Duration
+
 	// GWCMustBeAccepted represents the maximum time for a GatewayClass to have an Accepted condition set to true.
 	// Max value for conformant implementation: None
 	GWCMustBeAccepted time.Duration
@@ -91,22 +95,23 @@ type TimeoutConfig struct {
 // DefaultTimeoutConfig populates a TimeoutConfig with the default values.
 func DefaultTimeoutConfig() TimeoutConfig {
 	return TimeoutConfig{
-		CreateTimeout:                  60 * time.Second,
-		DeleteTimeout:                  10 * time.Second,
-		GetTimeout:                     10 * time.Second,
-		GatewayMustHaveAddress:         180 * time.Second,
-		GatewayStatusMustHaveListeners: 60 * time.Second,
-		GWCMustBeAccepted:              180 * time.Second,
-		HTTPRouteMustNotHaveParents:    60 * time.Second,
-		HTTPRouteMustHaveCondition:     60 * time.Second,
-		TLSRouteMustHaveCondition:      60 * time.Second,
-		RouteMustHaveParents:           60 * time.Second,
-		ManifestFetchTimeout:           10 * time.Second,
-		MaxTimeToConsistency:           30 * time.Second,
-		NamespacesMustBeReady:          300 * time.Second,
-		RequestTimeout:                 10 * time.Second,
-		LatestObservedGenerationSet:    60 * time.Second,
-		RequiredConsecutiveSuccesses:   3,
+		CreateTimeout:                     60 * time.Second,
+		DeleteTimeout:                     10 * time.Second,
+		GetTimeout:                        10 * time.Second,
+		GatewayMustHaveAddress:            180 * time.Second,
+		GatewayStatusMustHaveListeners:    60 * time.Second,
+		GatewayListenersMustHaveCondition: 60 * time.Second,
+		GWCMustBeAccepted:                 180 * time.Second,
+		HTTPRouteMustNotHaveParents:       60 * time.Second,
+		HTTPRouteMustHaveCondition:        60 * time.Second,
+		TLSRouteMustHaveCondition:         60 * time.Second,
+		RouteMustHaveParents:              60 * time.Second,
+		ManifestFetchTimeout:              10 * time.Second,
+		MaxTimeToConsistency:              30 * time.Second,
+		NamespacesMustBeReady:             300 * time.Second,
+		RequestTimeout:                    10 * time.Second,
+		LatestObservedGenerationSet:       60 * time.Second,
+		RequiredConsecutiveSuccesses:      3,
 	}
 }
 
@@ -127,6 +132,9 @@ func SetupTimeoutConfig(timeoutConfig *TimeoutConfig) {
 	if timeoutConfig.GatewayStatusMustHaveListeners == 0 {
 		timeoutConfig.GatewayStatusMustHaveListeners = defaultTimeoutConfig.GatewayStatusMustHaveListeners
 	}
+	if timeoutConfig.GatewayListenersMustHaveCondition == 0 {
+		timeoutConfig.GatewayListenersMustHaveCondition = defaultTimeoutConfig.GatewayListenersMustHaveCondition
+	}
 	if timeoutConfig.GWCMustBeAccepted == 0 {
 		timeoutConfig.GWCMustBeAccepted = defaultTimeoutConfig.GWCMustBeAccepted
 	}
diff --git a/conformance/utils/http/mirror.go b/conformance/utils/http/mirror.go
index d1010588..0179cca2 100644
--- a/conformance/utils/http/mirror.go
+++ b/conformance/utils/http/mirror.go
@@ -45,7 +45,6 @@ func ExpectMirroredRequest(t *testing.T, client client.Client, clientset clients
 			defer wg.Done()
 
 			require.Eventually(t, func() bool {
-				var mirrored bool
 				mirrorLogRegexp := regexp.MustCompile(fmt.Sprintf("Echoing back request made to \\%s to client", path))
 
 				t.Log("Searching for the mirrored request log")
@@ -58,12 +57,11 @@ func ExpectMirroredRequest(t *testing.T, client client.Client, clientset clients
 
 				for _, log := range logs {
 					if mirrorLogRegexp.MatchString(string(log)) {
-						mirrored = true
-						break
+						return true
 					}
 				}
-				return mirrored
-			}, 60*time.Second, time.Second, fmt.Sprintf(`Couldn't find mirrored request in "%s/%s" logs`, mirrorPod.Namespace, mirrorPod.Name))
+				return false
+			}, 60*time.Second, time.Millisecond*100, fmt.Sprintf(`Couldn't find mirrored request in "%s/%s" logs`, mirrorPod.Namespace, mirrorPod.Name))
 		}(mirrorPod)
 	}
 
diff --git a/conformance/utils/kubernetes/helpers.go b/conformance/utils/kubernetes/helpers.go
index aec66fa3..b7cc41f8 100644
--- a/conformance/utils/kubernetes/helpers.go
+++ b/conformance/utils/kubernetes/helpers.go
@@ -267,9 +267,12 @@ func MeshNamespacesMustBeReady(t *testing.T, c client.Client, timeoutConfig conf
 	require.NoErrorf(t, waitErr, "error waiting for %s namespaces to be ready", strings.Join(namespaces, ", "))
 }
 
-// GatewayAndHTTPRoutesMustBeAccepted waits until the specified Gateway has an IP
-// address assigned to it and the Route has a ParentRef referring to the
-// Gateway. The test will fail if these conditions are not met before the
+// GatewayAndHTTPRoutesMustBeAccepted waits until:
+// 1. The specified Gateway has an IP address assigned to it.
+// 2. The route has a ParentRef referring to the Gateway.
+// 3. All the gateway's listeners have the ListenerConditionResolvedRefs set to true.
+//
+// The test will fail if these conditions are not met before the
 // timeouts.
 func GatewayAndHTTPRoutesMustBeAccepted(t *testing.T, c client.Client, timeoutConfig config.TimeoutConfig, controllerName string, gw GatewayRef, routeNNs ...types.NamespacedName) string {
 	t.Helper()
@@ -297,18 +300,24 @@ func GatewayAndHTTPRoutesMustBeAccepted(t *testing.T, c client.Client, timeoutCo
 					SectionName: listener,
 				},
 				ControllerName: v1beta1.GatewayController(controllerName),
-				Conditions: []metav1.Condition{
-					{
-						Type:   string(v1beta1.RouteConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: string(v1beta1.RouteReasonAccepted),
-					},
-				},
+				Conditions: []metav1.Condition{{
+					Type:   string(v1beta1.RouteConditionAccepted),
+					Status: metav1.ConditionTrue,
+					Reason: string(v1beta1.RouteReasonAccepted),
+				}},
 			})
 		}
 		HTTPRouteMustHaveParents(t, c, timeoutConfig, routeNN, parents, namespaceRequired)
 	}
 
+	resolvedRefsCondition := metav1.Condition{
+		Type:   string(v1beta1.ListenerConditionResolvedRefs),
+		Status: metav1.ConditionTrue,
+		Reason: "", // any reason
+	}
+
+	GatewayListenersMustHaveCondition(t, c, timeoutConfig, gw.NamespacedName, resolvedRefsCondition)
+
 	return gwAddr
 }
 
@@ -347,6 +356,29 @@ func WaitForGatewayAddress(t *testing.T, client client.Client, timeoutConfig con
 	return net.JoinHostPort(ipAddr, port), waitErr
 }
 
+// GatewayListenersMustHaveCondition checks if every listener of the specified gateway has a
+// certain condition.
+func GatewayListenersMustHaveCondition(t *testing.T, client client.Client, timeoutConfig config.TimeoutConfig, gwName types.NamespacedName, condition metav1.Condition) {
+	t.Helper()
+
+	waitErr := wait.PollUntilContextTimeout(context.Background(), 1*time.Second, timeoutConfig.GatewayListenersMustHaveCondition, true, func(ctx context.Context) (bool, error) {
+		var gw v1beta1.Gateway
+		if err := client.Get(ctx, gwName, &gw); err != nil {
+			return false, fmt.Errorf("error fetching Gateway: %w", err)
+		}
+
+		for _, listener := range gw.Status.Listeners {
+			if !findConditionInList(t, listener.Conditions, condition.Type, string(condition.Status), condition.Reason) {
+				return false, nil
+			}
+		}
+
+		return true, nil
+	})
+
+	require.NoErrorf(t, waitErr, "error waiting for Gateway status to have a Condition matching expectations on all listeners")
+}
+
 // GatewayMustHaveZeroRoutes validates that the gateway has zero routes attached.  The status
 // may indicate a single listener with zero attached routes or no listeners.
 func GatewayMustHaveZeroRoutes(t *testing.T, client client.Client, timeoutConfig config.TimeoutConfig, gwName types.NamespacedName) {
diff --git a/geps/gep-1619.md b/geps/gep-1619.md
index 6190ffd2..a4504261 100644
--- a/geps/gep-1619.md
+++ b/geps/gep-1619.md
@@ -1,4 +1,4 @@
-# GEP-1619: Session Persistence and Session Affinity
+# GEP-1619: Session Persistence
 
 * Issue: [#1619](https://github.com/kubernetes-sigs/gateway-api/issues/1619)
 * Status: Provisional
@@ -7,14 +7,25 @@
 
 ## TLDR
 
-This GEP proposes a definition of session persistence and session affinity as the foundation of future session persistence related improvements. This GEP also outlines the ways session persistence could be achieved by implementations.
+This GEP initially proposes a definitions for session persistence, followed by the definition of an API spec for
+configuring it. Additionally, it explores example scenarios of session persistence and examines the approaches that
+implementations have taken to design APIs for session persistence. It intentionally refrains from defining an API for
+session affinity, as this design is expected to be addressed within a separate GEP.
 
 ## Goals
+
 - Define session persistence and session affinity to establish a common language
 - Identify differences in session persistence functionality between implementations
+- Define an API for session persistence
+- Establish anticipated outcomes for specific API configurations or scenarios
 
 ## Non-Goals
-- Mandate a default or expected session persistence functionality for implementations
+
+- Define an API for session affinity
+- Mandate a default session persistence or session affinity functionality for implementations
+- Prescribe the precise manner (the "how") in which implementations should achieve session persistence or handle
+  specific scenarios
+- Add API configuration for supporting backend initiated sessions
 
 ## Introduction
 
@@ -60,26 +71,166 @@ 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 Initiation**
-
-For both header-based and cookie-based sessions, either the gateway or the backend server can initiate establishing the session via the appropriate header or set-cookie attributes. The following rules apply based on who initiates the session:
-
-- If the backend initiates the session, the gateway should allow this and not force persistence connections, unless specifically configured to. The gateway may decode and alter the cookie established by the backend to achieve session persistence.
-- If the gateway initiates the session, the backend will be presented with session attributes regardless if it enabled them. 
-
-The client application also plays in a role in session initiation. If a client doesn't want a request to belong an existing session, it can remove the session cookie or identifier to signal the gateway or backend to recreate the session.
-
-### Achieving Session Affinity
-
-While session persistence uses attributes in the application layer, session affinity often uses, but is not limited to, attributes below the application layer. Session affinity doesn't require a session identifier like session persistence (e.g. a cookie), but instead uses existing connection attributes to establish a consistent hashing load balancing algorithm.
-
-Session affinity can be achieved by deterministic load balancing algorithms or a proxy feature that tracks IP-to-backend associations such as [HAProxy's stick tables](https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/) or [Cilium's session affinity](https://docs.cilium.io/en/v1.12/gettingstarted/kubeproxy-free/#id2). 
+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
+
+For all implementations of session persistence, the initiation of the persistent session is possible from various
+sources, including the gateway, intermediary gateway, backend, a sidecar in a backend, or any other infrastructure
+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 persistent connections, unless
+  specifically configured to[^1]. The gateway may decode and alter the cookie established by the backend to achieve
+  session persistence.
+
+It's important to note that we can have more complex implementations which involve traversing global load balancers,
+regional load balancers, intermediary internal gateways, sidecars, or waypoints before reaching the backend. At any
+point within this architecture, a persistent session can be initiated. See [Global Load Balancer Initiated Session Example](#global-load-balancer-initiated-session-example)
+for an example of one of these alternative implementations.
+
+In the next sections, we will take a closer look at the initiation of sessions in both the gateway and the backend.
+Please note that in the next sections, we are examining the various scenarios in which a session can be initiated. We
+are not prescribing specific implementations for session persistence. The intention is to understand the possibilities
+and behaviors related to session initiation while the [API](#api) section will provide more details on specific
+implementation details.
+
+#### Gateway Initiated Session Example
+
+To illustrate how a gateway can initiate a session, let's examine an implementation that uses cookies for persistence.
+This represents the most straightforward scenario for utilizing cookies. When a request is made, the gateway includes
+the `set-cookie` header in the final response, prompting the client to store the cookie. This cookie is subsequently
+used in future requests, allowing the gateway to consistently choose the same upstream, establishing a persistent
+session.
+
+Here an example implementation of a gateway initiating a session through cookies:
+```mermaid
+sequenceDiagram
+    actor C as Client
+    participant G as Gateway
+    participant B as Backend
+    C->>+G: Request Web Page
+    activate G
+    G->>+B: Request
+    B-->>-G: Response
+    G->>G: Add set-cookie header
+    G-->>-C: Response<br>[set-cookie]
+    Note right of G: [set-cookie] indicates a response<br> with a set-cookie header.<br>May include other set-cookie<br>headers from backend.
+    C->>C: Create Cookie(s)<br>from set-cookie header(s)
+    Note right of C: [cookie] indicates a request<br> with one or more cookies
+    C->>+G: Request Web Page<br>[cookie]
+    G->>G: Consistent lookup of<br>server using cookie value
+    G->>+B: Request<br>[cookie]
+    B-->>-G: Response
+    G-->>-C: Response
+```
+
+#### Backend Initiated Session Example
+
+**Important**: While we took it into consideration, this GEP does not support configuring backend-initiated sessions.
+This could potentially affect frameworks that initiate sessions in the backend. Implementing this feature is complicated
+and requires careful design, making it suitable for exploration in a separate GEP.
+
+Continuing with the cookie example, when dealing with backend-initiated sessions, the process becomes somewhat more
+complex. For cookie-based session persistence, the gateway needs to store a value within a cookie containing a backend
+identifier. This identifier can be then used as a reference to maintain a persistent session to a specific backend.
+There are several approaches a gateway could use in this situation to achieve session persistence:
+
+1. Insert an additional cookie
+2. Modify the existing cookie's value
+3. Prefix the existing cookie
+
+Additionally, there are variations to each of these approaches, such as making new or updated cookies transparent to the
+backend, either by remove an inserted cookie or reversing modifications of the cookie's value.
+
+Alternatively, if the backend is not configured for session persistence, the gateway should refrain from modifying or
+inserting a cookie. In this situation, the gateway should remain passive and simply forward the `set-cookie` header as
+it is.
+
+Refer to the [Session Initiation Guidelines](#session-initiation-guidelines) section of the API for implementation
+guidance.
+
+Here's an example implementation of a backend initiating a session and the gateway modifies the cookie's value:
+```mermaid
+sequenceDiagram
+    actor C as Client
+    participant G as Gateway
+    participant B as Backend
+    C->>+G: Request Web Page
+    activate G
+    G->>+B: Request
+    B->>B: Add set-cookie<br>header
+    B-->>-G: Response<br>[set-cookie]
+    G->>G: Modify set-cookie<br>header per configuration
+    G-->>-C: Response<br>[set-cookie*]
+    Note right of G: [set-cookie] indicates a response<br> with a set-cookie header<br>[set-cookie*] indicates a response<br>with a MODIFIED set-cookie header
+    C->>C: Create Cookie<br>from set-cookie header
+    Note right of C: [cookie] indicates a request<br>or response with a cookie
+    C->>+G: Request Web Page<br>[cookie]
+    G->>G: Consistent lookup<br>of server using cookie value
+    G->>+B: Request<br>[cookie]
+    B-->>-G: Response
+    G-->>-C: Response
+```
+
+#### Global Load Balancer Initiated Session Example
+
+In a more complex architecture example, a global load balancer may need to use cookies in order to maintain persistent
+connections to a regional load balancer. The regional cluster load balancer initiates the session by issuing the
+`set-cookie` header and subsequently uses the cookie to maintain persistent connections to a specific backend. The
+global load balancer then adds or modifies a cookie in order to establish persistent connection to a regional cluster
+load balancer.
+
+Here an example implementation of a global load balancer and a regional load balancer creating sessions through cookies:
+```mermaid
+sequenceDiagram
+    actor C as Client
+    participant G as Global<br>Load Balancer
+    participant R as Regional Cluster<br>Load Balancer
+    participant B as Backend
+    C->>+G: Request Web Page
+    G->>+R: Request
+    R->>+B: Request
+    B-->>-R: Response
+    R->>R: Initiates session by<br>adding set-cookie header
+    R-->>-G: Response<br>[set-cookie]
+    G->>G: Add or modify<br>set-cookie header
+    G-->>-C: Response<br>[set-cookie]
+    Note right of G: [set-cookie] indicates a response<br> with a set-cookie header.<br>May include other set-cookie<br>headers from backend or GLB.
+    C->>C: Create Cookie<br>from set-cookie header
+    Note right of C: [cookie] indicates a request<br> with one or more cookies
+    C->>+G: Request Web Page<br>[cookie]
+    G->>G: Consistent lookup of<br>regional cluster load balancer<br>using cookie value
+    G->>+R: Request<br>[cookie]
+    R->>R: Consistent lookup of backend<br>using cookie value
+    R->>+B: Request<br>[cookie]
+    B-->>-G: Response
+    G-->>-C: Response
+```
+
+### When does an application require session persistence?
+
+Enabling session persistence is a required configuration for applications intentionally designed by the application
+developer to use it, as they will encounter failures or malfunctions when it's not enabled. However, it's worth noting
+that certain applications may be designed to function both with and without session persistence. Regardless, the
+importance of Gateway API supporting session persistence remains emphasized because it is frequently seen as a necessary
+feature.
+
+Conversely, apps that have not been designed or tested with session persistence in mind may misbehave when it is
+enabled, primarily because of the impacts of load distribution on the app. Apps using session persistence must account
+for aspects like load shedding, draining, and session migration as a part of their application design.
 
 ### The Relationship of Session Persistence and Session Affinity
 
-Although session persistence and session affinity may appear to be quite similar, it is important to recognize and understand their distinctions. As mentioned above, their distinctions are defined by what information they use to establish session consistency and whether consistency is guaranteed.
+Though this GEP's intention is not to define a spec for session affinity, it is important to recognize and understand
+its distinction with session persistence. While session persistence uses attributes in the application layer, session
+affinity often uses, but is not limited to, attributes below the application layer. Session affinity doesn't require a
+session identifier like session persistence (e.g. a cookie), but instead uses existing connection attributes to
+establish a consistent hashing load balancing algorithm. It is important to note the session affinity doesn't guarantee
+persistent connections to the same backend server.
+
+Session affinity can be achieved by deterministic load balancing algorithms or a proxy feature that tracks IP-to-backend associations such as [HAProxy's stick tables](https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/) or [Cilium's session affinity](https://docs.cilium.io/en/v1.12/gettingstarted/kubeproxy-free/#id2).
 
 We can also examine how session persistence and session affinity functionally work together, by framing the relationship into a two tiered logical decision made by the data plane:
 1. If the request contains a session persistence identity (e.g. a cookie or header), then route it directly to the backend it has previously established a session with.
@@ -88,7 +239,7 @@ We can also examine how session persistence and session affinity functionally wo
 This tiered decision-based logic is consistent with the idea that session persistence is an exception to load balancing. Though there are different ways to frame this relationship, this design will influence the separation between persistence and affinity API design.
 
 ### Implementations
-In this section, we will describe how implementations achieve session persistence and affinity, along with a breakdown of related configuration options. Input from implementations is appreciated to complete this information.
+In this section, we will describe how implementations achieve session persistence, along with a breakdown of related configuration options. Input from implementations is appreciated to complete this information.
 
 In the following tables, we will example two types of APIs:
 1. Dataplane APIs
@@ -96,8 +247,6 @@ In the following tables, we will example two types of APIs:
 
 Generally, the implementation API programs the dataplane API; however these two are not always clearly separated. The two types of APIs can use different API structures for configuring the same feature. Examining the dataplane APIs helps to remove the layer of API abstraction that implementations provide. Removing this layer avoids situations where implementations don’t fully implement all capabilities of a dataplane API or obfuscate certain configuration around session persistence. On the other hand, examining implementation APIs provides valuable data points in what implementations are interested in configuring.
 
-**Session Persistence**
-
 | **Technology** 	| **Technology Type** 	| **Session Persistence Type** 	| **Configuration Options** 	| **Configuration Association (Global, Gateway, Route, or Backends)** 	| **Notes** 	|
 |---	|---	|---	|---	|---	|---	|
 | Acnodal EPIC 	| Implementation (Envoy) 	| N/A 	| Supports Gateway API Only* 	| N/A 	| *Acnodal Epic solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Acnodal EPIC Docs](https://www.epick8sgw.io/docs/) 	|
@@ -127,60 +276,236 @@ Generally, the implementation API programs the dataplane API; however these two
 |  	|  	| [Header-Based](https://docs.konghq.com/gateway/latest/how-kong-works/load-balancing/#balancing-algorithms) 	| name 	| [Upstreams](https://docs.konghq.com/gateway/3.2.x/admin-api/#add-upstream) (Backends) 	| N/A 	|
 | Kuma 	| Implementation (Envoy) 	| None 	| None 	| None 	| Kuma has no documentation on how it supports session persistence or cookies. [Kuma Docs](https://kuma.io/docs/2.1.x/) 	|
 | Nginx  	| Dataplane 	| [Cookie-Based (Nginx Plus Only)](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#enabling-session-persistence) 	| Name=name<br>Expires=time<br>Domain=domain<br>HttpOnly<br>SameSite = [strict \| lax \| none \| $variable]<br>Secure<br>path=path 	| [Upstream](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#enabling-session-persistence) (Backends) 	| See also [Sticky Cookie](https://nginx.org/en/docs/http/ngx_http_upstream_module.html?&_ga=2.184452070.1306763907.1680031702-1761609832.1671225057#sticky_cookie) 	|
-| NGINX Kubernetes Gateway 	| Implementation (Nginx) 	| N/A 	| Supports Gateway API Only* 	| N/A 	| *NGINX Kubernetes Gateway solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Nginx Kubernetes Gateway Docs](https://github.com/nginxinc/nginx-kubernetes-gateway) 	|
+| NGINX Gateway Fabric 	| Implementation (Nginx) 	| N/A 	| Supports Gateway API Only* 	| N/A 	| *NGINX Gateway Fabric solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [NGINX Gateway Fabric Docs](https://github.com/nginxinc/nginx-gateway-fabric) 	|
 | Traefik 	| Implementation / Dataplane 	| [Cookie-Based](https://doc.traefik.io/traefik/routing/services/#sticky-sessions) 	| name=name<br>secure<br>httpOnly<br>sameSite=[none \| lax \| strict ] 	| [Services](https://doc.traefik.io/traefik/routing/services/#sticky-sessions) (Backends) 	| N/A 	|
 
-**Session Affinity**
-
-| **Technology** 	| **Technology Type** 	| **Session Affinity Type** 	| **Notes** 	|
-|---	|---	|---	|---	|
-| Acnodal EPIC 	| Implementation (Envoy) 	| Supports Gateway API Only* 	| *Acnodal Epic solely uses Gateway API; therefore, it doesn’t yet have a way to configure session affinity. [Acnodal EPIC Docs](https://www.epick8sgw.io/docs/) 	|
-| Apache APISIX 	| Implementation (Nginx) 	| [Consistent Hashing](https://apisix.apache.org/docs/apisix/plugins/traffic-split/#attributes) via consumer ID or other variables 	| N/A 	|
-| Cilium 	| Implementation / Dataplane 	| [Source IP Address](https://docs.cilium.io/en/v1.12/gettingstarted/kubeproxy-free/#id2) (Default) 	| N/A 	|
-| Contour 	| Implementation (Envoy) 	| Consistent Hashing via [RequestHash](https://projectcontour.io/docs/1.24/config/request-routing/#load-balancing-strategy) 	| N/A 	|
-| Emissary-Ingress 	| Implementation (Envoy) 	| Consistent Hashing via [sourceIP](https://www.getambassador.io/docs/emissary/latest/topics/running/load-balancer#source-ip) 	| N/A 	|
-| Envoy 	| Dataplane 	| Consistent Hashing via [Maglev](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#maglev) and [Ring Hash](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#ring-hash) 	| N/A 	|
-| Envoy Gateway 	| Implementation (Envoy) 	| Supports Gateway API Only* 	| *Envoy Gateway solely uses Gateway API; therefore, it doesn’t yet have a way to configure session affinity. [Envoy Gateway Docs](https://gateway.envoyproxy.io/v0.3.0/index.html) 	|
-| Flomesh Service Mesh 	| Implementation / Dataplane (Pipy) 	| ? 	| ? 	|
-| Gloo Edge 2.0 	| Implementation (Envoy) 	| Consistent Hashing via HashPolicy of [SourceIP](https://docs.solo.io/gloo-edge/latest/reference/api/envoy/api/v2/route/route.proto.sk/#connectionproperties) 	| N/A 	|
-| Google CloudRun	 	| Implementation / Dataplane 	| None 	| [Google CloudRun Docs](https://cloud.google.com/run/docs) 	|
-| Google Kubernetes Engine 	| Implementation / Dataplane 	| [CLIENT_IP_NO_DESTINATION](https://cloud.google.com/load-balancing/docs/backend-service#client-ip-no-destination-affinity) and [CLIENT_IP](https://cloud.google.com/load-balancing/docs/backend-service#client_ip_affinity) 	| Google Kubernetes Engine [lists](https://cloud.google.com/load-balancing/docs/backend-service#bs-session-affinity) the products that can do persistence/affinity mode. Session affinity settings are fulfilled only if the load balancing locality policy (LocalityLbPolicy) is set to RING_HASH or MAGLEV. All persistence/affinity options are exclusive and can’t be used at the same time.<br>Note: Google Kubernetes Engine defines everything (persistence and affinity) as session affinity. 	|
-| HAProxy 	| Dataplane 	| [Stick Tables](https://cbonte.github.io/haproxy-dconv/2.4/configuration.html#4-stick-table) using connection attributes 	| N/A 	|
-| HAProxy Ingress 	| Implementation (HAProxy) 	| None 	| [Haproxy Ingress Docs](https://haproxy-ingress.github.io/docs/configuration/keys/) 	|
-| Hashicorp Consul  	| Implementation (Envoy) 	| Supports Gateway API Only* 	| *Hashicorp Consul solely uses Gateway API; therefore, it doesn’t yet have a way to configure session affinity. [Hashicorp Consul API Gateway Docs](https://developer.hashicorp.com/consul/docs/api-gateway) 	|
-| Istio 	| Implementation (Envoy) 	| Consistent Hashing via [ConsistentHashLB](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB) with Maglev or Ring Hash  	| N/A 	|
-| Kong 	| Implementation / Dataplane 	| [Consistent Hashing](https://docs.konghq.com/gateway/latest/how-kong-works/load-balancing/#balancing-algorithms) via Source IP or Consumer ID 	| N/A 	|
-| Kuma 	| Implementation (Envoy) 	| Consistent Hashing via [Ring Hash](https://kuma.io/docs/2.1.x/policies/traffic-route/#load-balancer-types) 	| N/A 	|
-| Nginx 	| Dataplane 	| [Consistent Hashing](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash) via IP or other connection attributes (Nginx Open Source) 	| N/A 	|
-| NGINX Kubernetes Gateway 	| Implementation (Nginx) 	| Supports Gateway API Only* 	| *NGINX Kubernetes Gateway solely uses Gateway API; therefore, it doesn’t yet have a way to configure session affinity. [Nginx Kubernetes Gateway Docs](https://github.com/nginxinc/nginx-kubernetes-gateway) 	|
-| Traefik 	| Implementation / Dataplane 	| None 	| [Traefik Docs](https://doc.traefik.io/traefik/) 	|
-
 ### Sessions in Java
 
-Java application servers such as Tomcat and Jetty, were the first to standardize the API around persistent sessions. These Java applications introduced the “jsessionid” cookie as well as more advanced features such as session migration, replication, and on demand session activation. It’s important for Gateway API to examine persistent session use cases and history from Java APIs to ensure the API is designed appropriately.
-
-## API
-
-### Session Persistence API
+Java application servers such as Tomcat and Jetty, were the first to standardize the API around cookies and sessions.
+These Java applications introduced the “jsessionid” cookie and session IDs encoded in URL parameters as well as more
+advanced features such as session migration, replication, and on demand session activation. It’s important for Gateway
+API to examine cookie use cases and history from Java APIs to ensure the API is designed appropriately.
 
-The majority of implementations and dataplanes support configuring cookies for session persistence while support for header-based session persistence is limited.
+### Session Affinity in K8S Services
 
-To organize potential Gateway API configuration of cookie functionality, the next section will break down configuration into specific categories:
-- Session Cookie Configuration
-- Session Cookie Strategy
+Kubernetes provides an API that allows you to enable [session affinity](https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity)
+on service objects. It ensures consistent sessions by utilizing the client's IP address and also offers the option to
+set a timeout for the maximum session duration. Implementations of Gateway API, such as service mesh use cases, may use
+the service IP directly. In these cases where both Kubernetes service session affinity and Gateway API session
+persistence are both enabled, the route must be rejected, and a status should be set describing the incompatibility of
+these two configurations.
 
-**Session Cookie Configuration**
+## API
 
-Session cookie configuration are the parameters and attributes the dataplane uses to create a cookie for establishing a session.
+In this section, we will explore the questions and design elements associated with a session persistence API.
+
+### GO
+
+```go
+// SessionPersistencePolicy provides a way to define session persistence rules
+// for a service or route.
+//
+// Support: Core
+type SessionPersistencePolicy struct {
+    metav1.TypeMeta   `json:",inline"`
+    metav1.ObjectMeta `json:"metadata,omitempty"`
+
+    // Spec defines the desired state of SessionPersistencePolicy.
+    Spec SessionPersistencePolicySpec `json:"spec"`
+
+    // Status defines the current state of SessionPersistencePolicy.
+    Status SessionPersistencePolicyStatus `json:"status,omitempty"`
+}
+
+// SessionPersistencePolicySpec defines the desired state of
+// SessionPersistencePolicy.
+// 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, GRPCRoute,
+    // or a HTTPRouteRule or GRPCRouteRule section.
+    // At least one of these targets must be supported for
+    // core-level compliance.
+    //
+    TargetRef gatewayv1a2.PolicyTargetReference `json:"targetRef"`
+
+    // AbsoluteTimeoutSeconds defines the absolute timeout of the
+    // persistent session measured in seconds. Once
+    // AbsoluteTimeoutSeconds has elapsed, the session becomes invalid.
+    //
+    // Support: Core
+    //
+    // +optional
+    AbsoluteTimeoutSeconds int64 `json:"absoluteTimeoutSeconds,omitempty"`
+
+    // IdleTimeoutSeconds defines the idle timeout of the
+    // persistent session measured in seconds. Once the session
+    // has been idle for more than specified IdleTimeoutSeconds
+    // duration, the session becomes invalid.
+    //
+    // Support: Core
+    //
+    // +optional
+    IdleTimeoutSeconds int64 `json:"idleTimeoutSeconds,omitempty"`
+
+    // SessionName defines the name of the persistent session token
+    // (e.g. a cookie name).
+    //
+    // Support: Extended
+    //
+    // +optional
+    // +kubebuilder:validation:MaxLength=4096
+    SessionName String `json:"sessionName,omitempty"`
+}
+
+// SessionPersistencePolicyStatus defines the observed state of SessionPersistencePolicy.
+type SessionPersistencePolicyStatus struct {
+    // Conditions describe the current conditions of the SessionPersistencePolicy.
+    //
+    // Implementations should prefer to express SessionPersistencePolicy
+    // conditions using the `SessionPersistencePolicyConditionType` and
+    // `SessionPersistencePolicyConditionReason` constants so that
+    // operators and tools can converge on a common vocabulary to
+    // describe SessionPersistencePolicy state.
+    // Known condition types are:
+    //
+    // * “Accepted”
+    //
+    // +optional
+    // +listType=map
+    // +listMapKey=type
+    // +kubebuilder:validation:MaxItems=8
+    // +kubebuilder:default={type: "Accepted", status: "Unknown", reason:"Pending", message:"Waiting for validation", lastTransitionTime: "1970-01-01T00:00:00Z"}
+    Conditions []metav1.Condition `json:"conditions,omitempty"`
+}
+
+// SessionPersistencePolicyConditionType is the type of condition used
+// as a signal by SessionPersistencePolicy. This type should be used with
+// the SessionPersistencePolicy.Conditions field.
+type SessionPersistencePolicyConditionType string
+
+// SessionPersistencePolicyConditionReason is a reason that explains why a
+// particular SessionPersistencePolicyConditionType was generated. This reason
+// should be used with the SessionPersistencePolicy.Conditions field.
+type SessionPersistencePolicyConditionReason string
+
+const (
+    // This condition indicates that the SessionPersistencePolicyStatus has been
+    // accepted as valid.
+    // Possible reason for this condition to be True is:
+    //
+    // * “Accepted”
+    //
+    // Possible reasons for this condition to be False are:
+    //
+    // * “Invalid”
+    // * “Pending”
+    SessionPersistencePolicyConditionAccepted SessionPersistencePolicyConditionType = “Accepted”
+
+    // This reason is used with the “Accepted” condition when the condition is true.
+    SessionPersistencePolicyReasonAccepted SessionPersistencePolicyConditionReason = “Valid”
+
+	// This reason is used with the “Accepted” condition when the SessionPersistencePolicy is invalid, e.g. crossing namespace boundaries.
+    SessionPersistencePolicyReasonInvalid SessionPersistencePolicyConditionReason = “Invalid”
+
+    // This reason is used with the “Accepted” condition when the SessionPersistencePolicy is pending validation.
+    SessionPersistencePolicyReasonPending SessionPersistencePolicyConditionReason = “Pending”
+)
+```
+
+### API Granularity
+
+The purpose of this session persistence API spec is to enable developers to specify that a specific backend expects a
+persistent session. However, it intentionally avoids specifying low-level details or configurations related to the
+session persistence implementation, such as cookie attributes. This decision is because the Gateway API supports various
+infrastructure types, and some implementations that already provide session persistence may not be able to adhere to a
+low-level API.
+
+For instance, platforms using global load balancers to maintain persistent sessions between regional load balancers, or
+Tomcat servlets generating distinct cookies per server. In such scenarios, it is important that this GEP does not
+obstruct the existing use of cookies while enabling session persistence. Enabling particular low-level API
+configurations, like allowing customization of the cookie name, could prevent certain implementations from conforming to
+the spec. In other words, opting for a higher-level API provides better interoperability among our implementations.
+
+### Target Persona
+
+Referring to the [Gateway API Security Model](https://gateway-api.sigs.k8s.io/concepts/security-model/#roles-and-personas),
+the target kubernetes role/persona for session persistence are application developers, as mentioned in the [When does an application require session persistence?](#when-does-an-application-require-session-persistence)
+section. It is the responsibility of the application developers to adjust the persistence configuration to ensure the
+functionality of their applications.
+
+### Prior Art
+
+Referring to our [Implementations](#Implementations) table on session persistence, the majority of Gateway API
+implementations designed session persistence in their APIs to be attached to a service or backends. This should be
+considered cautiously, as making associations to Gateway API's notion of Gateway, Route, and Service to other
+implementation's objects is hard to directly translate. The idea of a route in Gateway API is often not the same as a
+route in any given implementation.
+
+### Metaresource Policy Design
+
+In order to apply session persistence configuration to both a service and a route, we will implement it as a
+metaresource policy, as outlined in [Policy Attachment](https://gateway-api.sigs.k8s.io/references/policy-attachment/#direct-policy-attachment).
+The metaresource is named `SessionPersistencePolicy` and is only responsible for configuring session persistence for
+services or routes. It is defined as a [Direct Policy Attachment](https://gateway-api.sigs.k8s.io/v1alpha2/references/policy-attachment/#direct-policy-attachment)
+without defaults or overrides, applied to the targeted service, HTTPRoute, or GRPCRoute.
+
+Attaching the `SessionPersistencePolicy` metaresource to a service will be a core support level feature, while attaching
+it to a route will be considered extended. Implementations must support services for conformance, while routes are
+considered optional. This distinction arises because most existing implementations primarily support attaching to a
+service, while attaching to a route is less common and involves greater complexities (see [API Attachment Points](#api-attachment-points)
+for more details).
+
+### API Attachment Points
+
+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 to 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, route rule, or service) to be compliant with this GEP.
+
+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.
+
+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
+
+In scenarios involving traffic splitting, session persistence impacts load balancing done after routing, regardless if
+it is attached to a service or a route. When a persistent session is established and traffic splitting is configured
+across services, the persistence to a single backend should be maintained across services. Consequently, a persistent
+session takes precedence over traffic split weights when selecting a backend after route matching. It's important to
+note that session persistence does not impact the process of route matching.
+
+When using multiple backends in traffic splitting, all backend services should have session persistence enabled.
+Nonetheless, implementations should also support traffic splitting scenarios in which one service has persistence
+enabled while the other does not. This support is necessary, particularly in scenarios where users are transitioning
+to or from an implementation version designed with or without persistence.
+
+See [Expected API Behavior](#expected-api-behavior) for more use cases on traffic splitting.
+
+### Cookie Attributes
 
-A set-cookie request can be broken down into [3 main components](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie):
-- Cookie Name
-- Cookie Value
-- Cookie Attributes
+While the API is intended to be generic, as described in [API Granularity](#api-granularity), a majority of
+implementations will employ session persistence through cookies. Therefore, let's explore the possibilities of cookie
+configuration for these APIs.
 
-Only the Cookie Name and Cookie Value are required. All Cookie Attributes are optional. Attributes are simply key=value pairs with the value as optional for some attributes.
+A cookie is composed of various attributes, each represented as key=value pairs. While some attributes may have optional
+values, the cookie name attribute is the only mandatory one, and the rest are considered optional.
 
-The set-cookies attributes defined by [rfc6265](https://www.rfc-editor.org/rfc/rfc6265#section-5.2) are:
+The cookie attributes defined by [RFC6265](https://www.rfc-editor.org/rfc/rfc6265#section-5.2) are:
+- Name=_value_
 - Expires=_date_
 - Max-Age=_number_
 - Domain=_domain_
@@ -188,40 +513,374 @@ The set-cookies attributes defined by [rfc6265](https://www.rfc-editor.org/rfc/r
 - Secure
 - HttpOnly
 
-However, there are de-facto standard attributes that have been proposed as updates to [rfc6265](https://www.rfc-editor.org/rfc/rfc6265#section-5.2):
-- SameSite=_[Strict|Lax|None]_ ([Draft RFC Update](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-same-site-00))
-- Partitioned ([Draft RFC Update](https://www.ietf.org/archive/id/draft-cutler-httpbis-partitioned-cookies-01.html))
+Other cookie attributes not defined by RFC6265, but are captured in draft RFCs and could be considered de facto
+standards due to wide acceptance are:
+- SameSite=[Strict|Lax|None]
+- Partitioned
+
+Unless a `SessionPersistencePolicy` API field can be satisfied through a manipulating a cookie attribute, the attributes
+of the cookies are considered as opaque values in this spec and are to be determined by the individual implementations.
+Let's discuss some of these cookie attributes in more detail.
 
-**Session Cookie Strategy**
+#### Name
 
-Session cookie strategy is configuration specific to the creation of the cookie by the dataplane. These are not specific configuration parameters of the cookie itself, but instead the operation to take when inserting the cookie such as:
-- Rewriting an existing cookie value
-- Inserting a new cookie
-- Prefixing an existing cookie
-- Preserving an existing cookie value
-- Only adding cookies on specific HTTP methods (POST/GET)
+The `Name` cookie attribute can be configured via the `SessionName` field on `SessionPersistencePolicy`. However, this
+field is considered extended support level. This is because some implementations, such as ones supporting global load
+balancers, don't have the capability to configure the cookie name.
 
-### Session Affinity API
+#### TTL
 
-TBD - See [open question](#open-questions) about session affinity API
+The `TTL` cookie attribute may be influenced by the `AbsoluteTimeoutSeconds` field on `SessionPersistencePolicy`.
+However, it's important to understand that `AbsoluteTimeoutSeconds` represents the duration of the entire session, not
+just the cookie duration. Conversely, the cookie's `TTL` attribute does not have to be configured in order to implement
+`AbsoluteTimeoutSeconds`.
+
+#### Path
+
+The cookie's `Path` attribute defines the URL path that must exist in order for the client to send the `cookie` header.
+Whether attaching session persistence to an xRoute or a service, it's important to consider the relationship the cookie
+`Path` attribute has with the route path.
+
+When the `SessionPersistencePolicy` policy is attached to an xRoute, the implementor should interpret the path as
+configured on the xRoute. To interpret the `Path` attribute from an xRoute, implementors should take note of the
+following:
+
+1. For an xRoute that matches all paths, the `Path` should be set to `/`.
+2. For an xRoute that has multiple paths, the `Path` should be interpreted based on the route path that was matched.
+3. For an xRoute using a path that is a regex, the `Path` should be set to the longest non-regex prefix (.e.g. if the
+   path is /p1/p2/*/p3 and the request path was /p1/p2/foo/p3, then the cookie path would be /p1/p2).
+
+It is also important to note that this design makes persistent session unique per route path. For instance, if two
+distinct routes, one with path prefix `/foo` and the other with `/bar`, both target the same service, the persistent
+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
+
+The `Secure`, `HttpOnly`, and `SameSite` cookie attributes are security-related. The API implementers should follow the
+security-by-default principle and configure these attributes accordingly. This means enabling `Secure` and `HttpOnly`,
+and setting `SameSite` to `Strict`. However, in certain implementation use cases such as service mesh, secure values
+might not function as expected. In such cases, it's acceptable to make appropriate adjustments.
+
+### Session Persistence API with GAMMA
+
+The object of the [GAMMA (Gateway API for Mesh Management and Administration)](https://gateway-api.sigs.k8s.io/contributing/gamma/)
+initiative is to provide support for service mesh and mesh-adjacent use-cases with Gateway API. GAMMA is focused on
+defining how Gateway API could also be used for inter-service or [east/west](https://gateway-api.sigs.k8s.io/concepts/glossary/#eastwest-traffic)
+traffic within the same cluster.
+
+Given that service meshes commonly have session persistence requirements, this API design should take into consideration
+session persistence needs in GAMMA and service mesh scenarios.
+
+### Session Initiation Guidelines
+
+As illustrated in the examples provided in [Session Persistence Initiation](#session-persistence-initiation),
+implementations must consider how to manage sessions initiated by other components. As mentioned in [Backend Initiated Session Example](#backend-initiated-session-example),
+this GEP does not support configuring backend-initiated persistent sessions. We leave the decision of handling existing
+sessions with each specific implementation. In the case of cookie-based session persistence, an implementation has the
+freedom to either rewrite the cookie or insert an additional cookie, or to do nothing (resulting in the lack of a
+persistent session). In general, inserting an additional cookie is a generally safe option, but it's important for
+implementations to exercise their own discretion. However, regardless of the implementation's design choice, the
+implementation must be able to handle multiple cookies.
+
+### Expected API Behavior
+
+Implementing session persistence is complex and involves many edge cases. In this section, we will outline API
+configuration scenarios (use cases) and how implementations should handle them.
+
+#### Attaching Session Persistence to both Service And Route
+
+In a situation which:
+- `ServiceA` with `SessionPersistencePolicy` attached
+- `RouteX` with `SessionPersistencePolicy` attached and backend `ServiceA`
+
+The `SessionPersistencePolicy` policy attached to `RouteX` should take precedence. Since routes effectively group
+services, the policy attached to xRoutes operates at a higher-level and should override policies applied to individual
+services.
+
+```mermaid
+graph TB
+   RouteX ----> ServiceA((ServiceA))
+   SessionPersistencePolicyServiceA[SessionPersistence] -.-> ServiceA
+   SessionPersistencePolicyRouteA[SessionPersistence] -.Precedence.-> RouteX
+   linkStyle 2 stroke:red;
+```
+
+#### Two Routes Share Backends with Session Persistence Applied only on one Route
+
+In the situation in which:
+- `ServiceA` with`SessionPersistencePolicy` attached
+- `ServiceB` with no session persistence
+- `RouteX` with no session persistence backends `ServiceA` and `ServiceB`
+
+At this point, traffic through `RouteX` to `ServiceB` doesn't use session persistence.
+
+A new route is added:
+- `RouteY` with `SessionPersistencePolicy` attached
+
+Even though it's not explicitly configured, traffic flowing through `RouteX` to `ServiceB` should utilize session
+persistence. This behavior occurs because `ServiceB` has session persistence configured via `RouteY`.
+
+```mermaid
+graph TB
+   RouteX ----> ServiceA((ServiceA))
+   RouteX --Persistence--> ServiceB
+   RouteY ----> ServiceA
+   RouteY ----> ServiceB((ServiceB))
+   SessionPersistencePolicyServiceA[SessionPersistence] -.-> ServiceA
+   SessionPersistencePolicyRouteB[SessionPersistence] -.-> RouteY
+   linkStyle 1 stroke:red;
+```
+
+#### Traffic Splitting
+
+Consider the scenario where a route is traffic splitting between two backends, and additionally, a
+`SessionPersistencePolicy` is attached to the route:
+```yaml
+kind: HTTPRoute
+metadata:
+  name: split-route
+spec:
+  rules:
+  - backendRefs:
+    - name: servicev1
+      weight: 50
+    - name: servicev2
+      weight: 50
+---
+kind: SessionPersistencePolicy
+metadata:
+  name: spp-split-route
+spec:
+  targetRef:
+    kind: HTTPRoute
+    name: split-route
+  type: HTTPCookie
+```
+
+When persistent sessions are established, the persistence to a single backend should override the traffic splitting
+configuration.
+
+#### Traffic Splitting with two Backends and one with Weight 0
+
+Consider the scenario where a route has two path matches, but one of those paths involves traffic splitting with a
+backendRef that has a weight of 0, and additionally, a `SessionPersistencePolicy` is attached to the route:
+```yaml
+kind: HTTPRoute
+metadata:
+  name: split-route
+spec:
+  rules:
+  - matches:
+    - path:
+      value: /a
+    backendRefs:
+    - name: servicev1
+  - matches:
+    - path:
+      value: /b
+    backendRefs:
+    - name: servicev1
+      weight: 0
+    - name: servicev2
+      weight: 100
+---
+kind: SessionPersistencePolicy
+metadata:
+  name: spp-split-route
+spec:
+  targetRef:
+    kind: HTTPRoute
+    name: split-route
+  type: HTTPCookie
+```
+
+A potentially unexpected situation occurs when:
+1. Curl to `/a` which establishes a persistent session with `servicev1`
+2. Curl to `/b` routes to `servicev1` due to route persistence despite `weight: 0` configuration
+
+In this scenario, implementations should give precedence to session persistence, regardless of the `weight`
+configuration.
+
+#### A Service's Selector is Dynamically Updated
+
+In Kubernetes, it's possible to modify the [selector](https://kubernetes.io/docs/concepts/services-networking/service/#services-in-kubernetes)
+of a service after the gateway has established persistent sessions with it.
+
+```yaml
+kind: Service
+metadata:
+  name: my-service
+spec:
+  selector:
+    app.kubernetes.io/name: MyApp # Service selector can change
+```
+
+The expected behavior is that the gateway will retain existing persistent sessions, even if the pod is no longer
+selected, and establish new persistent sessions after a selector update. This use case is uncommon and may not be
+supported by some implementations due to their current designs.
 
 ### Open Questions
 
-- Should we include both session persistence and session affinity API configurations in this GEP or just focus on session persistence?
-- Should both session persistence and session affinity be designed as common load balancing policy API? Should they be configured as separately in the API?
 - What happens when session persistence is broken because the backend is not up or healthy? If that's an error case, how should that be handled? Should the API dictate the http error code? Or should the API dictate fall back behavior?
+- What happens when session persistence causes traffic splitting scenarios to overload a backend?
+- Should we add status somewhere when a user gets in to a "risky" configuration with session persistence?
+- Should there be an API configuration field that specifies how already established sessions are handled?
 
 ## TODO
 The following are items that we intend to resolve before we consider this GEP implementable:
 
-- We need to identify the needs and use cases from end users for specifying session persistence.
 - 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)
+    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 design and document an API for session persistence and/or session affinity in the Gateway API spec (see [open question](#open-questions) about API design)
+- 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 an implementation can implement session persistence in a
+predicable way.
 
 ## Alternatives
 
+### Alternate Session Persistence API
+
+Alternatively, the API for Session Persistence could define a loosely-typed list of attributes instead of strongly-typed
+attribute fields. This approach offers a more flexible specification, particularly when new attributes need to be
+introduced. However, loosely-typed lists may not be as user-friendly due to the lack of validation.
+
+```go
+// HttpCookie defines a cookie to achieve session persistence.
+//
+// Support: Core
+type HttpCookie struct {
+    // Name defines the cookie's name.
+    //
+    // Support: Core
+    //
+    // +kubebuilder:validation:MaxLength=4096
+    Name String `json:"name,omitempty"`
+    
+    // CookieAttributes defines the cookie's attributes.
+    //
+    // Support: Core
+    // +optional
+    CookieAttributes []CookieAttribute `json:cookieAttributes`
+}
+
+// CookieAttribute defines the cookie's attributes.
+type CookieAttribute map[string][]string
+)
+```
+
+The API could also be a mix of individual fields and listed attributes. More specifically, we could separate the key
+attributes with no value into a list. This approach is taken by [Haproxy Ingress](https://haproxy-ingress.github.io/docs/configuration/keys/#affinity)
+with their `session-cookie-keywords` field. This provides flexibility for simple boolean-typed attributes, while
+validating attributes that have values. However, this approach may be confusing to users as uses two different API
+patterns for cookie attributes.
+
+```go
+// HttpCookie defines a cookie to achieve session persistence.
+//
+// Support: Core
+type HttpCookie struct {
+    // Name defines the cookie's name.
+    //
+    // Support: Core
+    //
+    // +kubebuilder:validation:MaxLength=4096
+    Name String `json:"name,omitempty"`
+
+    // SameSite defines the cookie's SameSite attribute.
+    //
+    // Support: Extended
+    //
+    // +optional
+    // +kubebuilder:validation:Enum=Strict;Lax;None
+    SameSite SameSiteType `json:"sameSite,omitempty"`
+    
+    // Domain defines the cookie's Domain attribute.
+    //
+    // Support: Extended
+    //
+    // +optional
+    // +kubebuilder:validation:MaxLength=4096
+    Domain String `json:"domain,omitempty"`
+    
+    // CookieKeywords defines the cookie's attributes that have no value.
+    //
+    // Support: Extended
+    // +optional
+    CookieKeywords []CookieKeyword `json:cookieKeywords`
+}
+
+// CookieKeyword defines the cookie's attributes that have no value.
+type CookieKeyword string
+
+const (
+    // CookieKeywordsHttpOnly specifies the HttpOnly cookie attribute.
+    CookieKeywordsHttpOnly HttpOnlyMode = "HttpOnly"
+    // CookieKeywordsSecure specifies the Secure cookie attribute.
+    CookieKeywordsSecure HttpOnlyMode = "Secure"
+)
+```
+
+Taking a different approach, this GEP could design a generic approach to configuring load balancing policy. Instead of
+only having a metaresource specifically for session persistence, a metaresource called `LoadBalancerPolicy` of which
+includes a field for session persistence along with other load balancer related configuration. It's important to note
+that persistent session takes priority over balance algorithm.
+
+The `LoadBalancerPolicy` design provides tighter coupling with other load balancing configuration which help reduce CRD
+proliferation, but may limit API flexibility as it forces coupling between concepts that may not be appropriate for
+current and future implementations.
+
+```go
+// LoadBalancerPolicy provides a way to define load balancing rules
+// for a service.
+//
+// Support: Core
+type LoadBalancerPolicy struct {
+    metav1.TypeMeta   `json:",inline"`
+    metav1.ObjectMeta `json:"metadata,omitempty"`
+
+    // Spec defines the desired state of LoadBalancerPolicy.
+    Spec LoadBalancerPolicySpec `json:"spec"`
+
+    // Status defines the current state of LoadBalancerPolicy.
+    Status LoadBalancerPolicyStatus `json:"status,omitempty"`
+}
+
+// LoadBalancerPolicySpec defines the desired state of
+// LoadBalancerPolicy.
+// Note: there is no Override or Default policy configuration.
+type LoadBalancerPolicySpec struct {
+    // TargetRef identifies an API object to apply policy to.
+    // Services are the only valid API target references.
+    TargetRef gatewayv1a2.PolicyTargetReference `json:"targetRef"`
+
+    // SessionPersistence defines and configures session persistence.
+    SessionPersistence *SessionPersistence `json:"sessionPersistence"`
+    
+    // BalanceAlgorithm defines and configures the load balancer
+    // balancing algorithm.
+    BalanceAlgorithm *BalanceAlgorithm `json:"balanceAlgorithm"`
+}
+
+// SessionPersistence defines and configures session persistence.
+//
+// Support: Core
+type SessionPersistence struct {
+    // HttpCookie defines and configures a cookie to achieve
+    // session persistence.
+    //
+    // Support: Core
+    HttpCookie *HttpCookie `json:"httpCookie"`
+}
+```
+
 ### Alternate Naming
 
 This GEP describes session persistence and session affinity as the idea of strong and weak connection persistence respectively. Other technologies use different names or define persistence and affinity differently:
@@ -240,3 +899,8 @@ Though session persistence is a ubiquitous name, session affinity is more incons
 - [LBPolicy](https://static.sched.com/hosted_files/kccnceu2023/c4/Autoscaling%20Elastic%20Kubernetes%20Infrastructure%20for%20Stateful%20Applications%20using%20Proxyless%20gRPC%20and%20Istio.pdf#page=25) (proposed extension for session persistence API)
 - [gRPC Stateful Session Affinity Proposal](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md) (info on session draining and session persistence in gRPC)
 - [Kube-Proxy Session Affinity](https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity)
+- [GEP-713: Metaresources and PolicyAttachment](/geps/gep-713/)
+- [RFC6265](https://www.rfc-editor.org/rfc/rfc6265)
+- [Policy Attachment](https://gateway-api.sigs.k8s.io/references/policy-attachment/#direct-policy-attachment)
+- [Envoy Session Persistence Design Doc](https://docs.google.com/document/d/1IU4b76AgOXijNa4sew1gfBfSiOMbZNiEt5Dhis8QpYg/edit#heading=h.sobqsca7i45e)
+- [Envoy Session Persistence Issue](https://github.com/envoyproxy/envoy/issues/16698)
\ No newline at end of file
diff --git a/geps/gep-1742.md b/geps/gep-1742.md
index 1e6836dc..435178fc 100644
--- a/geps/gep-1742.md
+++ b/geps/gep-1742.md
@@ -61,7 +61,7 @@ support layer 7, please feel free to correct them.
 | Kong           | Nginx      |
 | Kuma           | Envoy      |
 | Litespeed      | Litespeed WebADC |
-| Nginx Kubernetes Gateway | Nginx |
+| NGINX Gateway Fabric | Nginx |
 | Traefik        | Traefik    |
 
 
diff --git a/geps/gep-1762.md b/geps/gep-1762.md
new file mode 100644
index 00000000..1a890cdb
--- /dev/null
+++ b/geps/gep-1762.md
@@ -0,0 +1,248 @@
+# GEP-1762: In Cluster Gateway Deployments
+
+* Status: Provisional
+
+## Overview
+
+Gateway API provides a common abstraction over different implementations, whether they are implemented by cloud load balancers, in-cluster deployments, or other mechanisms. However, many in-cluster implementations have solved some of the same problems in different ways.
+
+Related discussions:
+
+* [Support cluster-local Gateways](https://github.com/kubernetes-sigs/gateway-api/discussions/1247)
+* [Scaling Gateway Resources](https://github.com/kubernetes-sigs/gateway-api/discussions/1355)
+* [Manual deployments](https://github.com/kubernetes-sigs/gateway-api/issues/1687)
+* [Merging Gateways](https://github.com/kubernetes-sigs/gateway-api/pull/1863/)
+* [Per-Gateway Infrastructure](https://github.com/kubernetes-sigs/gateway-api/pull/1757)
+
+## Goals
+
+* Provide prescriptive guidance for how in-cluster implementations should behave.
+* Provide requirements for how in-cluster implementations should behave.
+
+Note that some changes will be suggestions, while others will be requirements.
+
+## Non-Goals
+
+* Provide guidance to how out-of-cluster implementations should behave. Rather, this document aims to bring consistency between these types.
+
+## Terminology
+
+This document uses a few terms throughout. To ensure consistency, they are defined below:
+
+* In-cluster deployment: refers to an implementation that actuates a `Gateway` by running a data plane in the cluster.
+  This is *often*, but not necessarily, by deploying a `Deployment`/`DaemonSet` and `Service`.
+* Automated deployment: refers to an implementation that automatically deploys the data plane based on a `Gateway`.
+  That is, the user simply creates a `Gateway` resource and the rest is handled behind the scenes by the implementation.
+
+## Design
+
+This GEP both introduces new API fields, and standardizes how implementations should behave when implementing the existing API.
+
+### Automated Deployments
+
+A simple `Gateway`, as is configured below is assumed to be an automated deployment:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: Gateway
+metadata:
+  name: my-gateway
+spec:
+  gatewayClassName: example
+  listeners:
+  - name: default
+    port: 80
+    protocol: HTTP
+```
+
+With this configuration, an implementation:
+
+* MUST mark the Gateway as `Programmed` and provide an address in `Status.Addresses` where the Gateway can be reached on each configured port.
+* MUST label all generated resources (Service, Deployment, etc) with `gateway.networking.k8s.io/gateway-name: my-gateway` (where `my-gateway` is the name of the Gateway resource).
+* MUST provision generated resources in the same namespace as the Gateway if they are namespace scoped resources.
+  * Cluster scoped resources are not recommended.
+* SHOULD name all generated resources `my-gateway-example` (`<NAME>-<GATEWAY CLASS>`).
+  This is not simply `NAME` to reduce the chance of conflicts with existing resources.
+  Where required, this can also serve as the prefix for the object.
+
+### Customizations
+
+With any in-cluster deployment, customization requirements will arise. 
+
+Some common requirements would be:
+
+* `Service.spec.type`, to control whether a service is a `ClusterIP` or `LoadBalancer`.
+* IP in the Service to assign to it.
+* Arbitrary labels and annotations on generated resources.
+* Any other arbitrary fields; the list is unbounded. Some examples would be:
+  * CPU and memory requests
+  * Service `externalTrafficPolicy`
+  * Affinity rules.
+
+This GEP currently only aims to solve a subset of these concerns. Additional concerns may be addressed in future revisions or other GEPs.
+
+#### Gateway Type
+
+This is handled by [GEP-1651](https://github.com/kubernetes-sigs/gateway-api/pull/1653), so won't be described here.
+
+#### Gateway IP
+
+This section just clarifies and existing part of the spec, how to handle `.spec.addresses` for in-cluster implementations.
+Like all other Gateway types, this should impact the address the `Gateway` is reachable at.
+
+For implementations using a `Service`, this means the `clusterIP` or `loadBalancerIP` (depending on the `Service` type).
+
+For example:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: Gateway
+metadata:
+  name: my-gateway
+spec:
+  addresses:
+  - type: IPAddress
+    value: 1.1.1.1
+  gatewayClassName: example
+  listeners:
+  - name: default
+    port: 80
+    protocol: HTTP
+```
+
+This would generate a `Service` with `clusterIP` or `loadBalancerIP`, depending on the Service type.
+
+
+#### Labels and Annotations
+
+Labels and annotations for generated resources are specified in `infrastructure`:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: Gateway
+metadata:
+  name: my-gateway
+spec:
+  infrastructure:
+    labels:
+      foo: bar
+    annotations:
+      name: my-annotation
+```
+
+These are both `map[string]string` types, just like in `ObjectMeta`.
+
+Any labels or annotations here are added to all generated resources.
+Note this may mean an annotation intended for a `Service` may end up on a `Deployment` (for example).
+This is typically not a concern; however, if an implementation is aware of specific meanings of certain labels or annotations, they MAY
+exclude these from irrelevant resources.
+
+This is intended to clearly identify resources associated with a specific application, environment, or Gateway.
+Additionally, it can be used support integration with the kitchen-sync of Kubernetes extensions which rely on labels and annotations.
+
+Validation will be added to prevent any usage with `gateway.networking.k8s.io/` prefix, to avoid conflicts with `gateway.networking.k8s.io/gateway-name` or other future additions.
+
+#### Arbitrary Customization
+
+GEP-1867 introduces a new `infrastructure` field, which allows customization of some common configurations (version, size, etc)
+and allows a per-Gateway generic `parametersRef`.
+This can be utilized for the remainder of customizations.
+
+### Resource Attachment
+
+Resources Generated in response to the `Gateway` will have two attributes:
+
+* A `gateway.networking.k8s.io/gateway-name: <NAME>` label.
+* A name `<NAME>-<GATEWAY CLASS>`. This format is not strictly required for implementations, but strongly recommended for consistency in attachment.
+
+The generated resources MUST be in the same namespaces as the `Gateway`.
+
+Implementations MAY set `ownerReferences` to the `Gateway` in most cases, as well, but this is not required
+as some implementations may have different cleanup mechanisms.
+
+The `gateway.networking.k8s.io/gateway-name` label and standardize resource naming format can be relied on to attach resources to.
+While "Policy attachment" in Gateway API would use attachment to the actual `Gateway` resource itself,
+many existing resources attach only to resources like `Deployment` or `Service`.
+
+An example using these:
+```yaml
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: Gateway
+metadata:
+  name: gateway
+spec:
+  gatewayClassName: example
+  listeners:
+  - name: default
+    hostname: "example.com"
+    port: 80
+    protocol: HTTP
+---
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+  name: gateway
+spec:
+  # Match the generated Deployment by reference
+  # Note: Do not use `kind: Gateway`.
+  scaleTargetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: gateway-example
+  minReplicas: 2
+  maxReplicas: 5
+  metrics:
+  - type: Resource
+    resource:
+      name: cpu
+      target:
+        type: Utilization
+        averageUtilization: 50
+---
+apiVersion: policy/v1
+kind: PodDisruptionBudget
+metadata:
+  name: gateway
+spec:
+  minAvailable: 1
+  selector:
+    # Match the generated Deployment by label
+    matchLabels:
+      gateway.networking.k8s.io/metadata.name: gateway
+```
+
+Note: there is [discussion](https://github.com/kubernetes-sigs/gateway-api/discussions/1355) around a way to attach a HPA to a Gateway directly.
+
+## API
+
+This GEP extends the `infrastructure` API introduced in [GEP-1867](https://gateway-api.sigs.k8s.io/geps/gep-1867).
+
+```go
+type GatewayInfrastructure struct {
+	// Labels that should be applied to any resources created in response to this Gateway.
+	//
+	// For implementations creating other Kubernetes objects, this should be the `metadata.labels` field on resources.
+	// For other implementations, this refers to any relevant (implementation specific) "labels" concepts.
+	//
+	// An implementation may chose to add additional implementation-specific labels as they see fit.
+	//
+	// Support: Extended
+	// +kubebuilder:validation:MaxItems=8
+	Labels map[string]string `json:"labels,omitempty"`
+	// Annotations that should be applied to any resources created in response to this Gateway.
+	//
+	// For implementations creating other Kubernetes objects, this should be the `metadata.annotations` field on resources.
+	// For other implementations, this refers to any relevant (implementation specific) "annotations" concepts.
+	//
+	// An implementation may chose to add additional implementation-specific annotations as they see fit.
+	//
+	// Support: Extended
+	// +kubebuilder:validation:MaxItems=8
+	Annotations map[string]string `json:"annotations,omitempty"`
+	...
+}
+```
+
+## Future Work
+
+* Allow various policies, [such as HPA](https://github.com/kubernetes-sigs/gateway-api/discussions/1355), to attach directly to `Gateway` rather than just `Deployment`.
diff --git a/geps/gep-1897.md b/geps/gep-1897.md
index bfb3e30d..4241ad10 100644
--- a/geps/gep-1897.md
+++ b/geps/gep-1897.md
@@ -354,7 +354,8 @@ const (
     StandardCertSystem StandardCertType = "System"
 )
 
-// ConfigMapObjectReference identifies a named config map.
+// ConfigMapObjectReference identifies an API object including its namespace,
+// defaulting to ConfigMap.
 //
 // The API object must be valid in the cluster; the Group and Kind must
 // be registered in the cluster for this reference to be valid.
@@ -380,7 +381,7 @@ type ConfigMapObjectReference struct {
     // +kubebuilder:validation:Required
     Name ObjectName `json"name"`
 
-    // Namespace is the namespace of the config map. When unspecified, the local
+    // Namespace is the namespace of the referenced object. When unspecified, the local
     // namespace is inferred.
     //
     // Note that when a namespace different than the local namespace is specified,
diff --git a/geps/gep-1911.md b/geps/gep-1911.md
new file mode 100644
index 00000000..817b376b
--- /dev/null
+++ b/geps/gep-1911.md
@@ -0,0 +1,183 @@
+# GEP-1911: Backend Protocol Selection
+
+* Issue: [#1911](https://github.com/kubernetes-sigs/gateway-api/issues/1911)
+* Status: Provisional
+
+(See status definitions [here](overview.md#status).)
+
+## TLDR
+
+Not all implementations support automatic protocol selection. Even in some cases protocols are disabled without an explicit opt-in (eg. websockets with Contour & NGINX). Thus application developers need the ability to specify the protocol(s) that their application supports.
+
+## Goals
+
+- Support protocols that can have a Gateway `*Route` resource as a frontend
+- Standardize Gateway API implementations on the protocols & constants defined by the Kubernetes [Standard Application Protocols (KEP-3726)][kep-3726]
+- Support backends with multiple protocols on the same port (ie. tcp/udp)
+
+## Non-Goals
+
+- Backend TLS (covered in [GEP-1897](https://github.com/kubernetes-sigs/gateway-api/issues/1897))
+- Additional protocol specific configuration
+- Disabling Protocols
+
+## Introduction
+
+Since Kubernetes 1.20 the [`core/v1.Service`][k8s-service] and [`core/v1.EndpointSlice`][k8s-endpointslices] resource has a stable `appProtocol` field. It's purpose is to allow end-users to specify an application protocol (L7) for each service port.
+
+Originally the use of this field in the Gateway API was rejected in [GEP-1282](geps/gep-1282#non-goals):
+> v1.Service’s appProtocol field is not fit for purpose, because it is defined as accepting values either from the IANA Service Name registry, or domain-prefixed values and we need more flexibility than that. 
+
+Since then a Kubernetes enhancement proposal was created [KEP-3726][kep-3726] to repurpose `appProtocol` to include a convention for protocols that are not IANA service names. This would involve prefixing protocol names with `kubernetes.io/*`.
+
+Note: Kubernetes will automatically create `EndpointSlices` for `Services` that have a selector. [Custom `EndpointSlices`](https://kubernetes.io/docs/concepts/services-networking/service/#custom-endpointslices) can manually be created.
+
+## API Semantics
+
+A Gateway implementation MUST recognize the Kubernetes Standard Application Protocols ([KEP-3726][kep-3726]) for specifying the protocol for a backend reference in a Gateway API `*Route` resource
+
+Thus when a `*Route` points to a Kubernetes Service resource the backend protocol for each port can be specified by
+
+- setting the `appProtocol` field on the Kubernetes `Service`
+- setting the `appProtocol` field on an `Endpoint`/`EndpointSlice` object associated with a Kubernetes `Service`
+
+At the moment there exists three defined constants:
+
+- `kubernetes.io/h2c` - HTTP/2 over cleartext as described in [RFC7540](https://www.rfc-editor.org/rfc/rfc7540)
+- `kubernetes.io/ws` - WebSocket over cleartext as described in [RFC6445](https://www.rfc-editor.org/rfc/rfc6455)
+- `kubernetes.io/wss` - WebSocket over TLS as described in [RFC6455](https://www.rfc-editor.org/rfc/rfc6455)
+
+### New Protocols & Reserved Prefix
+
+To add support for a new protocol it should first become a Kubernetes Standard Application Protocol by updating the [KEP-3726][kep-3726]. [KEP-3726][kep-3726] also states the `appProtocol` field accepts a domain-prefixed implementation specific value. Thus, if the suggested protocol is not suited to have a `kubernetes.io/*` prefix, then the Gateway API MAY support the new protocol using it's own prefix `gateway.networking.k8s.io/*`.  Please make a PR to this GEP.
+
+For example we may want to add a sentinel `appProtocol` value that prevents Gateway implementations from discovering the protocol of the application. Instead they should just refer to the Service's `protocol` field. Such a constant was rejected upstream (https://github.com/kubernetes/enhancements/pull/4106) but as an example it could be defined in a future addition to this GEP as `gateway.networking.k8s.io/no-sniff`.
+
+### Default Protocols
+
+If a Service `appProtocol` isn't specified an implementation MAY infer the backend protocol through its own means. Implementations MAY infer the protocol from the `Route` type referring to the backend Service.
+
+Absence of the `appProtocol` field does not imply the implementation should disable any features (eg. websocket upgrades).
+
+### Multiple Protocols on the Same Port
+
+Only the Kubernetes `Service` `protocol` field supports multiple protocols on the same port. See the details in [KEP-1435][kep-1435].
+
+Implementations MAY support multiplexing `TCP` and `UDP` on the same port. Otherwise implementations MUST set `ResolvedRefs` condition to `False` with the Reason `UnsupportedProtocol` with a clear message that multiplexing is not supported.
+
+Currently Kubernetes `Service` API only allows different `appProtocol` values for the same port when `protocol` fields differs. At this time there seems to be interest in changing `appProtocol` to be a list in order to faciliate this use-case.
+
+### Supporting Protocols
+
+If a Route attached to a Gateway is not able to send traffic to the backend using the specified protocol then the backend is considered invalid. Implementations MUST set `ResolvedRefs` condition to `False` with the Reason `UnsupportedProtocol`.
+
+Implementations MAY support the following combinations below:
+
+ServicePort Protocol | ServicePort AppProtocol | Route Type | Supported
+-|-|-|-
+`TCP` | `kubernetes.io/h2c` | `GRPCRoute` | Yes [1]
+`TCP` | `kubernetes.io/h2c` | `HTTPRoute` | Yes
+`TCP` | `kubernetes.io/ws`  | `HTTPRoute` | Yes
+`TCP` | `kubernetes.io/wss` | `TLSRoute`  | Yes
+
+1. GRPC works over h2c - so a GRPCRoute should be able to connect to an h2c backend
+
+Implementations MAY support the following combinations below:
+
+ServicePort Protocol | ServicePort AppProtocol | Route Type | Supported
+-|-|-|-
+ServicePort Protocol | ServicePort AppProtocol | Route Type | Supported
+`TCP`  | `kubernetes.io/wss` | `HTTPRoute` | Conditional [1]
+
+1. Only if there is a corresponding `BackendTLSPolicy` - see [GEP-1897](geps/gep-1897)
+
+## Open Questions
+
+1. TLSRoute & UDP protocol
+
+TLS over UDP seems to be a thing via QUIC/HTTP3 [ref](https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/).
+Likewise there's also [DTLS](https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security). But it's unclear if Gateway's TLSRoute
+applies to an underlying UDP protocol.
+
+2. Websockets & HTTP/2/3
+
+Should we upstream new constants for websocket over [HTTP/2](https://www.rfc-editor.org/rfc/rfc8441.html) & [HTTP/3](https://www.rfc-editor.org/rfc/rfc9220.html) ? HTTP/3 makes things more complicated since its supports UDP as the underlying protocol.
+
+## Alternatives
+
+### Single Meta-resource 
+
+The first pass of this GEP proposed a new meta-resource [GEP-713](geps/gep-713) called `BackendProtocol`.
+
+This allows end-users to specify a list of ports and a list of corresponding protocols that that single
+port supports.
+
+This was dropped in favour of supporting Kubernetes Standard Application Protocols.
+
+### Multiple Protocol Meta-resources
+
+Rather than bundle protocol details into a single resource an alternative would be to create distinct meta resources.
+ie. `HTTP2Backend`, `GPRCBackend`, `WebsocketBackend`.
+
+The advantages of this approach are:
+
+- Easy to introduce new protocols
+- Definitions/types would be simpler
+
+The disadvantages of this approach are:
+
+- N resources for N protocols need to be created to describe a single backend
+- No easy mechanic to specify priority of protocols
+
+### Adding Properties on Gateway Route Objects
+
+From [GEP-1282](geps/gep-1282#tldr):
+> some types of configuration requested by users are more about defining functionality that describes capabilities of the backend more than the route you take to get to the backend.
+
+Backend protocol is specifying capabilities. This configuration is less about routing.
+
+### Kubernetes Service - Expanding Protocol field
+
+The `protocol` field on a Kubernetes service is used to specify a L4 protocol over IP. This field isn't appropriate to describe protocols
+that operate at a higher 'application' level (eg. HTTP/GRPC etc.)
+
+### Extending Kubernetes Service
+
+This is considered untenable due to the 'the turnaround time for those changes can be years.' ([ref-1282](geps/gep-1282#non-goals))
+
+### Unstructured Data/Special Values
+
+Unstructured data refers to using labels and annotations.
+
+From [GEP-1282](geps/gep-1282#non-goals):
+> these are very sticky and hard to get rid of once you start using them.
+
+Special values refers to using special strings in existing Kubernetes Resources.
+For example Istio allows for protocol to be specified by prefixing the Kubernetes
+Service's port name with the protocol (ie. `http-`, `grpc-`). This approach is
+limiting as it doesn't allow for multiple protocols on the same port and future 
+configuration per protocol. One protocol per port may be relaxed in the future see 
+[KEP 1435][kep-1435]
+
+Additionally, annotations are not self-documenting unlike CRD fields which can display
+documentation via `kubectl explain`
+
+## References
+
+- [GitHub Discussion](https://github.com/kubernetes-sigs/gateway-api/discussions/1244)
+- GEP-1282 - Describing Backend Properties
+    - [GEP](geps/gep-1282)
+    - [Issue](https://github.com/kubernetes-sigs/gateway-api/issues/1911)
+- [GEP-713 - Metaresources](geps/gep-713)
+- [Linkerd Protocol Detection](https://linkerd.io/2.12/features/protocol-detection/)
+- [Istio Protocol Selection](https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/)
+- Contour Protocol Selection
+    - [Websockets](https://projectcontour.io/docs/1.24/config/websockets/)
+    - [GRPC](https://projectcontour.io/docs/1.24/guides/grpc/#httpproxy-configuration)
+- [AWS Gateway Protocol Selection](https://github.com/aws/aws-application-networking-k8s/blob/a277fb39449383f53cd7d1e5576b4fa190a1a853/config/crds/bases/application-networking.k8s.aws_targetgrouppolicies.yaml#L109)
+- [Google GKE AppProtocol Selection](https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#https_tls_between_load_balancer_and_your_application)
+
+[k8s-service]: https://kubernetes.io/docs/concepts/services-networking/service/
+[k8s-endpointslices]: https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/
+[kep-3726]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/3726-standard-application-protocols
+[kep-1435]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/1435-mixed-protocol-lb
diff --git a/mkdocs.yml b/mkdocs.yml
index 4c06a177..3e2cbc0c 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -94,6 +94,7 @@ nav:
         - geps/gep-1619.md
         - geps/gep-1867.md
         - geps/gep-1897.md
+        - geps/gep-1911.md
         - geps/gep-2162.md
       # - Implementable:
       #   -
diff --git a/pkg/generator/main.go b/pkg/generator/main.go
index 977d4c4e..f60e2906 100644
--- a/pkg/generator/main.go
+++ b/pkg/generator/main.go
@@ -207,6 +207,21 @@ func gatewayTweaks(channel string, props map[string]apiext.JSONSchemaProps) map[
 				})
 			}
 		}
+		startTag := "<gateway:experimental:description>"
+		endTag := "</gateway:experimental:description>"
+		regexPattern := startTag + `(?s:(.*?))` + endTag
+		if channel == "standard" && strings.Contains(jsonProps.Description, "<gateway:experimental:description>") {
+			re := regexp.MustCompile(regexPattern)
+			match := re.FindStringSubmatch(jsonProps.Description)
+			if len(match) != 2 {
+				log.Fatalf("Invalid <gateway:experimental:description> tag for %s", name)
+			}
+			modifiedDescription := re.ReplaceAllString(jsonProps.Description, "")
+			jsonProps.Description = modifiedDescription
+		} else {
+			jsonProps.Description = strings.ReplaceAll(jsonProps.Description, startTag, "")
+			jsonProps.Description = strings.ReplaceAll(jsonProps.Description, endTag, "")
+		}
 
 		if numValid < numExpressions {
 			fmt.Printf("Description: %s\n", jsonProps.Description)
diff --git a/requirements.txt b/requirements.txt
index 1522fd7b..44ffdde7 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7,11 +7,11 @@ livereload==2.6.3
 # https://github.com/kubernetes-sigs/gateway-api/pull/1671#issuecomment-1400586465
 Markdown==3.3.7
 MarkupSafe==2.1.3
-mkdocs==1.5.2
+mkdocs==1.5.3
 mkdocs-awesome-pages-plugin==2.9.2
 mkdocs-macros-plugin==1.0.4
-mkdocs-material==9.3.1
-mkdocs-material-extensions==1.1.1
+mkdocs-material==9.4.2
+mkdocs-material-extensions==1.2
 mkdocs-redirects==1.2.1
 mkdocs-mermaid2-plugin==1.1.0
 pep562==1.1
diff --git a/site-src/implementations.md b/site-src/implementations.md
index 9cca9387..1a875370 100644
--- a/site-src/implementations.md
+++ b/site-src/implementations.md
@@ -24,7 +24,7 @@ Implementors and integrators of Gateway API are encouraged to update this docume
 - [Kong][10] (beta)
 - [Kuma][11] (beta)
 - [LiteSpeed Ingress Controller][19]
-- [NGINX Kubernetes Gateway][12]
+- [NGINX Gateway Fabric][12]
 - [STUNner][21] (beta)
 - [Traefik][13] (alpha)
 - [Tyk][29] (work in progress)
@@ -55,7 +55,7 @@ Implementors and integrators of Gateway API are encouraged to update this docume
 [9]:#istio
 [10]:#kong
 [11]:#kuma
-[12]:#nginx-kubernetes-gateway
+[12]:#nginx-gateway-fabric
 [13]:#traefik
 [14]:#flagger
 [15]:#cert-manager
@@ -281,7 +281,7 @@ Check out the [Gateway API task][istio-2] for more information about the Gateway
 
 ### Kong
 
-[![Conformance](https://img.shields.io/badge/Gateway%20API%20Conformance%20v0.7.1-Kong%20Ingress%20Controller-green)](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/reports/v0.7.1/kong-kubernetes-ingress-controller.yaml)
+[![Conformance](https://img.shields.io/badge/Gateway%20API%20Conformance%20v0.8.1-Kong%20Ingress%20Controller-green)](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/reports/v0.8.1/kong-kubernetes-ingress-controller.yaml)
 
 [Kong][kong] is an open source API Gateway built for hybrid and multi-cloud environments.
 
@@ -294,7 +294,7 @@ For help and support with Kong's implementations please feel free to [create an
 [kong]:https://konghq.com
 [kic]:https://github.com/kong/kubernetes-ingress-controller
 [kong-gw-guide]:https://docs.konghq.com/kubernetes-ingress-controller/latest/guides/using-gateway-api/
-[kgo]:https://github.com/kong/gateway-operator-docs
+[kgo]:https://docs.konghq.com/gateway-operator/latest/
 [kong-issue-new]:https://github.com/Kong/kubernetes-ingress-controller/issues/new
 [kong-disc-new]:https://github.com/Kong/kubernetes-ingress-controller/discussions/new
 [kong-slack]:https://kubernetes.slack.com/archives/CDCA87FRD
@@ -334,19 +334,19 @@ The [LiteSpeed Ingress Controller](https://litespeedtech.com/products/litespeed-
 - [Gateway specific documentation](https://docs.litespeedtech.com/cloud/kubernetes/gateway).
 - Full support is available on the [LiteSpeed support web site](https://www.litespeedtech.com/support).
 
-### NGINX Kubernetes Gateway
+### NGINX Gateway Fabric
 
-[![Conformance](https://img.shields.io/badge/Gateway%20API%20Conformance%20v0.8.0-NGINX Kubernetes Gateway-green)](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/reports/v0.8.0/nginxinc-nginx-kubernetes-gateway.yaml)
+[![Conformance](https://img.shields.io/badge/Gateway%20API%20Conformance%20v0.8.0-NGINX Gateway Fabric-green)](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/reports/v0.8.0/nginxinc-nginx-gateway-fabric.yaml)
 
-[NGINX Kubernetes Gateway][nginx-kubernetes-gateway] is an open-source project that provides an implementation of the Gateway API using [NGINX][nginx] as the data plane. The goal of this project is to implement the core Gateway API -- Gateway, GatewayClass, HTTPRoute, TCPRoute, TLSRoute, and UDPRoute -- to configure an HTTP or TCP/UDP load balancer, reverse-proxy, or API gateway for applications running on Kubernetes. NGINX Kubernetes Gateway is currently under development and supports a subset of the Gateway API.
+[NGINX Gateway Fabric][nginx-gateway-fabric] is an open-source project that provides an implementation of the Gateway API using [NGINX][nginx] as the data plane. The goal of this project is to implement the core Gateway API -- Gateway, GatewayClass, HTTPRoute, TCPRoute, TLSRoute, and UDPRoute -- to configure an HTTP or TCP/UDP load balancer, reverse-proxy, or API gateway for applications running on Kubernetes. NGINX Gateway Fabric is currently under development and supports a subset of the Gateway API.
 
-If you have any suggestions or experience issues with NGINX Kubernetes Gateway, please [create an issue][nginx-issue-new] or a [discussion][nginx-disc-new] on GitHub. You can also ask for help in the [#nginx-kubernetes-gateway channel on NGINX slack][nginx-slack].
+If you have any suggestions or experience issues with NGINX Gateway Fabric, please [create an issue][nginx-issue-new] or a [discussion][nginx-disc-new] on GitHub. You can also ask for help in the [#nginx-gateway-fabric channel on NGINX slack][nginx-slack].
 
-[nginx-kubernetes-gateway]:https://github.com/nginxinc/nginx-kubernetes-gateway
+[nginx-gateway-fabric]:https://github.com/nginxinc/nginx-gateway-fabric
 [nginx]:https://nginx.org/
-[nginx-issue-new]:https://github.com/nginxinc/nginx-kubernetes-gateway/issues/new
-[nginx-disc-new]:https://github.com/nginxinc/nginx-kubernetes-gateway/discussions/new
-[nginx-slack]:https://nginxcommunity.slack.com/channels/nginx-kubernetes-gateway
+[nginx-issue-new]:https://github.com/nginxinc/nginx-gateway-fabric/issues/new
+[nginx-disc-new]:https://github.com/nginxinc/nginx-gateway-fabric/discussions/new
+[nginx-slack]:https://nginxcommunity.slack.com/channels/nginx-gateway-fabric
 
 ### STUNner
 



Test patch:
diff --git a/conformance/tests/gateway-modify-listeners.go b/conformance/tests/gateway-modify-listeners.go
index fffed977..777c7798 100644
--- a/conformance/tests/gateway-modify-listeners.go
+++ b/conformance/tests/gateway-modify-listeners.go
@@ -87,11 +87,18 @@ var GatewayModifyListeners = suite.ConformanceTest{
 						Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 						Kind:  v1beta1.Kind("HTTPRoute"),
 					}},
-					Conditions: []metav1.Condition{{
-						Type:   string(v1beta1.ListenerConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: "", // any reason
-					}},
+					Conditions: []metav1.Condition{
+						{
+							Type:   string(v1beta1.ListenerConditionAccepted),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+						{
+							Type:   string(v1beta1.ListenerConditionResolvedRefs),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+					},
 					AttachedRoutes: 1,
 				},
 				{
@@ -100,11 +107,18 @@ var GatewayModifyListeners = suite.ConformanceTest{
 						Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 						Kind:  v1beta1.Kind("HTTPRoute"),
 					}},
-					Conditions: []metav1.Condition{{
-						Type:   string(v1beta1.ListenerConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: "", // any reason
-					}},
+					Conditions: []metav1.Condition{
+						{
+							Type:   string(v1beta1.ListenerConditionAccepted),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+						{
+							Type:   string(v1beta1.ListenerConditionResolvedRefs),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+					},
 					AttachedRoutes: 1,
 				},
 			}
@@ -161,11 +175,18 @@ var GatewayModifyListeners = suite.ConformanceTest{
 						Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 						Kind:  v1beta1.Kind("HTTPRoute"),
 					}},
-					Conditions: []metav1.Condition{{
-						Type:   string(v1beta1.ListenerConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: "", // any reason
-					}},
+					Conditions: []metav1.Condition{
+						{
+							Type:   string(v1beta1.ListenerConditionAccepted),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+						{
+							Type:   string(v1beta1.ListenerConditionResolvedRefs),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+					},
 					AttachedRoutes: 1,
 				},
 			}
diff --git a/conformance/tests/gateway-secret-reference-grant-all-in-namespace.go b/conformance/tests/gateway-secret-reference-grant-all-in-namespace.go
index 1fb5fed8..f9ed96e6 100644
--- a/conformance/tests/gateway-secret-reference-grant-all-in-namespace.go
+++ b/conformance/tests/gateway-secret-reference-grant-all-in-namespace.go
@@ -55,6 +55,11 @@ var GatewaySecretReferenceGrantAllInNamespace = suite.ConformanceTest{
 						Status: metav1.ConditionTrue,
 						Reason: string(v1beta1.ListenerReasonProgrammed),
 					},
+					{
+						Type:   string(v1beta1.ListenerConditionResolvedRefs),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
 				},
 				AttachedRoutes: 0,
 			}}
diff --git a/conformance/tests/gateway-secret-reference-grant-specific.go b/conformance/tests/gateway-secret-reference-grant-specific.go
index 6d9c092f..ae883d30 100644
--- a/conformance/tests/gateway-secret-reference-grant-specific.go
+++ b/conformance/tests/gateway-secret-reference-grant-specific.go
@@ -55,6 +55,11 @@ var GatewaySecretReferenceGrantSpecific = suite.ConformanceTest{
 						Status: metav1.ConditionTrue,
 						Reason: string(v1beta1.ListenerReasonProgrammed),
 					},
+					{
+						Type:   string(v1beta1.ListenerConditionResolvedRefs),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
 				},
 				AttachedRoutes: 0,
 			}}
diff --git a/conformance/tests/gateway-with-attached-routes.go b/conformance/tests/gateway-with-attached-routes.go
index b33040ad..53b5659c 100644
--- a/conformance/tests/gateway-with-attached-routes.go
+++ b/conformance/tests/gateway-with-attached-routes.go
@@ -47,11 +47,18 @@ var GatewayWithAttachedRoutes = suite.ConformanceTest{
 					Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 					Kind:  v1beta1.Kind("HTTPRoute"),
 				}},
-				Conditions: []metav1.Condition{{
-					Type:   string(v1beta1.ListenerConditionAccepted),
-					Status: metav1.ConditionTrue,
-					Reason: "", // any reason
-				}},
+				Conditions: []metav1.Condition{
+					{
+						Type:   string(v1beta1.ListenerConditionAccepted),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
+					{
+						Type:   string(v1beta1.ListenerConditionResolvedRefs),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
+				},
 				AttachedRoutes: 1,
 			}}
 
@@ -66,11 +73,18 @@ var GatewayWithAttachedRoutes = suite.ConformanceTest{
 					Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 					Kind:  v1beta1.Kind("HTTPRoute"),
 				}},
-				Conditions: []metav1.Condition{{
-					Type:   string(v1beta1.ListenerConditionAccepted),
-					Status: metav1.ConditionTrue,
-					Reason: "", // any reason
-				}},
+				Conditions: []metav1.Condition{
+					{
+						Type:   string(v1beta1.ListenerConditionAccepted),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
+					{
+						Type:   string(v1beta1.ListenerConditionResolvedRefs),
+						Status: metav1.ConditionTrue,
+						Reason: "", // any reason
+					},
+				},
 				AttachedRoutes: 2,
 			}}
 
@@ -97,11 +111,18 @@ var GatewayWithAttachedRoutesWithPort8080 = suite.ConformanceTest{
 						Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 						Kind:  v1beta1.Kind("HTTPRoute"),
 					}},
-					Conditions: []metav1.Condition{{
-						Type:   string(v1beta1.ListenerConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: "", // any reason
-					}},
+					Conditions: []metav1.Condition{
+						{
+							Type:   string(v1beta1.ListenerConditionAccepted),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+						{
+							Type:   string(v1beta1.ListenerConditionResolvedRefs),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+					},
 					AttachedRoutes: 0,
 				},
 				{
@@ -110,11 +131,18 @@ var GatewayWithAttachedRoutesWithPort8080 = suite.ConformanceTest{
 						Group: (*v1beta1.Group)(&v1beta1.GroupVersion.Group),
 						Kind:  v1beta1.Kind("HTTPRoute"),
 					}},
-					Conditions: []metav1.Condition{{
-						Type:   string(v1beta1.ListenerConditionAccepted),
-						Status: metav1.ConditionTrue,
-						Reason: "", // any reason
-					}},
+					Conditions: []metav1.Condition{
+						{
+							Type:   string(v1beta1.ListenerConditionAccepted),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+						{
+							Type:   string(v1beta1.ListenerConditionResolvedRefs),
+							Status: metav1.ConditionTrue,
+							Reason: "", // any reason
+						},
+					},
 					AttachedRoutes: 1,
 				},
 			}
diff --git a/conformance/tests/httproute-request-multiple-mirrors.go b/conformance/tests/httproute-request-multiple-mirrors.go
index 40b05a3f..3421ca8a 100644
--- a/conformance/tests/httproute-request-multiple-mirrors.go
+++ b/conformance/tests/httproute-request-multiple-mirrors.go
@@ -49,11 +49,11 @@ var HTTPRouteRequestMultipleMirrors = suite.ConformanceTest{
 		testCases := []http.ExpectedResponse{
 			{
 				Request: http.Request{
-					Path: "/mirror",
+					Path: "/multi-mirror",
 				},
 				ExpectedRequest: &http.ExpectedRequest{
 					Request: http.Request{
-						Path: "/mirror",
+						Path: "/multi-mirror",
 					},
 				},
 				Backend: "infra-backend-v1",
@@ -70,7 +70,7 @@ var HTTPRouteRequestMultipleMirrors = suite.ConformanceTest{
 				Namespace: ns,
 			}, {
 				Request: http.Request{
-					Path: "/mirror-and-modify-request-headers",
+					Path: "/multi-mirror-and-modify-request-headers",
 					Headers: map[string]string{
 						"X-Header-Remove":     "remove-val",
 						"X-Header-Add-Append": "append-val-1",
@@ -78,7 +78,7 @@ var HTTPRouteRequestMultipleMirrors = suite.ConformanceTest{
 				},
 				ExpectedRequest: &http.ExpectedRequest{
 					Request: http.Request{
-						Path: "/mirror-and-modify-request-headers",
+						Path: "/multi-mirror-and-modify-request-headers",
 						Headers: map[string]string{
 							"X-Header-Add":        "header-val-1",
 							"X-Header-Add-Append": "append-val-1,header-val-2",
diff --git a/conformance/tests/httproute-request-multiple-mirrors.yaml b/conformance/tests/httproute-request-multiple-mirrors.yaml
index 0bab57e9..bf2d13b3 100644
--- a/conformance/tests/httproute-request-multiple-mirrors.yaml
+++ b/conformance/tests/httproute-request-multiple-mirrors.yaml
@@ -10,7 +10,7 @@ spec:
   - matches:
     - path:
         type: PathPrefix
-        value: /mirror
+        value: /multi-mirror
     filters:
     - type: RequestMirror
       requestMirror:
@@ -31,7 +31,7 @@ spec:
   - matches:
     - path:
         type: PathPrefix
-        value: /mirror-and-modify-request-headers
+        value: /multi-mirror-and-modify-request-headers
     filters:
     - type: RequestHeaderModifier
       requestHeaderModifier: