Re: [Add] [Ext] ADD Planning for IETF107
Paul Hoffman <paul.hoffman@icann.org> Sat, 07 March 2020 00:34 UTC
Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AB63A0E85 for <add@ietfa.amsl.com>; Fri, 6 Mar 2020 16:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 02jwwUtNhxm5 for <add@ietfa.amsl.com>; Fri, 6 Mar 2020 16:34:55 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290283A0E84 for <add@ietf.org>; Fri, 6 Mar 2020 16:34:55 -0800 (PST)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0270YrMq025383 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 7 Mar 2020 00:34:53 GMT
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 Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 6 Mar 2020 16:34:51 -0800
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.1497.006; Fri, 6 Mar 2020 16:34:51 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: "Deen, Glenn" <Glenn_Deen@comcast.com>
CC: ADD Mailing list <add@ietf.org>
Thread-Topic: [Ext] [Add] ADD Planning for IETF107
Thread-Index: AQHV9BMI351tcD20tU+dDFh8xw2ywqg8zmOA
Date: Sat, 07 Mar 2020 00:34:51 +0000
Message-ID: <659242CA-6E65-40B7-B753-0964D8756EAB@icann.org>
References: <79C104A7-47B8-4179-9B9A-25133C8B2840@comcast.com>
In-Reply-To: <79C104A7-47B8-4179-9B9A-25133C8B2840@comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_EA84C979-C4B6-42B4-84D5-80FE4297AB08"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-06_09:2020-03-06, 2020-03-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/FjfZWRW0JlsttzY3S0GPdeGaJjc>
Subject: Re: [Add] [Ext] ADD Planning for IETF107
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2020 00:34:56 -0000
FWIW, I consider draft-ietf-dnsop-resolver-information and draft-sah-resinfo-doh to be as much about discovery of secure resolvers as they are about resolver information. That is, if you know the address of your current resolver, you can ask it "are you my secure resolver" using those protocols. Separately, I don't understand the inclusion of draft-arkko-abcd-distributed-resolver-selection in the agenda for this WG. The document gives its scope as: This memo discusses whether DNS clients can improve their privacy through the potential use of a set of multiple recursive resolver services. This doesn't seem like it is about resolver discovery or resolver information, but instead about resolver assignment (probably by an application or OS). I like many of the ideas in the draft, but they don't seem to be home here. --Paul Hoffman
- [Add] ADD Planning for IETF107 Deen, Glenn
- Re: [Add] [Ext] ADD Planning for IETF107 Paul Hoffman
- Re: [Add] ADD Planning for IETF107 Deen, Glenn