Costin Manolache

I would suggest instead starting with a doc ( RFC, etc) describing the current distribution mechanism and options for roots of trust, and if we want to make change, have...

I wouldn't mind a mechanism to provide defaults - but MeshConfig is not the right place. Keeping in mind we plan to move to the K8S Gateway API, which defines...

In other word- for any operator-specific change ( and for every helm-specific setting ) I would like to see doc describing how the other is handling it and why it...

Still - an RFC explaining how the final ( common/ shared ) config will loook like, what is the upgrade plan, how will the existing values be migrated is needed.

The bug seems to be about adjusting the default values. I don't think we need API changes for that. We already have settings to enable the autoscaling - and we...

I am more concerned about the default behavior - I don't think users should start having to write configs to get correct and expected behavior. - inside the mesh we...

Yes, backward compat is a concern in a lot of areas - we do need some mechanism to migrate to the new behavior, but it doesn't have to be a...

@nrjpoddar for gateway, I think the correct default behavior is to filter out XFCC from incoming requests, unless gateway topology is used. And to generate XFCC if the gateway terminates...

> message ProxyHeaders { ForwardedClientCert forwarded_client_certs (APPEND|SANITIZE|APPEND_FORWARD....) bool enable_envoy_headers bool include_attempt_count bool skip_server_header } > > I think a message like above would be more readable and help us expand...

The general problem here is to control 'proxy headers' - including vendor-specific headers like x-envoy but probably more important are the standard ones ( XFCC, XFF, etc ). Arguably users...