Original text:
partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS RFC1035 <del> 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. </del>  The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses

Reviewer comments:
NAME 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 don'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.
NAME the singapore meeting is available here URL .. goto the 12 minute mark to review the discussion (wrt your question about drawbacks).
Text is in URL
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 NAME touched on in URL, is that it is unclear whether or not a minimum HTTP version must be supported. Based on URL , do we consider that by supporting HTTP/1.1 we get HTTP/1.0 for free and consider 0.9 not an option? Wouldn'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.

Revised text:
partially because they did not follow HTTP best practices. This document defines a specific protocol for sending DNS RFC1035  <ins> 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. </ins> The described approach is more than a tunnel over HTTP.  It establishes default media formatting types for requests and responses