John Howard

> My personal preference is to use the migration to the new K8S Gateway model > to fix all bad behaviors in Istio - this one, various things you >...

> > Is a list of ENUMs the best way to represent this? it does allow a > > strange config like [REQUEST_ID, REQUEST_ID] but that can just > >...

> I mostly agree - but no "envoy" in the API please since it should be moved to the vendor-neutral K8S Gateway policy. These are for literally controlling envoy headers...

This also impacts sidecar so it seems tricky to have a "policy attachment" mechanism, especially when one hasn't been done so far in Istio yet

> If we reuse the Kubernetes types, which means we import Kubernetes' proto in istio's proto and generate the istio's golang types, then the inline metadata will be lost, the...

> But please not in MeshConfig Rate limit feels like a similar category as telemetry,tracing,and ext authz backend. So why not follow the same pattern? If we don't like that...

There is no owner, I think the owners of certain APIs should fix the issues. Its probably not actually the tool thats broken but something in the proto. tool is...

Why should networking API change, wasn't it was using the selector first? We cannot break compatibility anyways, so best we could do is provide both most likely.

Can you give a little more info about why we would want this? I don't see why this needs to be customizable

"Secret of type tls for server certificates along with ca.crt key for CA certificates is also supported." is intending to cover this. It should probably say "Secret of type kubernetes.io/tls,...