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

Andrew Sullivan <ajs@anvilwalrusden.com> Sun, 17 May 2015 22:08 UTC

Return-Path: <ajs@anvilwalrusden.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 9918B1A1A17 for <dnsop@ietfa.amsl.com>; Sun, 17 May 2015 15:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 7RwqKzHZuJLv for <dnsop@ietfa.amsl.com>; Sun, 17 May 2015 15:08:18 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 379691A066B for <dnsop@ietf.org>; Sun, 17 May 2015 15:08:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id A71611063A for <dnsop@ietf.org>; Sun, 17 May 2015 22:08:17 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU_SVZ-nVLLr for <dnsop@ietf.org>; Sun, 17 May 2015 22:08:16 +0000 (UTC)
Received: from mx2.yitter.info (unknown [IPv6:2400:8901::f03c:91ff:fe37:9daf]) by mx2.yitter.info (Postfix) with ESMTPSA id 13C791060F for <dnsop@ietf.org>; Sun, 17 May 2015 22:08:15 +0000 (UTC)
Date: Sun, 17 May 2015 22:08:12 +0000
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20150517220811.GC8349@mx2.yitter.info>
References: <8EEA3B35-64CB-4960-A58A-7D6B62E11CCF@anvilwalrusden.com> <20150513205135.14395.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150513205135.14395.qmail@ary.lan>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/QhsqQI3UZtAuGd6Lr4B0JykLMLs>
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: Sun, 17 May 2015 22:08:19 -0000

On Wed, May 13, 2015 at 08:51:35PM -0000, John Levine wrote:

> .corp, .home, and .mail, they've only said they're "deferred" and I
> just don't believe that ICANN has the institutional maturity to say no
> permanently.

The point that I keep trying to make is that, if that's what we think,
we should _not_ be attempting to use DNSOP or the special names
registry as a policy-preference enforcement body.  If the issue is
that you don't think ICANN will do the right thing in managing the
policies of the root zone, then you need to go work on ICANN, not try
to use the IETF as a second control.  Doing that puts the IETF itself
in jeopardy.

> So this isn't an ICANN issue, it's an IANA issue.  ICANN can't sell
> .corp, .home, and .mail for the same reason they can't sell .arpa or
> .invalid: they're already spoken for.

But they're _not_ spoken for.  That's the point.  Since the very first
time I even heard of the DNS, everything I ever read said, "Hey, you
can't just pick any name you like.  You need a name you actually
control, and that needs to be registered."  For years, many people the
root was different, because it was not really a moving target.  But
that assumption turned out to be a bad one.

I am susceptible to the argument that there is an operations problem
on the Internet because these things are in wide use and therefore
they ought to be set aside.  And I think it is just fine if the IETF
says, "No, we decided to use this name as a protocol switch and you
need therefore not to delegate it."  But in the former case, one needs
a pretty good argument why we need anything stronger than ICANN's
policy statement that the names are blocked indefinitely -- certainly,
one needs a better argument than "I don't trust ICANN," because it's
already got the policy token.

Best regards,

A

-- 
--
Andrew Sullivan
ajs@anvilwalrusden.com
Awkward access to mail.  Please forgive formatting problems.