Note: This ballot was opened for revision 00-06 and is now closed.

Ballot question: "Do we approve of this charter?"

(Ben Campbell) Yes

Comment (2017-09-27 for -00-12)
No email
send info
I'm balloting "yes", but I have a point of confusion on the following text:

"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients and Iterative
Resolvers.  While access to DNS-over-HTTPS servers from JavaScript running in
a typical web browser is not the primary use case for this work, precluding
the ability to do so would require additional preventative design. The working
group will not engage in such preventative design."

I remember someone (Terry, maybe?) stating earlier that the justification for keeping this separate from DPRIVE was that confidentiality was _not_ the primary use case, and connection from JS in browsers _was_.  I see where people decided otherwise in the (95 entries so far) discussion thread--but does that change the relationship with DPRIVE? Especially since the first sentence comes directly from the DPRIVE charter?

(Adam Roach) Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2017-09-28 for -00-12)
No email
send info
In my first ballot, I mentioned "What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this." Because I'm not an Web browser and DNS expert, or most likely because the concerns were not clear in my head, I could not clearly express my thoughts.

So I watched the IETF mailing list with attention.
Mark Nottingham's email summarized the situation

    It's not a matter of constraining the work; the work isn't proposing to operate even remotely in the way that you describe. I think we're just having a misunderstanding, because people have multiple use cases in mind for this protocol, and properties thereof have been mixed up.

    AIUI those use cases are, roughly:

    1. Configure your browser/OS to use a DOH service for DNS resolution (as above) -- this will affect browser/OS state, because it's being used for DNS; however, it's not being done from JS.

    2. Call a DOH service from Javascript (for some reason) -- note this is just like any other HTTP request; it doesn't affect browser/OS state outside of the same origin model. Yes, you can still build a browser-in-a-browser and mess with things inside that context, but that's already true today.

    3. Future handwavy things like making DNS updates over HTTP -- very ill-defined and not important for this discussion

Expressing #1 and #2 in the charter would have helped me. #2 is kind of present now.
What about the addition the notion of "browser and/or OS" in the next sentence?

The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS Clients and Iterative

(Spencer Dawkins) No Objection

Comment (2017-09-25 for -00-10)
No email
send info
(I would be a Yes, but I don't want to be the first one)

Thanks to everyone for the spirited review to date. I think the changes are headed the right direction. I trust that will continue.

I have one nit. In this text,

"The specification of how to discover DOH servers via mechanisms currently used
to discover other DNS servers (e.g., DHCP and Router Advertisements) may be
considered by the working group if the chairs determine that a sufficiently
large mass of working group participants exist who are willing to edit and
comment on documents regarding such mechanisms."

is "large" the best word to describe what you're expecting the chairs to be assessing?


(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2017-09-27 for -00-12)
No email
send info
I think this new text about JS is going in the right direction, but perhaps it straddles the line too much.

Say that -- contra the text here -- we discovered some respect in which it was more convenient to design the protocol in a way that made JS break. Would the charter require us not to do that? I think the answer is "no", but I just want to verify that.

Alvaro Retana No Objection