Summary: Has enough positions to pass.
Ballot question: "Is this charter ready for external review?"
Note: this charter has received review from the ART community on the DISPATCH mailing list. Comments ranged from neutral to supportive. See https://mailarchive.ietf.org/arch/search/?email_list=dispatch&gbt=1&index=XJRkCb3Yeu6_Asa5a3sFfrsvgac for details.
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 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.
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.
I would actually also like to have more information which protocol stack is exactly in scope.
Thank you for the added text.
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.
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.