Ballot for charter-ietf-doh
Yes
No Objection
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
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.
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.
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.