conformance profiles: how to handle multiple "modes" in a project

[howardjohn]

Slack context: https://kubernetes.slack.com/archives/CR0H13KGA/p1690238884857489?thread_ts=1690225970.833499&cid=CR0H13KGA

Many projects can operate in different modes. Some examples are Istio in sidecar mode vs ambient, GKE in internal LB mode or external LB mode (or multicluster vs single cluster), etc.

We should prescribe how these are reported in conformance profiles.

[robscott]

Good question. In GKE behavior is unique per GatewayClass, but other implementations like Istio may have different behavior for the same GatewayClass.

/cc @mlavacca @shaneutt

[mlavacca]

Yeah, it makes total sense. Kong has different modes that actually affect conformance as well. One thing that immediately comes to my mind is adding a new optional field related to the mode in the report's implementation section. I think we need to update the GEP and maybe discuss the implementation details there. @howardjohn would you be interested in tackling that? It'd be great to have someone else coming from other implementations participating in the conformance profiles story.

[youngnick]

This may be out of scope for this issue, but so it doesn't get lost; should we also consider allowing multiple versions for an implementation?

Copying a comment I put in Slack:

I also thought today about multiple versions - do we want to allow implementations to submit multiple conformance reports, each one for a single version (it seems like it might be nice to be able to say "main is at v1.2.0, stable is at v1.0.0" for an implementation.)
Also, that would allow us to keep history (for example, Cilium 1.14 supports Gateway v0.7.1, but Cilium 1.15 will probably jump straight to Gateway API v1.0.0 because of release cycle timings).

[mlavacca]

/assign