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

James Mitchell <james.mitchell@ausregistry.com.au> Wed, 17 November 2010 13:06 UTC

Return-Path: <james.mitchell@ausregistry.com.au>
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 916CC3A68F6 for <dnsop@core3.amsl.com>; Wed, 17 Nov 2010 05:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 bmwHDXJauyY3 for <dnsop@core3.amsl.com>; Wed, 17 Nov 2010 05:06:50 -0800 (PST)
Received: from mx10-1.ausregistry.net.au (mx10-1.ausregistry.net.au [202.65.12.90]) by core3.amsl.com (Postfix) with ESMTP id 56D6F3A68F3 for <dnsop@ietf.org>; Wed, 17 Nov 2010 05:06:50 -0800 (PST)
Received: from off-win2003-01.ausregistrygroup.local (off-win2003-01.stkildard.vic.ausregistry.com.au [10.30.1.3]) by mx10-1.ausregistry.net.au (8.13.8/8.13.8) with ESMTP id oAHD7PT1001580; Thu, 18 Nov 2010 00:07:26 +1100
Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 18 Nov 2010 00:07:24 +1100
From: James Mitchell <james.mitchell@ausregistry.com.au>
To: Andrew Sullivan <ajs@shinkuro.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Date: Thu, 18 Nov 2010 00:08:13 +1100
Thread-Topic: [DNSOP] draft-liman-tld-names-04
Thread-Index: AcuGUalDV3K30fqTSCyzNbjL9lqeugAAgzoQ
Message-ID: <8CEF048B9EC83748B1517DC64EA130FB43C309F821@off-win2003-01.ausregistrygroup.local>
References: <4CE0F829.1010605@necom830.hpcl.titech.ac.jp> <7F03C666-16F8-49E4-BC56-F5DD441DD970@frobbit.se> <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>
In-Reply-To: <20101117121906.GC3773@shinkuro.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 13:06:51 -0000

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? And if you tell me that 3com can compromise and apply for a 'valid' TLD, then what happens should/when we change the rules to allow these characters in TLDs? "Sorry 3com, the first time we didn't want to punish the people who made assumptions about the composition of TLDs". The people who are punished are the applicant, 3com, because their TLD does not work!

With that said, I'm fairly certain that the ICANN Draft Applicant Guidebook by tells applicants that their TLD may not work. I don't quite see how the IETF (don't want to break existing applications) and ICANN (it might not work, no comment on when it will as it is up to application developers) align.

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. Removing the spaces will cause the characters to join, and the meaning lost (besides which the A-label will contain hyphens anyway?!). I'm far from qualified to talk authoritatively on the Arabic script, or how it will be used in domain names, however I do know of parties that will be applying for Arabic TLDs - are we to exclude these applicants?

My thoughts are this draft should re-iterate the requirement "The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System", clarify whether dotted decimal includes .256+, and mention that any TLD may not work due to assumptions on the composition of a TLD in applications not conforming to this RFC. It should even give guidance into how one should 'validate' TLDs so this does not happen in the future; i.e. update from IANA.

James

> -----Original Message-----
> From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of
> Andrew Sullivan
> Sent: Wednesday, 17 November 2010 11:19 PM
> To: dnsop@ietf.org
> Subject: Re: [DNSOP] draft-liman-tld-names-04
> 
> On Wed, Nov 17, 2010 at 11:20:56AM +0000, Tony Finch wrote:
> > I believe that no requirement needs to be relaxed to allow A-labels. A
> > clarification might be helpful.
> 
> If no requirement is needed, then no document is needed, because the
> policy realm was ceded to ICANN some years ago.  We can remain quiet
> and wait for someone at ICANN to write a document somewhere that
> clarifies that they have changed the policy that used to be expressed
> in RFC 1123.
> 
> > That is blatantly broken. There is no need for any heuristic to tell IP
> > addresses and host names apart. This kind of code should be mocked, not
> > accommodated.
> 
> To my mind, this is a way of saying that anyone who has to live with
> broken implementations by people who half-understand the huge volume
> of DNS-related RFCs is just sweet out of luck.  Too bad for them.  Is
> that really what we want to say?
> 
> A
> --
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop