Draft: draft-ietf-doh-dns-over-https-latest

Commentary: I 'm ok with you merging this and closing 11 if you 're ok with it . 
 I think that it is fine - or more precisely , invaluable - to explain what the semantics of server push are . But you do n't actually require HTTP/2 for this protocol to work . The only thing that requiring HTTP/2 gets you is tighter constraints on TLS usage . You can get those same constraints with some deployment recommendations . I would support strong recommendations that said HTTP/2 is useful for its multiplexing as well as similarly strong advice about following the advice in RFC 7525 . Those are both good practice . 
 fairly clear feedback from singapore to change this to an endorsement ( SHOULD ) with better explanatory text focusing on performance and scale . 
 What are the drawbacks of HTTP/2 ? Less readily available libraries ? more complex protocol ? Potential difficulties in integrating with current fronting stacks that may not be HTTP/2 ready ? On one hand , I feel like it may be easier to just enforce 1 stack for now rather than having to support multiple flavor of client / server protocols . A suboptimal HTTP/2 implementation may just be similar to HTTP/1 but at least we can try to move forward toward multiplexing . Making HTTP/2 a should may just leave us in limbo in HTTP/1 land . 
 the singapore meeting is available here .. goto the 12 minute mark to review the discussion ( wrt your question about drawbacks ) . 
 Text is in 
 Last PR accepted . I suspect there will be a bit more wordsmithing , but this should cover the main issue well . 
 thanks , I was in the room , but my notes were sparse and some of the cons I remembered of were more inconvenience to me than blockers . What I am not getting from the current spec , and which I believe touched on in , is that it is unclear whether or not a minimum HTTP version must be supported . Based on , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option ? Would n't not mandating a required version prevent client / server from having a known version to use ? Can we make this clearer maybe ? 
 The decision was to rely only on HTTP semantics and not versions . So any HTTP implementation that is acceptable to its peer can be used .
Paragraph (version A):
This document defines a specific protocol for sending DNS RFC1035
queries and getting DNS responses over modern versions of HTTP
RFC7540 using https:// (and therefore TLS RFC5246 security for
integrity and confidentiality).  Each DNS query-response pair is
mapped into a HTTP request-response pair.
Paragraph (version B):
This document defines a specific protocol for sending DNS RFC1035
queries and getting DNS responses over HTTP RFC7540 using https://
(and therefore TLS RFC5246 security for integrity and
confidentiality).  Each DNS query-response pair is mapped into a HTTP
request-response pair.
Paragraph (version A):
This protocol MUST use HTTP/2 RFC7540 or its successors in order to
satisfy the security requirements of DNS over HTTPS.  Further, the
messages in classic UDP based DNS RFC1035 are inherently unordered
and have low overhead.  A competitive HTTP transport needs to support
reordering, priority, parallelism, and header compression, all of
which are supported by HTTP/2 RFC7540 or its successors.
Paragraph (version B):
The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540.
Paragraph (version B):
The messages in classic UDP based DNS RFC1035 are inherently
unordered and have low overhead.  A competitive HTTP transport needs
to support reordering, parallelism, priority, and header compression
to acheive similar performance.  Those features were introduced to
HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of
conveying the semantic requirements of DOH but would result in very
poor performance for many uses cases.
Paragraph (version A):
Running DNS over HTTPS relies on the security of the underlying HTTP
connection.  By requiring at least RFC7540 levels of support for TLS,
this protocol expects to use current best practices for secure
transport.
Paragraph (version B):
Running DNS over HTTPS relies on the security of the underlying HTTP
transport.  Implementations utilizing HTTP/2 benefit from the TLS
profile defined in RFC7540 Section 9.2.