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

Ben Campbell <ben@nostrum.com> Thu, 28 September 2017 03:06 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3E132D4E; Wed, 27 Sep 2017 20:06:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: doh-chairs@ietf.org, doh@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150656797942.13674.8149145165497227094.idtracker@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 20:06:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/1LOpKCvauZUOyTqWIP3cx7bNLxs>
Subject: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Sep 2017 03:06:19 -0000

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:


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?