I've reviewed draft-ietf-intarea-proxy-config-08 and I have a few questions that I'd love to see answered before I support moving this document forward.
Questions: * what's the status of implementation? Hopefully we have multiple interoperating before sending to the IESG? * 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. Minor questions: * what characters are allowed in the "identifier" string? Is it encoded as ASCII or UTF-8? * 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? * in destination rule domains, do wildcards have to be prefixes? Or is "*.example.*" allowed? * I would also allow vendor-specific entries for Proxy Information PvD Keys * 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 Background section is needlessly combative against prior technologies. The fact that PAC/WPAD aren't standard or are "squatting" on DHCP options is irrelevant. We can talk at length why those technologies are worse than what this draft proposes, but it comes down to engineering (running an entire JavaScript engine to get the proxy hostname!?) not whether or not they were blessed by the IETF * there should be some normative text around the use of the "application/pvd+json". What happens if it isn't set by a client? 8801 doesn't mandate it. * would be good to include a reference for CIDR notation David On Wed, Oct 15, 2025 at 9:47 PM Wassim Haddad via Datatracker < [email protected]> wrote: > > Subject: WG Last Call: draft-ietf-intarea-proxy-config-08 (Ends 2025-10-29) > > This message starts a 2-week WG Last Call for this document. > > Abstract: > This document defines a mechanism for accessing provisioning domain > information associated with a proxy, such as other proxy URIs that > support different protocols and information about which destinations > are accessible using a proxy. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > Source for this draft and an issue tracker can be found at > https://github.com/tfpauly/privacy-proxy. > > File can be retrieved from: > https://datatracker.ietf.org/doc/draft-ietf-intarea-proxy-config/ > > Please review and indicate your support or objection to proceed with the > publication of this document by replying to this email keeping > [email protected] in copy. Objections should be motivated and suggestions > to > resolve them are highly appreciated. > > Authors, and WG participants in general, are reminded again of the > Intellectual Property Rights (IPR) disclosure obligations described in BCP > 79 > [1]. Appropriate IPR disclosures required for full conformance with the > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > any. Sanctions available for application to violators of IETF IPR Policy > can > be found at [3]. > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
