Re: [Ianaplan] CWG draft and its impact on the IETF

John Curran <jcurran@istaff.org> Fri, 22 May 2015 11:23 UTC

Return-Path: <jcurran@istaff.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 A2E121A8890 for <ianaplan@ietfa.amsl.com>; Fri, 22 May 2015 04:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
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 4mtvm0Z_h2hg for <ianaplan@ietfa.amsl.com>; Fri, 22 May 2015 04:23:11 -0700 (PDT)
Received: from outbound3.ore.mailhop.org (erouter8.ore.mailhop.org [54.187.218.212]) by ietfa.amsl.com (Postfix) with SMTP id E966B1A8886 for <ianaplan@ietf.org>; Fri, 22 May 2015 04:23:10 -0700 (PDT)
Received: from [192.168.200.106] (unknown [98.252.11.61]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 22 May 2015 11:22:50 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: John Curran <jcurran@istaff.org>
In-Reply-To: <555DE0FE.606@acm.org>
Date: Fri, 22 May 2015 07:23:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <35A9F741-DCC0-48DD-8C54-ABE039D059D0@istaff.org>
References: <ad1d0707ff1b44eb9e48fef18d8e1268@EX13-MBX-13.ad.syr.edu> <687222FF507C0D3EDBD9CAAA@JcK-HP8200.jck.com> <000001d091f7$266de3f0$7349abd0$@ch> <51ce19bc2a93443586adcdd2fac3888a@EX13-MBX-13.ad.syr.edu> <555BD28F.10402@gmail.com> <97E5874491A30994EC386C37@JcK-HP8200.jck.com> <555CEDFF.5010601@gmail.com> <51E8C05D9CFB07754ECD13F5@JcK-HP8200.jck.com> <DM2PR0301MB065543B4DCBCB751656B563DA8C20@DM2PR0301MB0655.namprd03.prod.outlook.com> <a78386a2666240d48be0aba1fb543e75@EX13-MBX-13.ad.syr.edu> <20150521001835.GA18401@mx2.yitter.info> <555DE0FE.606@acm.org>
To: avri@acm.org
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/ClU4s4mfVbw4idMTmX8ZsWSorSM>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
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: Fri, 22 May 2015 11:23:12 -0000

On May 21, 2015, at 9:43 AM, Avri Doria <avri@acm.org> wrote:
> ...
> It is becasue we in ICANN wanted what  IETF has: a contract with ICANN
> that would allow us to part company if things started to go really sour.

That’s not the only thing that a contract provides…  it also provides a way 
of setting clear expectations of satisfactory performance & service levels
as viewed by the contracting party

> But as part of ICANN, we could not simply have a contract with ICANN. 
> Names needed to find a way to have that legal separation that the IETF 
> naturally has.   We went through several ideas, including a brief
> flirtation with Names seceding from ICANN,  

(which in theory would have been a cleaner approach, but in practice is
quite challenging given the history of ICANN and expectations from the
IANA stewardship transition process)

> … but the PTI solution we have
> now put under review  seems the best fit for Names. The PTI  is a
> compromise between those who wanted to leave everything as it was, with
> perhaps more accountability, and those who wanted to form a completely
> separate organization. 
> ...
> Certainly some of us hoped you might consider it because we thought it
> might be better for the Internet if you did join us in the PTI and thus
> joined us in direct oversight of the IANA functions operator.

If the PTI is just performing registry operations services for three communities
under three contracts, then contractual oversight exists and is quite strong…
One wonders why it is necessary to be part of corporate oversight of PTI if
indeed the contractual provisions are properly defined.

>  It seemed
> to some of us that an organization like the PTI  anchored in the three
> organizations would be less susceptible to ICANN capriciousness
> (something we experience much more than you do).  

Isn’t the ICANN’s accountability to the community being already addressed 
via the CCWG efforts?

> With 3 organizations
> overseeing the PTI, we figured it would be certain that there would be
> no policy shenanigans and it would be guaranteed 3 times over that IANA
> stuck to its knitting. But given the separation amongst the 3
> operational communities, this was no more than a hope.

I could see binding PTI via its incorporation/structure to some very basic
principles related to operations of the IANA registry operations, e.g. the
principles in RFC 7500.  Such could also include strong language to the
effect that PTI is only to perform registry operations and not registry policy 
development, that it will operate IANA registries under contract to parties
which represent the affected communities, and that in administration of 
the registries, it will follow the policy adopted by those communities.

These sorts of conditions are factual in nature, and mirror provisions that
are already expected in the various IANA registry service agreements.
(whereas having PTI take on any additional roles or adhere to any other
non-core IANA registry principles simply creates conditions whereby the 
PTI board “oversight” that you seek could result in conflict between PTI and 
contracting community in terms of what is proper IANA registry operations - 
you may see that as a feature but to me it looks to be introduction of noise
into the system…)

/John

p.s. my views alone.  To my knowledge, neither the ARIN Board nor community 
has considered this matter and/or established any position in same.