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

John C Klensin <john-ietf@jck.com> Tue, 19 May 2015 02:04 UTC

Return-Path: <john-ietf@jck.com>
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 4ABD31B2CFD for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 19:04:14 -0700 (PDT)
X-Quarantine-ID: <PLlOsIMvseVB>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...T7vybj9Q@mail.gmail.com>\n \n <CAKFn1SEkBSf[...]
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 PLlOsIMvseVB for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 19:04:12 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5213D1B2CF2 for <ianaplan@ietf.org>; Mon, 18 May 2015 19:04:12 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YuWt2-000Ovb-Qy; Mon, 18 May 2015 22:04:04 -0400
Date: Mon, 18 May 2015 22:03:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Milton L Mueller <mueller@syr.edu>
Message-ID: <687222FF507C0D3EDBD9CAAA@JcK-HP8200.jck.com>
In-Reply-To: <ad1d0707ff1b44eb9e48fef18d8e1268@EX13-MBX-13.ad.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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/CJLRwF1aYotebDJ7tVsdjPQu-AE>
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 02:04:14 -0000


--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.  To the best of my knowledge, a reorganization of
that sort is not on the table.  In my personal opinion, while it
might be desirable, trying to disguise it as part of this
particular transition would be unwise and far exceeds the
mandates of the various transition-related groups.

>...
> Except that you have not provided any plausible reasons why
> they shouldn't. The numbers contract doesn't exist yet and
> thus could easily specify either ICANN or PTI as its
> counterparty. The protocols MoU and SLA could be assigned to
> PTI without any change in its substance. 

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.  

The question of whether you and the "names community" have to
demonstrate to other communities, e.g., what problems the PTI
model would solve or whether they need to convince you that it
is defective is not one that is likely to achieve more clarity
by either of us repeating ourselves.

> As I've said before, there will be an independent-affiliate
> PTI or there won't be a transition in the next two years. Take
> your pick. 

If you are speaking for the "names community", that puts us in
an interesting position.  Stressing that I'm speaking for myself
only, one of my concerns about various forms of ICANN
reorganizations and assertions of authority (disguised as
"transition" or not) is that, if not managed very carefully and
with careful consideration and protection of the roles in the
Internet of other bodies, changes could turn into mechanisms for
the "names community" and/or "domainer interests" to bully those
other bodies.  

If the position of CWG and the "names community" more broadly is
"we either get our way or we will make sure that no agreement is
reached" -- and "PTI as we have defined it or no transition"
seems to be just that--  then that concern is already validated
and puts those other bodies and communities in a position in
which a transition is actually unwise unless strong protections
against "names community"-driven excesses or decisions that
benefit that community and not the Internet are built into the
system.  

Because I think a transition away from the present NTIA role
would be a good idea, I hope that is not where we are headed.

best,
   john


[1] I know far more about the situation in the IETF wrt
protocols and protocol-associated registries than I do about the
address registries or mechanisms within the RIRs, so will focus
on the former.