DNS Over HTTPS
charter-ietf-doh-01

I do not object to the work -- but I personally think that one of the main benefits is the potential for censorship resistant DNS. I realize that listing all the justifications for doing something isn't really the job of the charter, but I was a bit surprised to not see it mentioned more prominently. 

I also think that strong consultation with DNSOP will be very important - DNS has much hidden subtlety and it is easy to trip over the edges if you are not careful.

Just a couple of nits:

(1) s/data may used/data may be used

(2) Given that the milestones reflect the intended date for completion, I don't think it is necessary to also include the date in the charter text.

What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this.
My first reaction was: is it because HTTP(S) became the new transport? But obviously not.
So instead of fixing a DNS issue with UDP/TCP/DTLS, we're going to offer yet another choice (with, I guess, a different source of truth?)
Do we need to mention the connection with DNSSEC?
Why not DPRIV?

I think I agree with MT's point that it would be best if this binding
were agnostic about HTTP/2 over TLS versus HTTPS over QUIC (or
whatever we call it) and to the extent possible, agnostic about HTTP/2
versus HTTP/1.1 (i.e., the binding should be indifferent for the
functionality that don't depend on explicit HTTP/2 features like
push). However, I think we could send the charter out for review
w/o deciding that.

I would actually also like to have more information which protocol stack is exactly in scope.

I agree with Eric's BLOCK, that this charter should be really clear about HTTPS expectations.  If I was chairing this working group, I'd want to know whether specifying HTTP was in scope, up front. 

I'm pretty sure I know what the answer is going to be, but I'll let people who understand more about DNS usage have that conversation before I express an opinion.

I also have concerns similar to Terry but Adam's proposed changes will resolve them.

Thank you for the added text.