Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

Thanks for sharing this.

I wonder if you considered WPAD (Web Proxy Autodiscovery) or PAC (Proxy
auto-config)? Although targetted at the application layer, it might help to
comment on how those forms of discovery would relate to the methods
outlined in your draft.

Cheers,
Lucas

On Mon, Nov 4, 2019 at 4:58 PM Mirja Kuehlewind <mirja.kuehlewind=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi all,
>
> we submitted a new draft that lists discovery mechanisms for QUIC-based
> proxies (see below). This is one piece of work that is needed for most of
> the use cases in draft-kuehlewind-quic-substrate.
>
> Let me know if you have any questions or comments!
>
> Mirja
>
>
> On 04.11.19, 17:53, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>
>     A new version of I-D, draft-kuehlewind-quic-proxy-discovery-00.txt
>     has been successfully submitted by Mirja Kuehlewind and posted to the
>     IETF repository.
>
>     Name:               draft-kuehlewind-quic-proxy-discovery
>     Revision:   00
>     Title:              Discovery Mechanism for QUIC-based,
> Non-transparent Proxy Services
>     Document date:      2019-11-04
>     Group:              Individual Submission
>     Pages:              11
>     URL:
> https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-proxy-discovery-00.txt
>     Status:
> https://datatracker.ietf.org/doc/draft-kuehlewind-quic-proxy-discovery/
>     Htmlized:
> https://tools.ietf.org/html/draft-kuehlewind-quic-proxy-discovery-00
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kuehlewind-quic-proxy-discovery
>
>
>     Abstract:
>        Often an intermediate instance (such as a proxy server) is used to
>        connect to a web server or a communicating peer if a direct end-to-
>        end IP connectivity is not possible or the proxy can provide a
>        support service like, e.g., address anonymisation.  To use a non-
>        transparent proxy a client explicitly connects to it and requests
>        forwarding to the final target server.  The client either knows the
>        proxy address as preconfigured in the application or can dynamically
>        learn about available proxy services.  This document describes
>        different discovery mechanisms for non-transparent proxies that are
>        either located in the local network, e.g. home or enterprise
> network,
>        in the access network, or somewhere else on the Internet usually
>        close to the target server or even in the same network as the target
>        server.
>
>        This document assumes that the non-transparent proxy server is
>        connected via QUIC and discusses potential discovery mechanisms for
>        such a QUIC-based, non-transparent proxy.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>