Subject: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Sep 2017 20:06:19 -0700

Ben Campbell has entered the following ballot position for
charter-ietf-doh-00-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-doh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Adam Roach <[email-masked]>
Date: Wed, 27 Sep 2017 22:20:12 -0500

On 9/27/17 22:06, Ben Campbell wrote:
> keeping this separate from DPRIVE was that confidentiality was_not_  the
> primary use case, and connection from JS in browsers_was_.

I seem to recall that the issue with doing it in DPRIVE was that DPRIVE 
made it clear that they were not interested. I thought Terry said as 
much during the last formal telechat, although the narrative minutes 
don't seem to capture it in a way that matches my memory.

The conversation about the charter so far -- like the input document -- 
are based primarily on "getting queries through networks where they 
might otherwise be blocked, snooped, or tamped with" as the primary use 
case, and the javascript-in-a-browser use case as secondary. There was 
one proponent on [email-masked] who was specifically interested in the 
latter case, but the language above that precludes blocking that ability 
should serve those purposes fine.

> I see where people

I took the line from DPRIVE because it was already vetted. :)

You can find context for that specific addition here: 
<https://mailarchive.ietf.org/arch/msg/ietf/2jdAf975gKGRwffgmums27m5-hM>

/a

---

From: Ben Campbell <[email-masked]>
Date: Wed, 27 Sep 2017 22:31:09 -0500

> On Sep 27, 2017, at 10:20 PM, Adam Roach <[email-masked]> wrote:
> 
> I seem to recall that the issue with doing it in DPRIVE was that DPRIVE made it clear that they were not interested. I thought Terry said as much during the last formal telechat, although the narrative minutes don't seem to capture it in a way that matches my memory.

I should let Terry speak for himself, but I thought at some point he mentioned that as the reasoning DPRIVE was not interested. I may misremember.

Don’t get me wrong, I’m happy enough with this going forward. This was a “yes” ballot.  I just wanted to make sure we hadn't changed the basic premise which generated the “not in DPRIVE” decision.

> 
> The conversation about the charter so far -- like the input document -- are based primarily on "getting queries through networks where they might otherwise be blocked, snooped, or tamped with" as the primary use case, and the javascript-in-a-browser use case as secondary. There was one proponent on [email-masked] who was specifically interested in the latter case, but the language above that precludes blocking that ability should serve those purposes fine.
> 
>> I see where people
> You can find context for that specific addition here: <https://mailarchive.ietf.org/arch/msg/ietf/2jdAf975gKGRwffgmums27m5-hM>

Yeah, I think that was entry number 86 :-)