Re: [Ianaplan] Fwd: For your Information: CWG-Stewardship Response for Chartering Organization Consideration and Approval

Avri Doria <avri@acm.org> Sat, 20 June 2015 01:34 UTC

Return-Path: <avri@acm.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 C96731B2C58 for <ianaplan@ietfa.amsl.com>; Fri, 19 Jun 2015 18:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 CjDOevY1YbQv for <ianaplan@ietfa.amsl.com>; Fri, 19 Jun 2015 18:34:08 -0700 (PDT)
Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id C39C01B2C57 for <ianaplan@ietf.org>; Fri, 19 Jun 2015 18:34:08 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t5K1Y690002580 for <ianaplan@ietf.org>; Fri, 19 Jun 2015 21:34:06 -0400
Received: (qmail 4113 invoked by uid 0); 20 Jun 2015 01:34:06 -0000
X-TCPREMOTEIP: 199.91.199.228
X-Authenticated-UID: avri@ella.com
Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@199.91.199.228) by 0 with ESMTPA; 20 Jun 2015 01:34:06 -0000
Message-ID: <5584C304.9000806@acm.org>
Date: Fri, 19 Jun 2015 22:33:56 -0300
From: Avri Doria <avri@acm.org>
Organization: Technicalities
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: ianaplan@ietf.org
References: <D1A45F80.1B274%grace.abuhamad@icann.org> <90E3156B-428B-4A61-92B7-BAC932842FB5@viagenie.ca> <557F63E2.40302@gmail.com> <20150619155355.GI17513@mx2.yitter.info> <55847B53.60106@gmail.com>
In-Reply-To: <55847B53.60106@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 150619-3, 06/19/2015), Outbound message
X-Antivirus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/9LDXnuBdGwx5TaX1Xj_OurJuwVU>
Subject: Re: [Ianaplan] Fwd: For your Information: CWG-Stewardship Response for Chartering Organization Consideration and Approval
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: avri@acm.org
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: Sat, 20 Jun 2015 01:34:10 -0000

Hi,

I do not think there is any notion of the Naming community thinking it
is more important than the other communities.  It just think that Names
can only speak for itself.  In fact that sort of operational community
myopia is something we learned through this process, as I have mentioned
before some of us hoped for a tripartite ownership of the PTI.

- as I understand it,  the functions performed by IANA are not easily
partitionable among  separate IANA Staff.   They seem to work with a
lean staff and each seem to each cover a multitude of tasks.  While it
seems true that some specialize in one more than the others, they seem
to work as a team and back each other up.  The division into operational
communities that we put so much significance into are not quite as
divided among the staff members of IANA.

- nether do I understand the  physical assets &c. to be divided along
operational community division lines.

- nor do I understand the financing of the IANA functions to be divided
along operational community lines.

- beyond that, it appears that ICANN will remain the service provider
for the Number and Protocol operational communities as they will remain
ICANN customers, at least for the present, and ICANN will utilize its
subsidiary, the PTI (all things being equal) for the their functions as
well as for the Naming community functions.

It is therefore hard for me to imagine that the assets that PTI needs to
do its job not be retained by ether the entity that is service provider
for two of the customers and home for one of them or the wholly owned
entity doing the work for all 3 operational communities.

I admit that despite the respect I have for the IETF and its Trust,
given that the Trust's fiduciary responsibilities are solely to the
IETF, I argue that the IANA domain names and any trademarks associated
with them should be transferred to the PTI along with the other assets
necessary for doing its job.  And if that can't happen, then remaining
with ICANN seems the next best option to me.

I do agree with those who question the license being for exclusive
ICANN/PTI use.  Not being a lawyer of any sort, I will look into the
reasons given for the exclusive license and see if can find any
reasonable basis for it.  I tend to think that this is something that
should/could probably be adjusted on ICG recommendation.

avri






On 19-Jun-15 17:28, Brian E Carpenter wrote:
> Hi Andrew,
> On 20/06/2015 03:53, Andrew Sullivan wrote:
>> On Tue, Jun 16, 2015 at 11:46:42AM +1200, Brian E Carpenter wrote:
>>
>>> "The existing IANA functions department, administrative staff, and
>>> related resources, processes, data, and know-how will be legally
>>> transferred to PTI.[8]
>>>
>>> [8] In the case of any existing ICANN contracts, MoUs or other
>>> arrangements that relate to the IANA functions, these could be
>>> assigned to and assumed by PTI, replaced by new arrangements at
>>> the PTI level or remain at ICANN with a subcontract to PTI."
>>>
>>> That appears to be suggesting that the entirety of IANA, not just
>>> the naming functions, should be transferred to PTI. That seems
>>> to be beyond the claimed scope of the proposal.
>> I don't think it is a scope problem.  On my reading, the CWG's
>> proposal in effect has two parts:
>>
>>     1.  The IANA functions MUST move from ICANN to some other
>>     organization.  This provides a separation of the
>>     naming-policy-community organization from the organization that
>>     delivers IANA.  The idea is that this is a necessary condition for
>>     the rest of the proposal.
> Yes, and it doesn't in effect say "IANA naming functions MUST move". So that
> seems to cover the entire scope, not just the names community's scope. And the
> footnote [8] makes that very clear.
>
> It may be a necessary condition for the rest of the proposal, but I find
> it disingenuous that it doesn't explicity acknowledge that all three
> communities would be impacted. It's almost as if the names community
> thinks it's more important.
>
> Rgds
>    Brian
>
>>     2.  The details of how the naming community wants to interact with
>>     the resulting IANA functions operator.
>>
>> The limitation of scope is really over (2), and not (1).
>>
>> At least, that's how I interepret the proposal.
>>
>> Best regards,
>>
>> A (as ever, speaking just for me)
>>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus