We’ve published the updates from the PRs referenced below in this revision: https://www.ietf.org/archive/id/draft-ietf-intarea-proxy-config-09.html
Thanks, Tommy > On Nov 13, 2025, at 3:53 AM, Yaroslav Rosomakho <[email protected]> > wrote: > > Hi David, > > Thank you very much for the thorough review! > > Please see responses below inline. > > -yaroslav > > >> > * what's the status of implementation? Hopefully we have multiple >> > interoperating before sending to the IESG? > > Apple has an implementation of both client and server side. Few other vendors > have implementations of the server side. > >> > * why do we restrict the discovery to .well-known/pvd ? I totally get >> > having the well-known path for cases where the proxy is configured via >> > hostname and port (similar to the default URI template for connect-udp), >> > but forcing the path like this prevents having multiple different >> > configurations on the same hostname. I think that's a shame, it prevents >> > one from running the proxy at a specific path while keeping the rest of the >> > website open. If we force a separate hostname, we're leaking that to the >> > network in the SNI. >> > >> > * Similarly, I understand forcing the port if the proxy uses a different >> > protocol like SOCKS, but it doesn't make sense to me for HTTPS. I would >> > love to be able to have a full-service HTTPS proxy with all the methods and >> > the discovery, all within its own port. > > Added text to clarify that ".well-known/pvd" path and port 443 are the > defaults that may be overridden by a local policy. > https://github.com/tfpauly/privacy-proxy/pull/314 > > Defaulting to the configured proxy port has a number of potential problems: > - a non-authorised user may be running a proxy on a high port and use that to > poison config > - a proxy running over HTTPS on a non-standard port is not guaranteed might > not be able to act as a web server and provide configuration information > > >> > Minor questions: >> > >> > * what characters are allowed in the "identifier" string? Is it encoded as >> > ASCII or UTF-8? > > Any UTF-8 as per JSON string spec. Clarified in > https://github.com/tfpauly/privacy-proxy/pull/316 > >> > >> > * how would you envision advertising support >> > for draft-ietf-masque-connect-udp-listen or draft-ietf-masque-quic-proxy in >> > this config? Perhaps some guidance in the document would help designers of >> > future extensions to proxying protocols? > > draft-ietf-masque-connect-udp-listen deserves its own "protocol" and should > be registered in the proposed Proxy Protocol IANA Registry. > As draft-ietf-masque-quic-proxy is an optional optimization for connect-udp > that is negotiated dynamically. I believe regular "connect-udp" protocol > applies. > > Do you think we need to provide additional guidance and "expert review" IANA > process is not enough? > >> > >> > * in destination rule domains, do wildcards have to be prefixes? Or is >> > "*.example.*" allowed? > > Only prefix wildcards are allowed. Clarified in > https://github.com/tfpauly/privacy-proxy/pull/318 > >> > >> > * I would also allow vendor-specific entries for Proxy Information PvD Keys > > This is allowed! Section 3.2 "Proprietary keys in proxy configurations" > >> > * That said, the vendor-specific carveout reminds me of the "X-" prefix in >> > HTTP headers. It was originally intended such that vendor-specific choices >> > would use it and they would then transition to a "standard" without the >> > "X-" prefix. In practice, once the header got traction, no one wanted to >> > change it any more so the "X-" value became the standard. That same >> > scenario is likely to happen here, so I would modify the IANA expert >> > requirement to allow underscores if there is wide deployment of the entry > > The key difference is that "X-" headers did not include a vendor name which > resulted in conflicts between implementations. > Our design is inspired by SSH namespaces which are reasonably successful at > trialing something vendor specific and later dropping the vendor designation > if the capability goes mainstream enough. > > > > This communication (including any attachments) is intended for the sole use > of the intended recipient and may contain confidential, non-public, and/or > privileged material. Use, distribution, or reproduction of this communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
