Re: [DNSOP] draft-liman-tld-names-04

Andrew Sullivan <ajs@shinkuro.com> Wed, 17 November 2010 16:45 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B31E3A6939 for <dnsop@core3.amsl.com>; Wed, 17 Nov 2010 08:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.639
X-Spam-Level:
X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltqcIY0+hBIq for <dnsop@core3.amsl.com>; Wed, 17 Nov 2010 08:45:23 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 190DA3A6936 for <dnsop@ietf.org>; Wed, 17 Nov 2010 08:45:23 -0800 (PST)
Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6B3A91ECB436 for <dnsop@ietf.org>; Wed, 17 Nov 2010 16:46:04 +0000 (UTC)
Date: Wed, 17 Nov 2010 11:45:55 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20101117164552.GA3990@shinkuro.com>
References: <4CE1A110.1060403@necom830.hpcl.titech.ac.jp> <20101115213532.GD322@shinkuro.com> <04856F66-598D-43CC-8164-90178A6F2952@virtualized.org> <4CE283DA.5080606@abenaki.wabanaki.net> <20101116145308.GG1389@shinkuro.com> <alpine.LSU.2.00.1011161601450.14239@hermes-2.csi.cam.ac.uk> <20101116164818.GN1389@shinkuro.com> <alpine.LSU.2.00.1011171101250.14239@hermes-2.csi.cam.ac.uk> <20101117121906.GC3773@shinkuro.com> <8CEF048B9EC83748B1517DC64EA130FB43C309F821@off-win2003-01.ausregistrygroup.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB43C309F821@off-win2003-01.ausregistrygroup.local>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] draft-liman-tld-names-04
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 17 Nov 2010 16:45:24 -0000

This is on dnsop, but just to be clear: for this and all the other
messages I've sent in this thread, no hat.

On Thu, Nov 18, 2010 at 12:08:13AM +1100, James Mitchell wrote:

> Do we really want to say to 3com (probably a bad example, but go
> with the concept) that they cannot have a TLD when their competitors
> can? 

That is None Of Our Business.

What this draft does is expand the previous rules about TLDs in the
DNS in the absolute minimum way necessary to allow new TLDs using
IDNA2008.  It won't allow every possible TLD, in exactly the way that
every possible LDH TLD is maybe or maybe not permitted by the RFC.

The only avenue open to people who think this draft should not be
published is to claim that the "will be alphabetic" claim in RFC1123
is not and never was an assertion to the rest of the network about
what assumptions they might legitimately make about TLDs.  In other
words, you have to argue that the assertion "will be alphabetic" was
(only) a statement of policy in force at the time; that such policy
was clearly defeasible; and that the policy has been quite plainly
overtaken by a new policy as determined by the relevant policy makers.
I'm actually mostly comfortable with such an argument, but there are
plenty of people who aren't.  I say "mostly" because I don't think the
policy people at ICANN have made anything about this topic even
remotely clear, including that they think they are changing a rule in
RFC 1123 and that they're doing it deliberately.  (This is not to
attack ICANN: they have their own problems, and I'm sympathetic.)
Note that some people in this thread are making that argument quite
clearly; I think it's an entirely reasonable position to take, though
I don't happen to share it.

If you think that we do in fact need an update to 1123 to clarify
things, then there is nothing at all wrong with publishing this
document right now, in order to allow the minimum necessary, and then
revisiting the question more completely (ideally, suggesting to ICANN
participants or staff that clear claims about the boundary between
policy and protocol here from their quarter would also be useful,
recognizing that there will be some disagreements and need to work
things out).

When 1123 was written, the Internet was in the early phases of the
commercial explosion.  We're past that now, and conditions are
obviously different.  But we have to deal with the fact that we have a
deployed system with a lot of different things dependent on the
historical behaviour.  Part of our responsibility, _particularly_ in
the operations end of the IETF "technical community", is to recommend
prudent and cautious development of the operational conventions on the
network: the line between policy and protocol has not always been
bright.  The closer we get to the thing that everyone depends on (and
the contents of the root zone are surely within spitting of
"everyone"), the more conservative we have to be.  And yes, that
sometimes means that we need to recommend prudence even if it isn't
desirable to particular interests.

> As a thought, consider names written in the Arabic script. Being a
> cursive script, how is a TLD applicant expected to separate 'words'
> in a top level domain without the use of a hyphen or
> equivalent.

They already have a problem, because DNS labels aren't words.  They're
mnemonics, perhaps, but not words.  The publisher, O'Reilly, isn't
going to be able to get .o'reilly either, no matter what we do: it's
not allowed by the traditional LDH rule and it doesn't fall under
IDNA2008.  Is this discrimination?  Only in the traditional meaning of
"applying correct discernment", I say.

Regards,

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.