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

Ole Jacobsen <ole@cisco.com> Wed, 02 July 2008 16:33 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 E09193A6AFD; Wed, 2 Jul 2008 09:33:07 -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 854C33A6AFD for <ietf@core3.amsl.com>; Wed, 2 Jul 2008 09:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level:
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 JG5JVHIKRwBn for <ietf@core3.amsl.com>; Wed, 2 Jul 2008 09:33:06 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B75703A6910 for <ietf@ietf.org>; Wed, 2 Jul 2008 09:33:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,738,1204502400"; d="scan'208";a="47840521"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2008 16:33:16 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m62GXGAU001292; Wed, 2 Jul 2008 09:33:16 -0700
Received: from pita.cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m62GXGvb006552; Wed, 2 Jul 2008 16:33:16 GMT
Date: Wed, 02 Jul 2008 09:30:06 -0700
From: Ole Jacobsen <ole@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
In-Reply-To: <p0624081cc4915ab876b2@[10.20.30.162]>
Message-ID: <Pine.GSO.4.63.0807020927290.12027@pita.cisco.com>
References: <4C0AE13D-4CA6-4989-A6B0-555A014DE464@multicasttech.com> <74E3E26A-FCFB-45C1-989A-DD7EA5752974@virtualized.org> <6.2.5.6.2.20080627121824.02c55340@resistor.net> <A9ACF7FB-BC78-44D9-AA61-4FCACE821677@virtualized.org> <9486A1E5-864F-4B23-9EBA-697C1A7A7520@ca.afilias.info> <200807012051.m61KpLeq021685@cichlid.raleigh.ibm.com> <105D288AF30DA6D8EE55976A@p3.JCK.COM> <200807021417.m62EHckw017869@cichlid.raleigh.ibm.com> <p0624081cc4915ab876b2@[10.20.30.162]>
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=569; t=1215016396; x=1215880396; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ole@cisco.com; z=From:=20Ole=20Jacobsen=20<ole@cisco.com> |Subject:=20Re=3A=20Update=20of=20RFC=202606=20based=20on=2 0the=20recent=20ICANN=20changes=20? |Sender:=20; bh=qHPJ69A0NlTD+LGfTTFcaq3RDpDfyhsgwMi0tCk7otA=; b=X9UcEdQXMLtdxFM+L+zZHk24h2099CjUamzcwoZbvz0GU+cDyoXXtbWbpO p0j1TsqOsWZ9aksYKML+O8vv4Pl82qN803EABWZ+bGQcwzzdvk5xcHf7RQn+ Ce85bAx60f;
Authentication-Results: sj-dkim-2; header.From=ole@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: The IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Ole Jacobsen <ole@cisco.com>
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

Paul,

But it is still the case that an application for say .local would need 
to go through some review process (regardless of price) which would 
include input from the IETF ICANN rep. I see little reason why or how
a TLD that would be damaging, confusing, or otherwise "bad" for the 
IETF would/could just "slip through" this process.

What am I missing here?

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: ole@cisco.com  URL: http://www.cisco.com/ipj



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