GEP: TLSRoute

[robscott]

Although TLSRoute was created prior to GEPs, we are retroactively creating this issue to track the status of this resource.

[jaronoff97]

I would love it if the TLSRoute were part of the standard offerings rather than the experimental offerings. Right now we can't use the managed Gateway API in GKE because of this.

[youngnick]

I think that TLSRoute just needs more conformance tests to be graduated. @robscott ?

[candita]

@robscott @youngnick I propose that we make no changes to the TLSRoute at the moment. Do we still need a GEP document if that is the case?

[youngnick]

Hmm, good question, this is a weird situation because of the exception to the process TLSRoute has. We currently don't have any GEP documenting what TLSRoute is actually for. Feels like maybe we could use that going forward? @robscott, @shaneutt, any thoughts?

[shaneutt]

We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.

[mlavacca]

We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.

+1. We may probably want to use the same approach for #2645 and #2644?

[candita]

We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.

@shaneutt As of yesterday, @robscott added this to Gateway API Enhancement Proposals (GEPs) (view) because I volunteered to take it on. It was deferred, but it is no longer deferred.

@youngnick I was hoping, because this is a relatively well documented component, that we could get away with out a GEP.

[mlavacca]

I'm gathering all the TLSRoute-related issues under an epic issue and I think that as a first step, we need to figure out this one. I agree with what @candita wrote here about moving on without a GEP given the current status of the API and our will to promote it in time for 1.2.

What do you think about it?

@robscott @shaneutt @youngnick

[shaneutt]

I hate to be the one pushing for something that might seem very ceremonial, but I personally would prefer that we have a GEP. If nothing else, just to document the history, progress and decisions over the years. There are benefits to this posterity:

• it can be easily found along with other features and APIs in the list of GEPs by any interested reader
• we have a legend which collects all the point-in-time context about the feature for us in one place
• nobody can say we didn't do it