Hi all! Apologies for such a late email, but I wanted to chime in with some thoughts on the draft. For some context, my team runs various privacy preserving proxies, including a second-hop proxy in iCloud Private Relay (a "Proxy B"), various single hop CONNECT proxies and finally some Oblivious HTTP relays (and gateways).
Overall the draft is great! It nicely defines and condenses some similar structures we have in our own control-plane. I can see this being very useful for our own tooling and for automatic configuration for our customers. I have two minor suggestions: 1. First, consider removing the distinction between `http-connect` and `https-connect` and combine the two into one protocol, `connect`. For `http-connect` and `https-connect`, transport security is encoded in the protocol identifier, whereas for the `connect-*` family of protocols, it's encoded in the URI scheme. To me, the capability to provide TLS is a question of the transport and not proxying protocol and adding a scheme is sufficient to signal that. I suggest using a single protocol `connect` with a `URI template` Proxy Location Format. Then with a note specifying that only the scheme and host should be present. For example: A TLS enabled connect proxy uses `https://`: ``` { "protocol": "connect", "proxy": "https://proxy.example.org"; } ``` And one without TLS would use `http://`: ``` { "protocol": "connect", "proxy": "http://proxy.example.org"; } ``` 2. Second, when multiple proxy dictionaries are present, I believe the client SHOULD use the first proxy presented to it which satisfies the client's requirements and then only move to the next satisfying proxy in the event of failure. It is very useful to have a deterministic, server-controlled method of determining what actions a client takes. If clients always choose the first satisfactory proxy, it's much easier to safely deploy breaking changes. More concretely, I suggest these edits: - `should -> SHOULD` in: "If a matching rule contains more than one identifier the client SHOULD treat the list as an ordered list." - "Multiple proxy dictionaries can contain the same identifier value. In this case, the client SHOULD choose the first proxy." Take for example a blue-green deployment of a proxy. `proxy-blue.example.org` and `proxy-green.example.org` run two different versions of proxying code. Both proxies share the same identifier `privacy-proxy`. The PvD would look something like this: ``` { // other PvD fields omitted "proxies": [ { "identifier": "privacy-proxy", "protocol": "https-connect", "proxy": "proxy-blue.example.org:443" }, { "identifier": "privacy-proxy", "protocol": "https-connect", "proxy": "proxy-green.example.org:443" }, ] } ``` With deterministic client selection, we (the proxy provider) can know based on this config that all clients should be using `proxy-blue` as their primary proxy and only use `proxy-green` as a backup. To deploy, we can drop the expiration time and begin sending PvDs with the `proxy-green` proxy as the first one in the list. Then we slowly increase the percentage of responses which have `proxy-green` be the first in the list while watching health metrics. This way once 100% of PvD configs have `proxy-green` as the first in the list, we can be fairly confident all of our clients prefer `proxy-green` over `proxy-blue`. This is definitely a contrived example. Moving the traffic using DNS/anycast/etc. is usually easier. However, the point is that breaking changes in version-less configuration can be difficult to rollout across all clients. Knowing that clients will use a certain configuration in a specific order makes any breaking or risky changes easier to rollout, especially around changes in proprietary keys. I'm happy to write some GitHub issues or PR if the language changes if that's helpful for further review :) In any case, thanks for reading my email and thank you all for the efforts on this draft! All the best and happy New Year's, - Fisher
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
