Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt

Jim Reid <jim@rfc1035.com> Wed, 11 March 2015 01:33 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F61A8AE8 for <dnsop@ietfa.amsl.com>; Tue, 10 Mar 2015 18:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 WIe7jACctwrR for <dnsop@ietfa.amsl.com>; Tue, 10 Mar 2015 18:33:16 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDDD1A8821 for <dnsop@ietf.org>; Tue, 10 Mar 2015 18:33:14 -0700 (PDT)
Received: from [10.47.168.180] (unknown [91.103.36.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id CAC812420FB7; Wed, 11 Mar 2015 01:33:11 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <50B802F4-26D3-4250-BEFE-5C5EAF2093A2@virtualized.org>
Date: Wed, 11 Mar 2015 01:33:10 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0336D810-AF17-4760-A331-D6A569ABC5FB@rfc1035.com>
References: <20150302105857.16985.904.idtracker@ietfa.amsl.com> <54F4E124.3010406@gmail.com> <alpine.LFD.2.10.1503022129000.19140@bofh.nohats.ca> <alpine.LSU.2.00.1503031046080.23307@hermes-1.csi.cam.ac.uk> <50B802F4-26D3-4250-BEFE-5C5EAF2093A2@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/GFEytIJke98yYYx9TeC7_YCMHqc>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-chapin-additional-reserved-tlds-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 01:33:18 -0000

On 11 Mar 2015, at 00:08, David Conrad <drc@virtualized.org> wrote:

> While true, these values will vary over time, location of collection, and myriad other reasons, probably including phase of moon. If we're going to reserve strings from ever being delegated, I believe we need to come up with some rationale beyond "because they showed up a lot at some root servers at this point in time."

In the absence of other objective, measurable data (sigh), going with what's seen at the root for some arbitrary shapshot(s) on arbitrary date(s) seems to be the least-worst option. It might even be the only option.

> If that is the only criteria, it would be relatively easy to game the stats by hiring a few botnet zombies to pump queries with names you'd like to reserve with spoofed source addresses.

The same would no doubt hold for whatever other criteria were chosen.

IMO the draft is a reasonable attempt at harm reduction. For some definition of harm. It seems ICANN's policy-making fora want the IETF to produce a list of "dangerous" TLD strings (on technical grounds) so that they can point at some RFC and say everything else can be classed as "safe to delegate". Which is at best a very misguided approach IMO.

That ship has already sailed so the WG just has to make the best job it can of the cards it has been dealt. If anyone here has better ideas on how to do that, please speak up.

I think it would be prudent to assume any new TLD strings (if there ever are any after the current round has been processed) are harmful unless the applicant can prove otherwise to a reasonable standard. But nobody's ever going to accept that.