2606bis (was: .local)

Frank Ellermann <nobody@xyzzy.claranet.de> Wed, 19 October 2005 06:38 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7av-0003bS-88; Wed, 19 Oct 2005 02:38:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES7as-0003bI-Eb for ietf@megatron.ietf.org; Wed, 19 Oct 2005 02:38:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24701 for <ietf@ietf.org>; Wed, 19 Oct 2005 02:38:24 -0400 (EDT)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES7mY-0000Xi-ED for ietf@ietf.org; Wed, 19 Oct 2005 02:50:39 -0400
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ES7ZB-00050H-6f for ietf@ietf.org; Wed, 19 Oct 2005 08:36:49 +0200
Received: from pd9fbad0c.dip0.t-ipconnect.de ([217.251.173.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 19 Oct 2005 08:36:49 +0200
Received: from nobody by pd9fbad0c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf@ietf.org>; Wed, 19 Oct 2005 08:36:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Wed, 19 Oct 2005 08:33:08 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 54
Message-ID: <4355E8A4.7634@xyzzy.claranet.de>
References: <Pine.LNX.4.61.0509191647510.23762@internaut.com> <p0620074fbf5509dd070a@[192.168.2.2]> <Pine.LNX.4.61.0509192043550.28535@internaut.com> <4333DDFF.8020909@zurich.ibm.com> <4333F545.7619@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fbad0c.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Subject: 2606bis (was: .local)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> How about adding it to 2606 ?  2606bis could add a note that
> ".local" might be used for local purposes specified elsewhere

There is now a 2606bis draft, but it doesn't mention .local :
<http://ietf.org/internet-drafts/draft-eastlake-2606bis-00>

This memo quotes an agreement between ICANN and VeriSign about
gTLD .net published in 

<http://www.icann.org/tlds/agreements/net/net-registry-agreement-01jul05.pdf>

While that's all fine for gTLD .net and all TLDs with similar
agreements it's somewhat strange for other TLDs:

What's wrong with any "labels at all levels" matching one of
aso, gnso, icann, internic, ccsno, afrinic, apnic, arin,
example, gtld-servers, iab, iana, iana-servers, iesg, ietf,
irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers ?

Where's the technical problem with one of these strings in an
SLD or elsewhere ?  What's the technical purpose of reserving
these strings everywhere ?  When did all ccTLDs agree to this
arrangement ?  

This draft references the informational RfC 1591 as normative.
So far I thought that 1591 in essence says that the internal
business of a TLD is, well, its internal business.

E.g. it's not obliged to offer a whois server no matter what
ICANN's agreements with other TLDs like .net might say.

For chapter 3.3 the purpose is clear, but xn-- is not more
reserved, it's already used as specified elsewhere.

3.4 is also clear:  FQDN whois.sc is a Bad Thing, because it's
unrelated to a whois server of ccTLD .sc  OTOH one reserved SLD
nic could be good enough for all TLDs, an inflation of reserved
SLD labels doesn't help (?)

3.2 prohibits single characters as SLD.  What's the technical
purpose of this prohibition ?  It also prohibits two characters
as SLD unless the government of the corresponding ccTLD, or if
that doesn't exist the ISO 3166 MA allow it.

What on earth has ISO 3166 to do with SLDs ?  They are ignorant
about ccTLDs as demonstrated by CS.  Numerous SLDs using two
characters, country codes, letters, or else, exist.  If ICANN
doesn't allow this in its agreements it's fine, but where is
the technical reason to prohibit something like http://a9.com
or http://ix.de ?  (Yes, the latter is a legacy case under
DENIC rules, but so far this is no BCP affecting all TLDs.)

                        Bye, Frank



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf