Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On 3 April 2018 at 17:58, Martin Thomson wrote: > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. It's

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On Apr 3, 2018, at 1:00 PM, Dave Lawrence wrote: > That testing TCP capabilities part is a distraction from the core > motivation. The request makes sense from a dumb transparent proxy > point of view, where there's a regular DNS resolver on the one end who > just wants to be able

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Martin Thomson writes: > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. That testing TCP capabilities part is a distraction from the

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

If I understand your response (not sure that I do), that seems pretty academic and not at all persuasive. For instance, if a client cared about testing TCP capabilities, it can always do its own resolution. On Tue, Apr 3, 2018 at 7:44 PM, Davey Song wrote: > > > On 3

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On 3 April 2018 at 15:33, Martin Thomson wrote: > This is intended to do what? Indicate where the response came from? > Why does the client care? To keep the proxy (API client and server) transparent and bypass the middlebox along the path. Without the indicate, the

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

On 03/04/2018 08:33, Martin Thomson wrote: > This is intended to do what? Indicate where the response came from? > Why does the client care? I assume that it doesn't apply to > requests, or that would get into draft-bellis-dnsop-xpf territory. I think there's some overlap here, if the intent

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

This is intended to do what? Indicate where the response came from? Why does the client care? I assume that it doesn't apply to requests, or that would get into draft-bellis-dnsop-xpf territory. BTW, you really need to drop UDP from the media type name now.