Re: [Doh] [Ext] WG Review: DNS Over HTTPS (doh)

Paul Hoffman <paul.hoffman@icann.org> Mon, 18 September 2017 17:29 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBB4133070; Mon, 18 Sep 2017 10:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ7Mrk4hTkqN; Mon, 18 Sep 2017 10:29:56 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8FC132992; Mon, 18 Sep 2017 10:29:56 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Sep 2017 10:29:53 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 18 Sep 2017 10:29:53 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ted Hardie <ted.ietf@gmail.com>
CC: "doh@ietf.org" <doh@ietf.org>, IETF <ietf@ietf.org>
Thread-Topic: [Ext] [Doh] WG Review: DNS Over HTTPS (doh)
Thread-Index: AQHTMKO8PoKiNsWal0q0l6Sn3okW1w==
Date: Mon, 18 Sep 2017 17:29:52 +0000
Message-ID: <E7353DA6-808C-4779-987A-DE60CEAC94F6@icann.org>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <CA+9kkMBJAP23GmGf_ix-DMeOMB=Rbas+qsBQhrVwZuA5-Cv7Mg@mail.gmail.com> <EB3D58DB-1F8D-4E32-AE71-841EBCDDC3CA@vpnc.org> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <CA+9kkMDokEDbBiCR_TRQda2RBHxoHag6mQL57Uzn7ALqakm1Og@mail.gmail.com> <e4a02fff-6803-28c7-c01d-f27a1b282d50@nostrum.com> <CA+9kkMCPRfjazW7Kk7GGnu1a0f2QNvgERV-5SGXWzp2HRmPJ=A@mail.gmail.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <CA+9kkMDRdje0LTjAXLJkU6MeEP9tgJOmTjEP3jbtogyFtYYAwA@mail.gmail.com> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <CA+9kkMCHPO_VO8sO2YUFLHCw8fTKFwoB4-Jy3V22ODHjtVs5YA@mail.gmail.com>
In-Reply-To: <CA+9kkMCHPO_VO8sO2YUFLHCw8fTKFwoB4-Jy3V22ODHjtVs5YA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1B8CD1DD7C2AB941A878EE446ED42960@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/McW73TgGrec8ysG55xNIukknIXg>
Subject: Re: [Doh] [Ext] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Mon, 18 Sep 2017 17:29:57 -0000

On Sep 18, 2017, at 10:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> Does this add a new tool for DNS systems attempting resolution to use when previous efforts are blocked?  So any DNS resolution might use it, whether from a browser, an app, or system call, but that those would not *specify* it be used?
> 
> Does this add a method for Web application to directly resolve DNS resource records using a resolver self-identified in the Javascript?  So DNS resolutions are instantiated and consumed by Javascript without any intermediation by the local DNS resolver or the browser's DNS rules?
> 
> Does this charter aim for the working group to do both?
> 
> As currently written, I see the charter describing 1.

Then that may be a failure of the current charter text. 

>  There has been an argument that it also do 2 or that 2 becomes possible when 1 is specified and is thus automatically part of the scope.  If that is the case, I believe the charter needs a re-write to describe it.  

In the many discussions leading up to the -00 wording for the charter (which became much longer in IESG discussion), #2 was the clear use case.

--Paul Hoffman