Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

Ted Lemon <Ted.Lemon@nominum.com> Tue, 12 May 2015 23:16 UTC

Return-Path: <Ted.Lemon@nominum.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 68B1D1A006F for <dnsop@ietfa.amsl.com>; Tue, 12 May 2015 16:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Rubvd-gQvR99 for <dnsop@ietfa.amsl.com>; Tue, 12 May 2015 16:16:19 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 244DD1A0022 for <dnsop@ietf.org>; Tue, 12 May 2015 16:16:19 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id BDDAEDA0088; Tue, 12 May 2015 23:16:18 +0000 (UTC)
Received: from [10.0.20.126] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 12 May 2015 16:16:18 -0700
References: <20150508193400.55273.qmail@ary.lan> <FF464258-0C33-45CC-A684-BAB7BCE8A8FB@gmail.com> <alpine.OSX.2.11.1505082118060.31363@ary.lan> <0902600F-134B-4688-9CDD-1ACB23431DDE@vpnc.org> <20150512010624.GC74841@mx2.yitter.info> <62970575-A605-4B3E-9E98-D760B47E8532@isoc.org> <CAHw9_i+jpobNKtim=Gw3ZAjaU6ff3A-SHVrGHqn0AW7-WOwsNQ@mail.gmail.com> <A789E52D-9682-42C7-AF04-A25C8C43450F@nominum.com> <CAHw9_iL8CkQ8VwaCXza+vsYh990MJWsdF0crAdq2qLbJdhG6-Q@mail.gmail.com> <DA7987D3-BA53-4D88-9B83-E272D728A70E@nominum.com> <20150512163603.GP75349@mx2.yitter.info>
MIME-Version: 1.0 (1.0)
In-Reply-To: <20150512163603.GP75349@mx2.yitter.info>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <F8108959-3BAD-4198-BF97-39B4C54F917C@nominum.com>
X-Mailer: iPad Mail (12F69)
From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Tue, 12 May 2015 19:16:17 -0400
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Originating-IP: [71.233.43.215]
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MI6Z6_CbGPiu1aLWel36FhmU4RY>
Cc: "<dnsop@ietf.org>" <dnsop@ietf.org>
Subject: Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
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: Tue, 12 May 2015 23:16:20 -0000

On May 12, 2015, at 12:36 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> This is a bizarre argument.  You don't get to kind-of delegate policy
> authority this way.  Authority was delegated, and if we don't like the
> outcome we can go pound sand.

I think the IETF can develop a position on whether we think what ICANN is doing with the authority we delegated to them makes sense. You are right that we may not be able to do anything about this position other than state it, but we could state it, if we chose. But that wasn't the argument I was making.

The argument I was making is that it's pretty clear that what ICANN has done is bad for the Internet, and that we should not decide whether or not to allocate special use names, or how many to allocate, based on an attitude of deferring to ICANN's greater wisdom on the topic.

If in fact we have any basis for claiming to be able to allocate special use names, then we should just do that, not without taking care to avoid creating unnecessary conflicts, but not with trepidation either.   If we don't, then we should figure that out, and figure out what to do about it, because this whole conversation appears to be based on the premise that we can in fact allocate special use names.