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

"Richard Hill" <rhill@hill-a.ch> Tue, 19 May 2015 05:46 UTC

Return-Path: <rhill@hill-a.ch>
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 AC1991A038F for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 22:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 6ESsC0FNL2tS for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 22:46:29 -0700 (PDT)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A011A038E for <ianaplan@ietf.org>; Mon, 18 May 2015 22:46:28 -0700 (PDT)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t4J5kPLv007216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 19 May 2015 07:46:26 +0200
Received: from RHillNew (adsl-178-39-41-197.adslplus.ch [178.39.41.197]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t4J5kMrd027337; Tue, 19 May 2015 07:46:22 +0200
From: Richard Hill <rhill@hill-a.ch>
To: 'John C Klensin' <john-ietf@jck.com>, 'Milton L Mueller' <mueller@syr.edu>
References: <5550F809.80200@cisco.com> <55511064.2000300@gmail.com> <CAOW+2dvBb4n4W=q7NoO_V1X+JoqvO1TWYBqPAEseY9T7vybj9Q@mail.gmail.com> <CAKFn1SEkBSfk5H5ZjOqfiyaxPak_62cNcRR-SDFH2JJ2HxQumA@mail.gmail.c > <om@mac.com> <59edd953c1d349cfa377bcd72b514b7f@EX13-MBX-13.ad.syr.edu> <C3D17473E06220755959AB78@JcK-HP8200.jck.com> <27ed27614a6b47729043610f09ac197f@EX13-MBX-13.ad.syr.edu> <88F741BF3D4C2A597622A70C@JcK-HP8200.jck.com> <44A0F230-A98C-4060-88E2-B20FE1DE1FC5@isoc.org> <14ff00ba1aae45f2a8f4befb896e2a08@EX13-MBX-13.ad.syr.edu> <D17525F2-190B-4D00-AEBE-5AD96BA79E79@arin.net> <A026656644A030B7130B94B5@JcK-HP8200.jck.com> <ad1d0707ff1b44eb9e48fef18d8e1268@EX13-MBX-13.ad.syr.edu> <687222FF507C0D3EDBD9CAAA@JcK-HP8200.jck.com>
In-Reply-To: <687222FF507C0D3EDBD9CAAA@JcK-HP8200.jck.com>
Date: Tue, 19 May 2015 07:46:24 +0200
Message-ID: <000001d091f7$266de3f0$7349abd0$@ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdCR2B0LD9kgPtN3RYCnE6ojk4fd7gAHc2Ew
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/R24RW7d6adIl7-NoIPX76SpWAqE>
Cc: ianaplan@ietf.org, 'Olaf Kolkman' <kolkman@isoc.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: Tue, 19 May 2015 05:46:31 -0000

Please see embedded comment below.

Thanks and best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:ianaplan-bounces@ietf.org] On Behalf Of John C
> Klensin
> Sent: Tuesday, May 19, 2015 04:04
> To: Milton L Mueller
> Cc: ianaplan@ietf.org; Olaf Kolkman
> Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
> 
> 
> 
> --On Monday, May 18, 2015 15:12 +0000 Milton L Mueller
> <mueller@syr.edu> wrote:
> 
> >> Yes.  See the response I just sent to Olaf, but it seems to me that
> a
> >> "PTI" as a subcontracting arrangement to (more or
> >> less) an internal department is inconsistent with the
> >> (apparent) CWG of separation and independence and,
> >
> > Wrong. This has been explained repeatedly; PTI provides separation, a
> > limited amount of independence and mirrors the relationship numbers
> > and protocols already have.
> 
> As others have pointed out, there is a fundamental difference between
> the IETF relationship (and, to a considerable degree, the RIR
> relationship) with ICANN and the "names community"
> relationship with ICANN.  That differences lies in the distinction
> between "independent actor and customer" and "constituency" (or, more
> accurately, "collection of constituencies".  I'm even putting "names
> community" in quotes, not to be disparaging but to remind you and
> others that the claim that it is single community with common purpose
> often does
> not appear to be true.   PTI doesn't change that.  To the extent
> to which it allows the "names community" to "mirror" the protocol
> relationships [1], the mirror is fairly distorted.
> 
> Rather than looking at this in terms of governance, let's consider the
> more objective relationships associated with how IANA registries are
> created and populated.  For the IETF case, those decisions are made by
> IETF processes, completely outside of ICANN.  IANA has a role to verify
> clarify and consistency of the specifications, but no real decision
> role.  And non-IANA ICANN processes have no role at all.  ICANN, as an
> organization, doesn't even get to review the procedures the IETF uses
> to make those decisions.  By contrast, using the most important of the
> IANA Names registries, the database of top level domains (aka "root
> zone database") as an example, new entries are added to the database
> according to rules established by ICANN (one hopes via bottom-up policy
> development) and then, IIR, approved one at a time by the ICANN Board.
> Delegation changes, e.g., to adjust the servers for a particular TLD,
> also go through ICANN processes.  Once changes are approved, ICANN
> directs IANA to make the registry changes (in the current model, those
> changes go through NTIA review too, but that doesn't change ICANN's key
> role).
> 
> Interestingly, the "names community" doesn't even have final approval
> authority over those changes within the ICANN community and processes
> (again, with or without NTIA).
> 
> In principle, one could change that model to make the "names community"
> relationship with ICANN mirror the IETF one, but doing so would,
> AFAICT, require a much more significant reorganization of ICANN than
> the "2.0" one of circa a dozen years ago.  

I agree with John. If PTI is a wholly owned subsidiary of ICANN, then I
don't see how it provides any meaningful separation.

As John points out, ICANN is the policy-making authority for names, so
mirroring the arrangements for protocol parameters and numbers would require
that ICANN contract with an independent entity for the names part of the
IANA function. And this because the policy authorities for protocol
parameters and numbers contract with an independent entity, ICANN, for their
parts of the IANA function.

PTI as currently conceived is not independent of ICANN, so the proposed
transition for names is not at all comparable to the proposed transition for
protocol parameters and numbers.

I have some trouble understanding exactly what problem the creation of PTI
is supposed to solve.

I don't think that it addresses the number 1 priority issue identified by
the Working Group on Internet Governance back in 2005, namely the asymmetric
role of the USA, because it seems that ICANN and PTI will be based in the US
and subject to US law.

SNIP

> Coming back to my first note in this thread, I see a potential loss of
> accountability in such a transfer because it is difficult to see how
> agreements with the sort of PTI you contemplate could be enforced
> against ICANN if, for some reason, they decided to not supply PTI with
> the resources needed or otherwise constrained PTI's behavior.  You have
> said that there are ways to solve that problem and then indicated that
> the details have not been worked out.  On that basis, I'm not sure why
> the community outside the CWG is being asked to review the draft at all
> until there is a complete proposal.

Indeed, I don't see how one can evaluate a proposal that is missing key
elements, namely the exact legal structure of PTI and who controls it.