Re: [Internetgovtech] Cross community

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 25 July 2014 02:47 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B21A0ADA for <internetgovtech@ietfa.amsl.com>; Thu, 24 Jul 2014 19:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level:
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceOJQ1tdgZ0o for <internetgovtech@ietfa.amsl.com>; Thu, 24 Jul 2014 19:47:16 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE71A0ACA for <internetgovtech@iab.org>; Thu, 24 Jul 2014 19:47:16 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E97F132E52C; Fri, 25 Jul 2014 11:47:13 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7ed7_76ca_d67e0650_9163_4fb5_a345_ff8f6ae2d753; Fri, 25 Jul 2014 11:47:13 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 62666BF4BA; Fri, 25 Jul 2014 11:47:13 +0900 (JST)
Message-ID: <53D1C521.3030809@it.aoyama.ac.jp>
Date: Fri, 25 Jul 2014 11:46:57 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John Curran <jcurran@istaff.org>, S Moonesamy <sm+ietf@elandsys.com>
References: <A193D048-2B67-469A-93BA-C61BB362DA75@vigilsec.com> <53CD1E8A.1060804@acm.org> <FA4238C4-ADDC-435F-9591-E3B074C2F6F6@vigilsec.com> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <B7163126-31B6-4CC6-A711-F225051C294A@istaff.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.20200 00@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org> <6.2.5.6.2.20140724012237.0ce22978@resistor.net> <9DBA0ECE-D26D-463F-858A-B990B68BDDD1@istaff.org> <6.2.5.6.2.20140724084607.0bb21040@elandnews.com> <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org>
In-Reply-To: <9A1009CB-2617-4809-A318-11DCD34E6504@istaff.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/FQC1zpS1y9JyTi0l08qdrJrnXuw
Cc: internetgovtech@iab.org, Avri Doria <avri@acm.org>
Subject: Re: [Internetgovtech] Cross community
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 02:47:19 -0000

On 2014/07/25 05:52, John Curran wrote:
> On Jul 24, 2014, at 1:08 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
>> At 07:16 24-07-2014, John Curran wrote:

>>> Now it is true that these policies are generally technical in nature and
>>> tend to avoid "public policy" positions, but that is not a hard requirement
>>> for either IETF protocols or the associated registries.  For example, it
>>> is possible for the IETF to define a protocol (e.g. an enhancement to DNS)
>>> whereby the protocol itself has some embedded rules for certain identifiers
>>> (e.g. the string "curran" shall always return empty set on any query...)
>>
>> Ok.
>
> i.e. technical registry policy is part of protocol specification; the IETF
> can indeed make a mess of either, but is inclined to try and make it so the
> resulting protocol & registry useful for the Internet.

I think that in general, IETF caring about the technical stuff, and 
ICANN about the political stuff, should work out fine, even where these 
overlap (i.e. TLDs).

But imagine the following, somewhat imaginary but not totally improbable 
scenario:

The IETF is working on some technology that requires a couple of TLDs to 
be reserved for a special purpose. The technology is already partially 
deployed, but not yet extremely widely, and the IETF is standardizing it 
and fixing some stuff that needs fixing for wider deployment.

ICANN is working on a new round of gTLDs or some such. Of course they 
exclude already reserved TLDs, but not stuff that might be coming up 
(because they don't know it).

Now assume that at some point rather late in the game, it gets 
discovered that some names on both sides clash. ICANN already has 
accepted a (significant) amount of money and made some firm promises. 
The IETF technology is already well deployed, and fixes may be costly 
and time-consuming. Each organization and its constituents thinks that 
they were first and therefore think they have priority, and provide 
ample material to support their claims.

What, if any, provisions are there currently to avoid such a problem? 
What, if any, additional provisions would we need to avoid such a 
problem in the future.

Please note that "we can talk to each other" doesn't work here; the 
example is explicitly constructed that way :-(.

Regards,   Martin.