IETF Logo Mail Archive

Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq

Jim Reid <jim@rfc1035.com> Tue, 23 March 2021 15:59 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C875B3A1323 for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 08:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 ojLnHb3QcEuY for <dns-privacy@ietfa.amsl.com>; Tue, 23 Mar 2021 08:59:41 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0D53A131C for <dns-privacy@ietf.org>; Tue, 23 Mar 2021 08:59:40 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 4E1332420C28; Tue, 23 Mar 2021 15:59:38 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Message-Id: <C1444682-A016-40AD-8F3A-272B68E035BE@rfc1035.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_AFD4AFA9-A75F-49F7-9934-F55986A07BA5"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Date: Tue, 23 Mar 2021 15:59:37 +0000
In-Reply-To: <A340AA39-B80E-47DB-87C1-01D13675550A@pch.net>
Cc: Brian Haberman <brian@innovationslab.net>, dns-privacy@ietf.org
To: Bill Woodcock <woody@pch.net>
References: <2ba5ac12c24eaee4c51de2cd2c1693e9bd1fd8b2.camel@powerdns.com> <4bc96140-454e-0746-83b3-bb1331cf7cce@cs.tcd.ie> <ADB00FD5-A6EA-4D05-84E8-A44A2E40BE7C@icann.org> <8363070a-8fc5-2d20-a9aa-45673d1515ac@innovationslab.net> <5861CBBC-4C76-4455-90FF-B127171CF054@rfc1035.com> <A340AA39-B80E-47DB-87C1-01D13675550A@pch.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/E6NBwoUroTsDGmb59bB2fdn-J9w>
Subject: Re: [dns-privacy] [Ext] next steps for draft-opportunistic-adotq
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 15:59:46 -0000


> On 23 Mar 2021, at 14:54, Bill Woodcock <woody@pch.net> wrote:
> 
> There are a million clever and useful things that you could do, if it were possible. Which are particularly valuable for brand TLDs, for instance.

IMO, the IETF shouldn’t get into developing protocols just for the benefit of here today, gone tomorrow brand TLDs.

> What arguments exist against it?  Was there some justification, back when that language was put in?  I’ve always assumed it was just existing registries trying to gratuitously jerk new ones around.

IIUC the ICANN limitations on RRtypes was to stop registries doing stuff like adding A or MX records for names that didn’t have delegations.

v2.23.0 | Report a Bug | By Email