Re: Update of RFC 2606 based on the recent ICANN changes ?

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 29 June 2008 21:49 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECE53A69B1; Sun, 29 Jun 2008 14:49:32 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCFA3A69B1 for <ietf@core3.amsl.com>; Sun, 29 Jun 2008 14:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.305
X-Spam-Level:
X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599]
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 MgG1jEFP+u7b for <ietf@core3.amsl.com>; Sun, 29 Jun 2008 14:49:29 -0700 (PDT)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 7D9743A69AF for <ietf@ietf.org>; Sun, 29 Jun 2008 14:49:29 -0700 (PDT)
Received: by wa-out-1112.google.com with SMTP id k34so1189019wah.25 for <ietf@ietf.org>; Sun, 29 Jun 2008 14:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TQULr/x86+7sdK5X6urhmgQ7OcVigo8kDFnir51ksQk=; b=JdSY7wr6XknP3mYLXYCpMSIpP0E/m0+fe7ApWl0eVrWxKY6FbZrYX9JH04QeXJ+tQY qpm11SOk90YifWCKEC7xXJ1fVfRm0nUEfogp44xkJ90Rm8w4lzdPs1RbGgPOY+2J2XLE HhsNSVR4LIcC0E/RSaUBNSC1gajjNV7b23QIo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nAGzNNiJHowXIy7x31p1hKzEeilqs4xWkBHfqTbMYyLZhCjVmYb65o7PPxtEooxjVX BoP2BenSD71yrgveGIMm/48I3RYZnyL10Y3NlIiN3vRlGuo+Qrvy0tBs06qgFJGO4RaX WF1oBK2kmA0BfBO9mWIekse6k/zgYamkJIQaM=
Received: by 10.114.130.1 with SMTP id c1mr3359859wad.152.1214776179498; Sun, 29 Jun 2008 14:49:39 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id m34sm4974823waf.20.2008.06.29.14.49.37 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Jun 2008 14:49:38 -0700 (PDT)
Message-ID: <4868036E.5080403@gmail.com>
Date: Mon, 30 Jun 2008 09:49:34 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: SM <sm@resistor.net>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
References: <4C0AE13D-4CA6-4989-A6B0-555A014DE464@multicasttech.com> <74E3E26A-FCFB-45C1-989A-DD7EA5752974@virtualized.org> <6.2.5.6.2.20080627121824.02c55340@resistor.net> <BBB8E0B4-7E45-4BE9-B9DF-DEBE294585D6@multicasttech.com> <6.2.5.6.2.20080627140118.02a43fd8@resistor.net> <6F1CFDA0-A6E2-4257-8C72-0FCD1E117290@virtualized.org> <6.2.5.6.2.20080628201322.02e43268@resistor.net>
In-Reply-To: <6.2.5.6.2.20080628201322.02e43268@resistor.net>
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On 2008-06-29 16:35, SM wrote:
> At 16:18 27-06-2008, David Conrad wrote:
>> A TLD of all numbers would be a real pain to deal with.  That is, from
>> a software parsing perspective, what's the difference between the
>> domain name "127.0.0.1" and the IP address "127.0.0.1"?
> 
> The domain name may be confused with an IP address.  That can be avoided
> by not allocating numbers from zero to 255 as TLDs.  There was a recent
> thread on the IDNA mailing list about other representations of IPv4.
> 
>> Because, as you've indicated with the .local example above, protocol
>> actions can result in technical justification why a particular label
>> used as a TLD could be problematic.  An IANA registry defining these
>> that ICANN can point to and tell applicants "no, because it is in the
>> IETF-defined 'bad' list" would likely be helpful.
> 
> The IETF can only publish such a list for protocols within IETF's scope,

Nonsense. The IETF can reserve any TLDs for technical reasons that
need to be reserved for technical reasons (subject to IETF consensus,
of course).

    Brian

> i.e. Internet protocol parameters only as directed by the criteria and
> procedures specified in RFCs, including Proposed, Draft and full
> Internet Standards and Best Current Practice documents, and any other
> RFC that calls for IANA assignment.  That covers assignments of domain
> names for technical uses (such as domain names for inverse DNS lookup),
> (b) assignments of specialised address blocks (such as multicast or
> anycast blocks), and (c) experimental assignments.
> 
> That's different from an IETF-based "bad" list.  .local can be covered
> once a RFC meeting the criteria is published.  It doesn't fall under RFC
> 2606.  That RFC lists top level
> domain names reserved for use in private testing, as examples in
> documentation, and the like.
> 
> Regards,
> -sm
> 
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf