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

Andrew Sullivan <ajs@shinkuro.com> Mon, 29 November 2010 14:38 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 4732328C162 for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 06:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.629
X-Spam-Level:
X-Spam-Status: No, score=-102.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, 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 jCHHRtsRa1Ap for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 06:38:13 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B987828C15B for <dnsop@ietf.org>; Mon, 29 Nov 2010 06:38:12 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B25491ECB41D for <dnsop@ietf.org>; Mon, 29 Nov 2010 14:39:21 +0000 (UTC)
Date: Mon, 29 Nov 2010 09:39:20 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20101129143919.GE33199@shinkuro.com>
References: <20101124142303.GB19441@shinkuro.com> <alpine.LSU.2.00.1011251734170.4075@hermes-2.csi.cam.ac.uk> <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk> <D8E75C03-0322-4594-BB27-D825AB429EA6@hopcount.ca> <C4FB358F-53D1-4A2B-A3A4-1C07222C0B51@dotat.at> <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca> <20101127185010.GB56062@farside.isc.org> <79DC22E8-18BC-44B1-8874-D094844D9E94@dotat.at> <8CEF048B9EC83748B1517DC64EA130FB43E00387CC@off-win2003-01.ausregistrygroup.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB43E00387CC@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: Mon, 29 Nov 2010 14:38:14 -0000

On Mon, Nov 29, 2010 at 10:17:39AM +1100, James Mitchell wrote:
> 1. Requirements on composition of TLDs
> no requirements over and above normal host names
> i.e. can be 1*63 [a-z] [0-9]  and hyphen, cannot start or end with hypen etc..
> [I think we can all agree that the internet will not break if ".8-ball" was added to the root, as to whether it works...]
> 

It seems to me we can all agree that the Internet will not break if
you register a domain name o'reilly.com, either.  But you're not
allowed to, not because of the DNS rules but because of the hostname
rules and a suggestion in the DNS specification that things will go
better if you follow the hostname rules too.  Why not relax that
restriction?  Why should we be beholden to old-timey restrictions?

> For IDNs, must be valid a-label and u-label 

Why?  That seems like it's "just" a policy preference.  Why should the
IETF have anything to say about it?  Why shouldn't the top level
labels also conform to JFC Morfin's Intersem plans, using multiple
[a-z][a-z]-- prefixes?  What basis do we have for telling ICANN what
valid DNS labels they're allowed to pick?
 
> 2.1 RFC1123
> application developers may have made assumptions about composition of domain names; applications may not recognise new TLD. this has been seen with .museum..
> 
> 2.2 Confusion with IP Addresses
> TLDs that begin with a digit may be confused with IP addresses
> TLDs that begin with 0x may be confused with IP addresses
> TLDs that are 0-255 may be confused with IP addresses and thus never looked up in DNS as suggested in RFCxxx
> [perhaps some of these points become restrictions on the composition of TLDs]

Or perhaps, in the interests of making changes near or at the root
incrementally, we adopt the restrictive proposal in the draft and then
write a subsequent one, informed perhaps by more study, that opens the
door wider.
 
> 3. Validation of TLDs
> Application developers should not make assumptions about the composition of TLDs, or the frequency in which they are allocated. if validation is required then looking up the entry in the DNS is a foolproof way to know if a TLD has been allocated. Consideration should be made to reduce queries to the root. Static lists should be avoided.
> 

Note that we already have an RFC that says roughly what (3) says, and
so we don't need to say it again.

A

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