From 674897720b435fb2121a8538d85e64fb51f55538 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Wed, 2 Jul 2025 18:46:57 -0700
Subject: [PATCH 01/21] Updated index doc and corrected formatting.

---
 geps/gep-2162/index.md | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index a8959acc8e..ed4c3c567f 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -1,11 +1,11 @@
 # GEP-2162: Supported features in GatewayClass Status
 
 * Issue: [#2162](https://github.com/kubernetes-sigs/gateway-api/issues/2162)
-* Status: Experimental
+* Status: Standard
 
 ## TLDR
 
-This GEP proposes to enhance the [GatewayClassStatus](https://github.com/kubernetes-sigs/gateway-api/blob/f2cd9bb92b4ff392416c40d6148ff7f76b30e649/apis/v1beta1/gatewayclass_types.go#L185) to include a list of Gateway API features supported by the installed GatewayClass. 
+This GEP proposes to enhance the [GatewayClassStatus](https://github.com/kubernetes-sigs/gateway-api/blob/f2cd9bb92b4ff392416c40d6148ff7f76b30e649/apis/v1beta1/gatewayclass_types.go#L185) to include a list of Gateway API features supported by the installed GatewayClass.
 
 ## Goals
 
@@ -17,15 +17,14 @@ This GEP proposes to enhance the [GatewayClassStatus](https://github.com/kuberne
 
 * Provide foundation for tools to block or warn when unsupported features are used.
 
-
 ## Non-Goals
 
 * Validate correctness of supported features published by the implementation.
     Meaning we don't intend to verify whether the supported features reported by
     the implementation are indeed supported.
 
-    However, the supported features in the status of the GatewayClass should
-    make it very easy for any individual to run conformance tests against the
+    However, the supported features in the status of the `GatewayClass should
+    make it easy for any individual to run conformance tests against the
     GatewayClass using our conformance tooling.
 
 ## Introduction
@@ -45,7 +44,7 @@ Implementations **must** publish the supported features before Accepting the Gat
 
 Implementations are free to decide how they manage this information. A common approach could be to maintain static lists of supported features or using predefined sets.
 
-Note: implementations must keep the published list sorted in ascending alphabetical order.
+> Note: implementations must keep the published list sorted in ascending alphabetical order.
 
 ## API
 
@@ -53,7 +52,6 @@ This GEP proposes API changes describes as follow:
 
 * Update the `GatewayClassStatus` struct to include a string-represented list of `SupportedFeatures`.
 
-
 ```go
 // GatewayClassStatus is the current status for the GatewayClass.
 type GatewayClassStatus struct {
@@ -106,6 +104,7 @@ status:
     - HTTPRouteQueryParamMatching
 
 ```
+
 ## Standardize features and conformance tests names
 
 Before we add the supported features into our API, it is necessary to establish standardized naming and formatting conventions.
@@ -130,6 +129,12 @@ We should treat this guidance as "best effort" because we might have test files
 
 In any case, the conformance tests file names should be meaningful and easy to understand.
 
+#### Conformance report
+
+In order for to verify that the list of features reported are indeed supported
+by GatewayClass tests will be run based on the inferred features from the
+GatewayClassStatus. If the source of features are not inferred (manually
+provided, or undefined) this will block report from being generating.
 
 ## Followups
 
@@ -137,14 +142,13 @@ Before we make the changes we need to;
 
 1. Change the names of the supported features and conformance tests that don't conform with the formatting rules.
 
-
 ## Alternatives
 
 ### Re-using ConformanceProfiles structs
 
 We could use the same structs as we do in conformance profile object, more specifically, the [ProfileReport](https://github.com/kubernetes-sigs/gateway-api/blob/main/conformance/apis/v1alpha1/profilereport.go#LL24C6-L24C19) struct.
 
-Though it would be nice to have only one place to update, these structs seems to include much more data relevant to the conformance report but not for our use case. 
+Though it would be nice to have only one place to update, these structs seems to include much more data relevant to the conformance report but not for our use case.
 
 That said, conformance profiles are still at experimental stage, we could explore the option to create a shared struct that will be used both for the conformance reports and for the GatewayClass status.
 
@@ -158,8 +162,7 @@ However, having the supported features published in the GatewayClass Status adds
 * We could build a mechanism or a tool to block or warn when unsupported features are used.
 * Users will be able to select the GatewayClass that suits their needs without having to refer to documentation or conformance reports.
 
-This does not cover a future piece of work we want to implement which is to warn/block users from applying a Gateway API object if the installed GWC doesn't support it. (originally suggested in [#1804](https://github.com/kubernetes-sigs/gateway-api/issues/1804)). 
-
+This does not cover a future piece of work we want to implement which is to warn/block users from applying a Gateway API object if the installed GWC doesn't support it. (originally suggested in [#1804](https://github.com/kubernetes-sigs/gateway-api/issues/1804)).
 
 ## References
 
@@ -169,6 +172,7 @@ This does not cover a future piece of work we want to implement which is to warn
 ## Future Work
 
 ### Research the development of an unsupported feature warning/blocking mechanism
+
 Once the GatewayClass features support are is published into the status we could look into;
 
 1. Using the supported features in the webhook to validate or block attempts to apply manifests with unsupported features.
@@ -181,7 +185,7 @@ Once the GatewayClass features support are is published into the status we could
 
 We got some feedback that it will be useful to indicate which Gateway API version the implementation supports. So when we have supported features published in the GatewayClass Status, users will also be able to understand that those are the supported features for a specific Gateway API version.
 
-This work is likely to require its own small GEP but ideally what this field would mean is that an implementation supports Max(vX.X). 
+This work is likely to require its own small GEP but ideally what this field would mean is that an implementation supports Max(vX.X).
 
 The value of it is to provide a better user experience and also more foundation for tools to be able to warn for example when a GatewayClass and CRDs have mismatched versions.
 

From a099c800ff6f1d2f54455dabe5ebf7dea3faaa44 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Mon, 7 Jul 2025 10:38:53 -0700
Subject: [PATCH 02/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index ed4c3c567f..6e76ed635f 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -134,7 +134,7 @@ In any case, the conformance tests file names should be meaningful and easy to u
 In order for to verify that the list of features reported are indeed supported
 by GatewayClass tests will be run based on the inferred features from the
 GatewayClassStatus. If the source of features are not inferred (manually
-provided, or undefined) this will block report from being generating.
+provided, or undefined) the conformance suite will block the report from being submitted.
 
 ## Followups
 

From 37a908af0c289e9d78b8617b568c57b997539cc0 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Mon, 7 Jul 2025 20:19:33 -0700
Subject: [PATCH 03/21] Added details about Mesh and staying compliant.

---
 geps/gep-2162/index.md | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 6e76ed635f..282f87aa3c 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -136,6 +136,30 @@ by GatewayClass tests will be run based on the inferred features from the
 GatewayClassStatus. If the source of features are not inferred (manually
 provided, or undefined) the conformance suite will block the report from being submitted.
 
+#### Reporting Mesh features
+
+As Mesh doesn't have functionality (yet) to populate SupportedFeatures in the
+Status, they can be tested for compliance by using Conformance Profiles, or
+manually providing features for test using `--supported-features` flag.
+Conformance suite will determine if the implementation doesn't support
+GatewayClass and validate that report is run for the Mesh features and NOT block
+the report.
+
+#### Staying Compliant
+
+SupportedFeatures will become available starting 1.4 release as a standard
+feature, which means that all implementors will be expected to define and
+populate SupportedFeatures in the GatewayClass' Status. Conformance test suite
+will be based on inferring supported features from GatewayClassStatus, meaning
+if you want to generate passing report, above mentioned feature should be
+implemented.
+
+Grace period is till 1.5 release. After that, we'll flip flag for
+Conformance tests that will block all the reports for implementations that do
+not populate SupportedFeatures in GatewayClassStatus. So, if you want your
+implementation to remain compliant, SupportedFeatures should be implemented
+before 1.5 release.
+
 ## Followups
 
 Before we make the changes we need to;

From 14664635c034754358848d435c301b1d608f924e Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Mon, 7 Jul 2025 20:24:35 -0700
Subject: [PATCH 04/21] Wording update.

---
 geps/gep-2162/index.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 282f87aa3c..5a157e6464 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -139,8 +139,8 @@ provided, or undefined) the conformance suite will block the report from being s
 #### Reporting Mesh features
 
 As Mesh doesn't have functionality (yet) to populate SupportedFeatures in the
-Status, they can be tested for compliance by using Conformance Profiles, or
-manually providing features for test using `--supported-features` flag.
+Status, its features can be tested for compliance by using Conformance Profiles,
+or manually, providing features for test using `--supported-features` flag.
 Conformance suite will determine if the implementation doesn't support
 GatewayClass and validate that report is run for the Mesh features and NOT block
 the report.

From 31d0ce29f37ab033095d53f6ccd4e4b2e7d525a5 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Mon, 7 Jul 2025 20:33:31 -0700
Subject: [PATCH 05/21] TODO for what GWC reports.

---
 geps/gep-2162/index.md | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 5a157e6464..02434c9e74 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -105,6 +105,11 @@ status:
 
 ```
 
+### SupportedFeatures Guidance in GatewayClass
+
+TODO(bexxmodd@): Guidance regarding what features should be published under
+SupportedFeatures in GatewayClass (only gateway features - option 1 from #3885)
+
 ## Standardize features and conformance tests names
 
 Before we add the supported features into our API, it is necessary to establish standardized naming and formatting conventions.

From f2139e85c9a1a5a795afaa640b0435db9c6a444c Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Mon, 7 Jul 2025 20:51:07 -0700
Subject: [PATCH 06/21] Added mesh stuff.

---
 geps/gep-2162/index.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 02434c9e74..70b0c84aa7 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -107,8 +107,9 @@ status:
 
 ### SupportedFeatures Guidance in GatewayClass
 
-TODO(bexxmodd@): Guidance regarding what features should be published under
-SupportedFeatures in GatewayClass (only gateway features - option 1 from #3885)
+GatewayClassStatus should only populated Gateway related features. The rest,
+e.i Mesh features should be populated when Mesh resource gets introduced.
+Please see *Reporting Mesh Features* section for conformance reporting.
 
 ## Standardize features and conformance tests names
 

From 79a3c73b1d2dae84b0af3b39b4e768d1f885b391 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Tue, 8 Jul 2025 09:33:18 -0700
Subject: [PATCH 07/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 70b0c84aa7..d52f0e4619 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -107,9 +107,8 @@ status:
 
 ### SupportedFeatures Guidance in GatewayClass
 
-GatewayClassStatus should only populated Gateway related features. The rest,
-e.i Mesh features should be populated when Mesh resource gets introduced.
-Please see *Reporting Mesh Features* section for conformance reporting.
+Only Gateway related features should be published on GatewayClass. The rest,
+i.e Mesh features should not be published on Gateway Class, and will likely to be published on a Mesh resource if an when it is introduced (xRef: https://github.com/kubernetes-sigs/gateway-api/pull/3887).
 
 ## Standardize features and conformance tests names
 

From dde670e368280745b6243bb81795a9ea87b7b511 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Tue, 8 Jul 2025 09:33:26 -0700
Subject: [PATCH 08/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index d52f0e4619..7d6dc342e3 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -137,7 +137,7 @@ In any case, the conformance tests file names should be meaningful and easy to u
 #### Conformance report
 
 In order for to verify that the list of features reported are indeed supported
-by GatewayClass tests will be run based on the inferred features from the
+by GatewayClass tests will be run based on the features from the
 GatewayClassStatus. If the source of features are not inferred (manually
 provided, or undefined) the conformance suite will block the report from being submitted.
 

From 04acd2d70ee4969b66c5ae313656050b80c302be Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Tue, 8 Jul 2025 09:33:34 -0700
Subject: [PATCH 09/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 7d6dc342e3..ad86d6d7bd 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -139,7 +139,7 @@ In any case, the conformance tests file names should be meaningful and easy to u
 In order for to verify that the list of features reported are indeed supported
 by GatewayClass tests will be run based on the features from the
 GatewayClassStatus. If the source of features are not inferred (manually
-provided, or undefined) the conformance suite will block the report from being submitted.
+provided) the conformance suite will block the report from being submitted.
 
 #### Reporting Mesh features
 

From 58686e1c97a1c981cb749aafcdc6e35d68cf8408 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Tue, 8 Jul 2025 09:33:49 -0700
Subject: [PATCH 10/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index ad86d6d7bd..c31fdaf0eb 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -161,9 +161,7 @@ implemented.
 
 Grace period is till 1.5 release. After that, we'll flip flag for
 Conformance tests that will block all the reports for implementations that do
-not populate SupportedFeatures in GatewayClassStatus. So, if you want your
-implementation to remain compliant, SupportedFeatures should be implemented
-before 1.5 release.
+not use SupportedFeatures in their GatewayClassStatus as a source of truth for their tests.
 
 ## Followups
 

From b7390778356ff9f1409277518bb66bed70ad89de Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Tue, 8 Jul 2025 09:34:07 -0700
Subject: [PATCH 11/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index c31fdaf0eb..ad84d17020 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -143,8 +143,7 @@ provided) the conformance suite will block the report from being submitted.
 
 #### Reporting Mesh features
 
-As Mesh doesn't have functionality (yet) to populate SupportedFeatures in the
-Status, its features can be tested for compliance by using Conformance Profiles,
+As Mesh doesn't have a good place (yet) to populate SupportedFeatures, its features can be tested for compliance by using Conformance Profiles,
 or manually, providing features for test using `--supported-features` flag.
 Conformance suite will determine if the implementation doesn't support
 GatewayClass and validate that report is run for the Mesh features and NOT block

From 663e2645240b09f33df458d699618b996e800a1f Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Tue, 8 Jul 2025 09:39:48 -0700
Subject: [PATCH 12/21] Added summary paragraph for Staying Compliant section.

---
 geps/gep-2162/index.md | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index ad84d17020..c11a10b7a9 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -156,12 +156,21 @@ feature, which means that all implementors will be expected to define and
 populate SupportedFeatures in the GatewayClass' Status. Conformance test suite
 will be based on inferring supported features from GatewayClassStatus, meaning
 if you want to generate passing report, above mentioned feature should be
-implemented.
-
-Grace period is till 1.5 release. After that, we'll flip flag for
+implemented. Grace period is till 1.5 release. After that, we'll flip flag for
 Conformance tests that will block all the reports for implementations that do
 not use SupportedFeatures in their GatewayClassStatus as a source of truth for their tests.
 
+The core purpose of conformance tests for GatewayClass is to verify that
+reported features are truly supported. While the community currently operates on
+a trust-based system for conformance reports, programmatically inferring
+features from the GatewayClass status field creates a strong, verifiable link
+between an implementation's claims and the test results. This not only provides
+crucial context in conformance reports but also encourages accurate reporting
+and helps differentiate between trustworthy and less reliable feature sources,
+making it easier to identify discrepancies. Although implementations can still
+manually create reports, the reputational cost of faking results acts as a
+significant deterrent.
+
 ## Followups
 
 Before we make the changes we need to;

From 9d86fe65bf5bc564c4b77061eea5fb7f25dd86dc Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Wed, 9 Jul 2025 13:33:01 -0700
Subject: [PATCH 13/21] Update geps/gep-2162/index.md

Co-authored-by: Rob Scott <rob.scott87@gmail.com>
---
 geps/gep-2162/index.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index c11a10b7a9..c86692f00f 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -156,9 +156,8 @@ feature, which means that all implementors will be expected to define and
 populate SupportedFeatures in the GatewayClass' Status. Conformance test suite
 will be based on inferring supported features from GatewayClassStatus, meaning
 if you want to generate passing report, above mentioned feature should be
-implemented. Grace period is till 1.5 release. After that, we'll flip flag for
-Conformance tests that will block all the reports for implementations that do
-not use SupportedFeatures in their GatewayClassStatus as a source of truth for their tests.
+implemented. There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports 
+will need to be generated based on the SupportedFeatures field in GatewayClass status.
 
 The core purpose of conformance tests for GatewayClass is to verify that
 reported features are truly supported. While the community currently operates on

From 89d974a6c0352562bb8dbb3acc2ba29fd800c2e9 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Wed, 9 Jul 2025 13:33:09 -0700
Subject: [PATCH 14/21] Update geps/gep-2162/index.md

Co-authored-by: Rob Scott <rob.scott87@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index c86692f00f..af18f22e2a 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -152,7 +152,7 @@ the report.
 #### Staying Compliant
 
 SupportedFeatures will become available starting 1.4 release as a standard
-feature, which means that all implementors will be expected to define and
+feature, which means that all Gateway implementations will be expected to define and
 populate SupportedFeatures in the GatewayClass' Status. Conformance test suite
 will be based on inferring supported features from GatewayClassStatus, meaning
 if you want to generate passing report, above mentioned feature should be

From 63f8ad75e3a677b5f974a228c6e34a6e98da8ba2 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Wed, 9 Jul 2025 13:44:05 -0700
Subject: [PATCH 15/21] Formatting changes.

---
 geps/gep-2162/index.md | 52 ++++++++++++++----------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index af18f22e2a..20779d94bc 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -20,12 +20,9 @@ This GEP proposes to enhance the [GatewayClassStatus](https://github.com/kuberne
 ## Non-Goals
 
 * Validate correctness of supported features published by the implementation.
-    Meaning we don't intend to verify whether the supported features reported by
-    the implementation are indeed supported.
+    Meaning we don't intend to verify whether the supported features reported by the implementation are indeed supported.
 
-    However, the supported features in the status of the `GatewayClass should
-    make it easy for any individual to run conformance tests against the
-    GatewayClass using our conformance tooling.
+    However, the supported features in the status of the GatewayClass should make it easy for any individual to run conformance tests against the GatewayClass using our conformance tooling.
 
 ## Introduction
 
@@ -107,8 +104,7 @@ status:
 
 ### SupportedFeatures Guidance in GatewayClass
 
-Only Gateway related features should be published on GatewayClass. The rest,
-i.e Mesh features should not be published on Gateway Class, and will likely to be published on a Mesh resource if an when it is introduced (xRef: https://github.com/kubernetes-sigs/gateway-api/pull/3887).
+Only Gateway related features should be published on GatewayClass. The rest, i.e Mesh features should not be published on Gateway Class, and will likely to be published on a Mesh resource if an when it is [introduced](https://github.com/kubernetes-sigs/gateway-api/pull/3887).
 
 ## Standardize features and conformance tests names
 
@@ -120,7 +116,7 @@ Before we add the supported features into our API, it is necessary to establish
 
 Every feature should:
 
-1. Start with the resource name. i.e HTTPRouteXXX
+1. Start with the resource name. i.e HTTPRouteXXX.
 2. Follow the PascalCase convention. Note that the resource name in the string should come as is and not be converted to PascalCase, i.e HTTPRoutePortRedirect and not HttpRoutePortRedirect.
 3. Not exceed 128 characters.
 4. Contain only letters and numbers
@@ -136,39 +132,25 @@ In any case, the conformance tests file names should be meaningful and easy to u
 
 #### Conformance report
 
-In order for to verify that the list of features reported are indeed supported
-by GatewayClass tests will be run based on the features from the
-GatewayClassStatus. If the source of features are not inferred (manually
-provided) the conformance suite will block the report from being submitted.
+In order for to verify that the list of features reported are indeed supported by GatewayClass tests will be run based on the features from the GatewayClassStatus.
+If the source of features are not inferred (manually provided) the conformance suite will block the report from being submitted.
 
 #### Reporting Mesh features
 
-As Mesh doesn't have a good place (yet) to populate SupportedFeatures, its features can be tested for compliance by using Conformance Profiles,
-or manually, providing features for test using `--supported-features` flag.
-Conformance suite will determine if the implementation doesn't support
-GatewayClass and validate that report is run for the Mesh features and NOT block
-the report.
+As Mesh doesn't have a good place (yet) to populate SupportedFeatures, its features can be tested for compliance by using Conformance Profiles, or manually, providing features for test using `--supported-features` flag.
+Conformance suite will determine if the implementation doesn't support GatewayClass and validate that report is run for the Mesh features and NOT block the report.
 
 #### Staying Compliant
 
-SupportedFeatures will become available starting 1.4 release as a standard
-feature, which means that all Gateway implementations will be expected to define and
-populate SupportedFeatures in the GatewayClass' Status. Conformance test suite
-will be based on inferring supported features from GatewayClassStatus, meaning
-if you want to generate passing report, above mentioned feature should be
-implemented. There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports 
-will need to be generated based on the SupportedFeatures field in GatewayClass status.
-
-The core purpose of conformance tests for GatewayClass is to verify that
-reported features are truly supported. While the community currently operates on
-a trust-based system for conformance reports, programmatically inferring
-features from the GatewayClass status field creates a strong, verifiable link
-between an implementation's claims and the test results. This not only provides
-crucial context in conformance reports but also encourages accurate reporting
-and helps differentiate between trustworthy and less reliable feature sources,
-making it easier to identify discrepancies. Although implementations can still
-manually create reports, the reputational cost of faking results acts as a
-significant deterrent.
+SupportedFeatures will become available starting 1.4 release as a standard feature, which means that all Gateway implementations will be expected to define and populate SupportedFeatures in the GatewayClass' Status.
+Conformance test suite will be based on inferring supported features from GatewayClassStatus,
+meaning if you want to generate passing report, above mentioned feature should be implemented.
+There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports will need to be generated based on the SupportedFeatures field in GatewayClass status.
+
+The core purpose of conformance tests for GatewayClass is to verify that reported features are truly supported.
+While the community currently operates on a trust-based system for conformance reports, programmatically inferring features from the GatewayClass status field creates a strong, verifiable link between an implementation's claims and the test results.
+This not only provides crucial context in conformance reports but also encourages accurate reporting and helps differentiate between trustworthy and less reliable feature sources, making it easier to identify discrepancies.
+Although implementations can still manually create reports, the reputational cost of faking results acts as a significant deterrent.
 
 ## Followups
 

From ad1c6516493279a6e821f56c10857ebe16bf4697 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Wed, 16 Jul 2025 12:13:03 -0700
Subject: [PATCH 16/21] Added info that suite will throw an error if Mesh
 features are added to GWC.

---
 geps/gep-2162/index.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 20779d94bc..b46bdea934 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -104,7 +104,8 @@ status:
 
 ### SupportedFeatures Guidance in GatewayClass
 
-Only Gateway related features should be published on GatewayClass. The rest, i.e Mesh features should not be published on Gateway Class, and will likely to be published on a Mesh resource if an when it is [introduced](https://github.com/kubernetes-sigs/gateway-api/pull/3887).
+Only Gateway related features should be published on GatewayClass. The rest, i.e Mesh features should not be published under GatewayClass, and will likely to be published on a Mesh resource if and when it is [introduced](https://github.com/kubernetes-sigs/gateway-api/pull/3887).
+If the Mesh features are added to the GatewayClassStatus conformance test suite will error out.
 
 ## Standardize features and conformance tests names
 
@@ -133,7 +134,7 @@ In any case, the conformance tests file names should be meaningful and easy to u
 #### Conformance report
 
 In order for to verify that the list of features reported are indeed supported by GatewayClass tests will be run based on the features from the GatewayClassStatus.
-If the source of features are not inferred (manually provided) the conformance suite will block the report from being submitted.
+If the source of Gateway features are not inferred and manually provided the conformance suite will block the report from being submitted.
 
 #### Reporting Mesh features
 

From 9e8acd26d5739774f2dcff523ea500c39e6cd958 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Thu, 7 Aug 2025 15:05:09 -0700
Subject: [PATCH 17/21] Apply suggestions from code review

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index b46bdea934..94977e7efc 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -104,8 +104,8 @@ status:
 
 ### SupportedFeatures Guidance in GatewayClass
 
-Only Gateway related features should be published on GatewayClass. The rest, i.e Mesh features should not be published under GatewayClass, and will likely to be published on a Mesh resource if and when it is [introduced](https://github.com/kubernetes-sigs/gateway-api/pull/3887).
-If the Mesh features are added to the GatewayClassStatus conformance test suite will error out.
+Only Gateway related features should be published on GatewayClass. The rest, i.e Mesh features should not be published under GatewayClass, and will likely to be published on the new Mesh resource CRD when it is ready [ref](https://github.com/kubernetes-sigs/gateway-api/pull/3950).
+Mesh features published on GatewayClassStatus will be ignored by the conformance test suite along with a warning.
 
 ## Standardize features and conformance tests names
 
@@ -150,8 +150,7 @@ There will be a grace period until the 1.5 release, after which all Gateway Conf
 
 The core purpose of conformance tests for GatewayClass is to verify that reported features are truly supported.
 While the community currently operates on a trust-based system for conformance reports, programmatically inferring features from the GatewayClass status field creates a strong, verifiable link between an implementation's claims and the test results.
-This not only provides crucial context in conformance reports but also encourages accurate reporting and helps differentiate between trustworthy and less reliable feature sources, making it easier to identify discrepancies.
-Although implementations can still manually create reports, the reputational cost of faking results acts as a significant deterrent.
+Having this connection between supported features and conformance tests, helps improve the UX and make it easier for implementers to run the correct conformance tests.
 
 ## Followups
 

From 7df8f7e76e3aa6dd2750ebac55484f49fcb57990 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Thu, 7 Aug 2025 15:05:26 -0700
Subject: [PATCH 18/21] Update geps/gep-2162/index.md

Co-authored-by: Lior Lieberman <liorlib7+riskified@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 94977e7efc..2c8f8251cb 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -139,7 +139,7 @@ If the source of Gateway features are not inferred and manually provided the con
 #### Reporting Mesh features
 
 As Mesh doesn't have a good place (yet) to populate SupportedFeatures, its features can be tested for compliance by using Conformance Profiles, or manually, providing features for test using `--supported-features` flag.
-Conformance suite will determine if the implementation doesn't support GatewayClass and validate that report is run for the Mesh features and NOT block the report.
+Until mesh features are posted on the Mesh resource CRD, the conformance suite will determine if conformance run is for Mesh features and will NOT block the report if provided manually.
 
 #### Staying Compliant
 

From 683724ba8a374279a6b3bc715469889e59969b18 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <bexx@google.com>
Date: Mon, 11 Aug 2025 11:32:10 -0700
Subject: [PATCH 19/21] Link issue for populating mesh features in its crd.

---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 2c8f8251cb..b248077c6c 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -139,7 +139,7 @@ If the source of Gateway features are not inferred and manually provided the con
 #### Reporting Mesh features
 
 As Mesh doesn't have a good place (yet) to populate SupportedFeatures, its features can be tested for compliance by using Conformance Profiles, or manually, providing features for test using `--supported-features` flag.
-Until mesh features are posted on the Mesh resource CRD, the conformance suite will determine if conformance run is for Mesh features and will NOT block the report if provided manually.
+Until mesh features are posted on the Mesh resource CRD, the conformance suite will determine if conformance run is for [Mesh features](https://github.com/kubernetes-sigs/gateway-api/issues/3984) and will NOT block the report if provided manually.
 
 #### Staying Compliant
 

From b715bdc3826b3bf0c9233d2a84dba2245de52149 Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Wed, 13 Aug 2025 10:14:12 -0700
Subject: [PATCH 20/21] Update geps/gep-2162/index.md

Co-authored-by: Rob Scott <rob.scott87@gmail.com>
---
 geps/gep-2162/index.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index b248077c6c..1efd4dbe62 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -144,8 +144,8 @@ Until mesh features are posted on the Mesh resource CRD, the conformance suite w
 #### Staying Compliant
 
 SupportedFeatures will become available starting 1.4 release as a standard feature, which means that all Gateway implementations will be expected to define and populate SupportedFeatures in the GatewayClass' Status.
-Conformance test suite will be based on inferring supported features from GatewayClassStatus,
-meaning if you want to generate passing report, above mentioned feature should be implemented.
+The conformance test suite will be based on inferring supported features from GatewayClassStatus,
+meaning if you want to generate passing report, features should be populated there.
 There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports will need to be generated based on the SupportedFeatures field in GatewayClass status.
 
 The core purpose of conformance tests for GatewayClass is to verify that reported features are truly supported.

From 4af263ad183aedd5e43aa5cd39e9857c00340d6b Mon Sep 17 00:00:00 2001
From: Beka Modebadze <58038950+bexxmodd@users.noreply.github.com>
Date: Wed, 13 Aug 2025 10:14:21 -0700
Subject: [PATCH 21/21] Update geps/gep-2162/index.md

Co-authored-by: Rob Scott <rob.scott87@gmail.com>
---
 geps/gep-2162/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md
index 1efd4dbe62..25f3371c63 100644
--- a/geps/gep-2162/index.md
+++ b/geps/gep-2162/index.md
@@ -146,7 +146,7 @@ Until mesh features are posted on the Mesh resource CRD, the conformance suite w
 SupportedFeatures will become available starting 1.4 release as a standard feature, which means that all Gateway implementations will be expected to define and populate SupportedFeatures in the GatewayClass' Status.
 The conformance test suite will be based on inferring supported features from GatewayClassStatus,
 meaning if you want to generate passing report, features should be populated there.
-There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports will need to be generated based on the SupportedFeatures field in GatewayClass status.
+There will be a grace period until the 1.5 release, after which all Gateway Conformance Reports will need to be generated based on the SupportedFeatures field in GatewayClass status (with the exception of Mesh features described above).
 
 The core purpose of conformance tests for GatewayClass is to verify that reported features are truly supported.
 While the community currently operates on a trust-based system for conformance reports, programmatically inferring features from the GatewayClass status field creates a strong, verifiable link between an implementation's claims and the test results.