Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2018 15:06:06 +0000

On Apr 30, 2018, at 10:28 PM, Mark Nottingham <[email-masked]> wrote:
> "The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]."
> 
> SHOULD is too strong here, and "used by DOH" is ambiguous. Suggest:
> 
> "DNS API clients and servers should support, but not require, the use of HTTP/2 [RFC7540]."

This seems like a good clarification.

--Paul

---

From: Patrick McManus <[email-masked]>
Date: Tue, 1 May 2018 17:17:41 -0400

Hey Mark, et al,

For those following just list mail - paul opened a corresponding github
issue https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/165

The essence of your proposal is making this a non-normative SHOULD, but I
think we had established this as something pretty important for the
protocol to operate well. (and I say this not just as an HTTP/2 advocate,
but because the light-bandwidth, high-latency nature of DoH is in
particular need of HTTP/2's multiplexing). However practical considerations
of not being able to control the whole protocol chain create "valid reasons
in particular circumstances" (from 2119) to ignore the requirement.

If you prefer, I would be happy to change to use RECOMMENDED .. when the WG
had this discussion in Singapore we decided to change from MUST to
RECOMMEND (or was it recommend?) instead.

On Tue, May 1, 2018 at 1:28 AM, Mark Nottingham <[email-masked]> wrote:

> Hi,
>
> Overall, this looks good. One issue:
>
> Cheers,
> > On 19 Apr 2018, at 5:07 am, Ben Schwartz <[email-masked]> wrote:
> >
> > All,
> > This message starts a two week WG Last Call on advancing:
> >
> >   Title           : DNS Queries over HTTPS
> >   Author          : Paul Hoffman, Patrick McManus
> >   Filename        : draft-ietf-doh-dns-over-https-07
> >   Pages           : 17
> >   Date            : 2018-04-11
> >
> > as a Standards Track document. The last call will end on May 2, 2018.
> > All substantive comments are to be sent to the [email-masked] list for
> > discussions. Editorial comments can be sent to the document editor.
> >
> > You can find the latest version of the document here:
> > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07
> >
> > Regards,
> > Ben & tale
> > _______________________________________________
> > Doh mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/doh
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 May 2018 08:49:24 +1000

RECOMMENDED works for me.

Cheers,

> On 2 May 2018, at 7:17 am, Patrick McManus <[email-masked]> wrote:
> 
> Hey Mark, et al,
> 
> For those following just list mail - paul opened a corresponding github issue https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/165
> 
> The essence of your proposal is making this a non-normative SHOULD, but I think we had established this as something pretty important for the protocol to operate well. (and I say this not just as an HTTP/2 advocate, but because the light-bandwidth, high-latency nature of DoH is in particular need of HTTP/2's multiplexing). However practical considerations of not being able to control the whole protocol chain create "valid reasons in particular circumstances" (from 2119) to ignore the requirement.
> 
> If you prefer, I would be happy to change to use RECOMMENDED .. when the WG had this discussion in Singapore we decided to change from MUST to RECOMMEND (or was it recommend?) instead. 
> 
> 
> 
> 
>

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 2 May 2018 14:23:30 +0100

One other last nit/question on this. The WG charts states:

“The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g., operating
system stub resolvers) and recursive resolvers.”

But the definitions in the Terminology are simply ‘DNS API client' and ‘DNS API server’. Much of the discussion of caching and DNSSEC is specific to stup-resolver interactions so I think this needs to be addressed.

I suggest stating the scope clearly in the draft e.g.:

"This document focuses on communication between DNS clients (e.g., operating
system stub resolvers) and recursive resolvers, as per
 the charter of the DOH Working Group at the time of writing.”

Sara.

> On 18 Apr 2018, at 20:07, Ben Schwartz <[email-masked]> wrote:
> 
> All,
> All substantive comments are to be sent to the [email-masked] <mailto:[email-masked]> list for
> https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 <https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07>
> 
> Regards,
> Ben & tale

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 3 May 2018 01:09:22 +0000

>  the charter of the DOH Working Group at the time of writing.”

Good catch, yes.

--Paul Hoffman