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

David Conrad <drc@virtualized.org> Fri, 27 June 2008 23:18 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 1D3B33A68FB; Fri, 27 Jun 2008 16:18:47 -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 94EE43A68FB for <ietf@core3.amsl.com>; Fri, 27 Jun 2008 16:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 awrI+f7hZqVH for <ietf@core3.amsl.com>; Fri, 27 Jun 2008 16:18:45 -0700 (PDT)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id E575E3A681F for <ietf@ietf.org>; Fri, 27 Jun 2008 16:18:45 -0700 (PDT)
Received: from [10.0.1.198] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 1008D25FC6B; Fri, 27 Jun 2008 16:18:51 -0700 (PDT)
Message-Id: <6F1CFDA0-A6E2-4257-8C72-0FCD1E117290@virtualized.org>
From: David Conrad <drc@virtualized.org>
To: SM <sm@resistor.net>
In-Reply-To: <6.2.5.6.2.20080627140118.02a43fd8@resistor.net>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Date: Fri, 27 Jun 2008 16:18:50 -0700
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>
X-Mailer: Apple Mail (2.924)
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Jun 27, 2008, at 3:22 PM, SM wrote:
> It would cause problems if .local was given out.  I don't recall  
> seeing any RFC requesting IANA to reserve it.

Right.

>> - a label consisting of all numbers
> We already have 888.com.  Some users may ask for .888 given its  
> significance in some cultures.

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"?

> I cannot find a technical reason against PAYPAI.c0m.

Right.  There is a policy reason ("confusingly similar"), but that's  
not a technical, e.g., protocol reason.

> If such a technical review process is doomed, then why should the  
> IETF get into defining technical guidelines outside the ".example"  
> examples?

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.

Regards,
-drc

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