Re: [Ianaplan] Transition proposal for naming-related functions

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 04 May 2015 21:13 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BD51B2B7B for <ianaplan@ietfa.amsl.com>; Mon, 4 May 2015 14:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.664
X-Spam-Level:
X-Spam-Status: No, score=-96.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 rx22Pd8YzjIp for <ianaplan@ietfa.amsl.com>; Mon, 4 May 2015 14:13:49 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E601B2C4D for <ianaplan@ietf.org>; Mon, 4 May 2015 14:13:49 -0700 (PDT)
Received: from [192.168.178.28] (x590f0478.dyn.telefonica.de [89.15.4.120]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 19C2D6369F; Mon, 4 May 2015 23:13:47 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=lIET6XyO2Ka8P+9GufpK+gfOw9IclNeajmNgpGO2v2enrhY8h/NnmrEEFTbMkkk5b9bPvXFkFLFLl6mCDzkJL/OGQzH6jpN18hZVtWWO6q1fCugmaoTeYGUbT1631p/hc18ygDHfldaaLsuYSkKBSOaIXQr2sFbv8O2O+YFmHe4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type;
Message-ID: <5547E10A.3000104@gondrom.org>
Date: Mon, 04 May 2015 23:13:46 +0200
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: steve@shinkuro.com, alissa@cooperw.in, ianaplan@ietf.org
References: <6FADE19B-E3BD-48F8-9A2D-91FA6F88E6DC@cooperw.in> <554637C4.2010400@gondrom.org> <64F5CADC-5739-4CB1-B2E3-BAA3B21DA0EB@cooperw.in> <C6F030D4-58DF-4B2B-969E-6D4F2B00C742@shinkuro.com>
In-Reply-To: <C6F030D4-58DF-4B2B-969E-6D4F2B00C742@shinkuro.com>
Content-Type: multipart/alternative; boundary="------------010706090906010503000002"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/LHTAJrozMWmBdsExIp_RtZw9quI>
Subject: Re: [Ianaplan] Transition proposal for naming-related functions
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2015 21:13:50 -0000

Steve,

thank you for the clarification.
With my individual participant hat on: I agree with your view and if not 
too inconvenient, it might indeed be useful to add text to this effect 
to make it more clear and explicit and avoid misunderstandings if read 
by others without our historical context many years from now...

Best regards, Tobias


On 04/05/15 22:56, Steve Crocker wrote:
> Alyssa, Tobias, et al,
>
> We normally take time internally to coordinate our formal statements, 
> but I consider this particular detail to be unambiguous, settled long 
> ago, and something I spoke forcefully about at the IETF meeting in 
> London, so I’ll speak immediately on this list.
>
> ICANN publishes the IANA registries for anyone to use without charge, 
> and it asserts no ownership or control of the information in the 
> registries.  No matter what additional structures are created, this 
> basic rule must continue.  There are no subtle or hidden meanings 
> here, and if anyone manages to see an ambiguity, I can assure you none 
> is intended and we will be happy to restate this in language that 
> removes the perceived ambiguity.  Anything less would be inconsistent 
> with the spirit, history and ethic of the IANA function.
>
> Steve Crocker
> Chair, ICANN Board of Directors
>
>
>
>
>
> On May 4, 2015, at 4:42 PM, Alissa Cooper <alissa@cooperw.in 
> <mailto:alissa@cooperw.in>> wrote:
>
>> Hi Tobias,
>>
>> On May 3, 2015, at 7:59 AM, Tobias Gondrom 
>> <tobias.gondrom@gondrom.org <mailto:tobias.gondrom@gondrom.org>> wrote:
>>
>>> Dear Alissa,
>>>
>>> just a small question for my understanding:
>>> as the proposal speaks about ownership and transferring data to PTI 
>>> for naming functions, but also mentions possible implications for 
>>> non-naming functions. Is there any implicit assumption that such a 
>>> PTI entity would aspire ownership or copyright for the data in the 
>>> IANA registries?
>>>
>>> Would it make sense that we make it more clear in the context of 
>>> this proposal that PTI is not assuming ownership of that data?
>>
>> With my individual participant hat on, I would say that yes it would 
>> make sense. I haven’t looked into these provisions of the draft 
>> proposal in detail but in my brief reading it seemed like it wasn’t 
>> entirely clear what the expectation is as far as ownership/copyright 
>> of the data in the registries.
>>
>> Alissa
>