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

SM <> Sun, 29 June 2008 04:37 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 304EC3A681C; Sat, 28 Jun 2008 21:37:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 432213A688C for <>; Sat, 28 Jun 2008 21:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.657
X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=3.256, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HqMEbFk1Htth for <>; Sat, 28 Jun 2008 21:37:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 612593A681C for <>; Sat, 28 Jun 2008 21:37:33 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id m5T4bPR0028806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jun 2008 21:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1214714259; x=1214800659; bh=8Omd231RUiJ+IlNsSFJuRA087vtx+XksSC0K 3oyBFqQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=tBal7kypgkVveGEtAM0IOaW1pa tk1SPgWLbKLAkTDU/VKm4bTMB0Ord0fUCXOuZwZ4KgRJMbAwIWIgHj+fnmK5DPFE/R5 c1lV0qDE61OIaKSzZUiMG6jsA3tC6UEn4sTHYuO7l6O23ipKixbuNUo/pcuXTJKhn6R bwIqvav93UU=
DomainKey-Signature: a=rsa-sha1; s=mail;; c=simple; q=dns; b=pV0ba0hdaYuRzXN27L7dtqW7+sqzxdwgQJoVLkzeVQgYGxY+zqYdatfwAMTnDpgeI SnL0yTgC+lJobB57EO8wtxpVGThRMfGsk8cNiIqZPB8NyZlZ0aBTMK+xwRKKmsGMD7p Fnds/aB/CMjwWM3KqF5JYOl1ZXxUL+WTCz3t8S0=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sat, 28 Jun 2008 21:35:36 -0700
To: David Conrad <>
From: SM <>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-Reply-To: <>
References: <> <> <> <> <> <>
Mime-Version: 1.0
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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 "" and the IP address ""?

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, 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.


Ietf mailing list