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

Roger Jørgensen <rogerj@gmail.com> Wed, 13 May 2015 09:08 UTC

Return-Path: <rogerj@gmail.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 9232A1AC411 for <ianaplan@ietfa.amsl.com>; Wed, 13 May 2015 02:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 LUamiEI1BIDO for <ianaplan@ietfa.amsl.com>; Wed, 13 May 2015 02:08:04 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88ABF1AC40B for <ianaplan@ietf.org>; Wed, 13 May 2015 02:08:03 -0700 (PDT)
Received: by wgic8 with SMTP id c8so36480712wgi.1 for <ianaplan@ietf.org>; Wed, 13 May 2015 02:08:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k7SBPWS/iNJ9ZnjrYnHwsrbMedz0w0ehNq202AqLNW8=; b=s8TY8kg3c4Zhh5PxpsWsD+AxYcisQDi0BYmgj0QYbdjLgTB5K3D4kTHxsPe4N3m3d6 O6U+Tce2o2VEKBAEhozqEio6nn+33bBJ+n7GbPfDHPwo14kp6gx3PTL6zjRiXwwEB6pa l+bsuNK+gOLqEDJ5EVAMS2TmGem79Gg8qth56BFRbqFhCmnMuHjALgE0GwXgbuOizGYH dWG9LA2W0KEZhZZo1zI8t2R/Y8IqzbVApDtoZEbiTRf1Zm1CsY808ixuEogvGO/aD70c +4hNo7qrC4ZBQn0nD4xr9RHl0ySRc6dlmhA0F4S3XJT1WKCOdpeEw95uvdz1XWqdxgqt yFWg==
MIME-Version: 1.0
X-Received: by 10.194.7.97 with SMTP id i1mr38714310wja.107.1431508082274; Wed, 13 May 2015 02:08:02 -0700 (PDT)
Received: by 10.28.151.137 with HTTP; Wed, 13 May 2015 02:08:02 -0700 (PDT)
In-Reply-To: <418d692e98e94d2bafe1c232b5c39e90@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.com> <6AAF802C-31C2-4D83-A6BE-49E794D966FE@istaff.org> <418d692e98e94d2bafe1c232b5c39e90@EX13-MBX-13.ad.syr.edu>
Date: Wed, 13 May 2015 11:08:02 +0200
Message-ID: <CAKFn1SF-1LyQ6k4+moxJ4iKYCLnf9jOUbN5X3XwXPWyn74DkXA@mail.gmail.com>
From: Roger Jørgensen <rogerj@gmail.com>
To: Milton L Mueller <mueller@syr.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/s4zznu4wTedNkY7cRFP_ywyaO60>
Cc: "ianaplan@ietf.org" <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: Wed, 13 May 2015 09:08:05 -0000

(sorry for top posting)


Milton,

In general - I don't really appreciate the tone of this email from
you, it read too much
like you have to take this or bad things will happen.



My personal view is that this PTI construct don't add anything else
than complexity.
I'll repeat that comment over in RIR land to, just working on a better
formulation.

If the goal - clear and stated goal from the names side of things was
to separate
policy from operations that make sense, but call it something else then.



--- Roger J ---

On Wed, May 13, 2015 at 10:27 AM, Milton L Mueller <mueller@syr.edu> wrote:
>
>
>
>
> Indeed - the more obvious approach would have been to move "the structure
> representing
>
> the DNS community" external to ICANN (and then have that contract with ICANN
> for IANA
>
> naming services), but as noted by Milton, such an approach quickly raises
> concerns about
>
> risk of capture and stability of the resulting entities.
>
>
>
> MM: Just a correction. That is not what I said. John Curran is talking about
> moving what is now the GNSO, ccNSO, ALAC and GAC outside of ICANN (“the
> structure representing the DNS community”) into some kind of large new
> entity that makes policy, and leaving IANA inside ICANN corporate. That
> would also establish a clear separation between policy and implementation,
> but if you know anything about the political and organizational complexity
> and dynamics of the ICANN policy process you cannot fail to realize that it
> is simply not feasible to make such a change. It would be massively
> destabilizing politically, financially, organizationally. (GNSO alone
> consists of 4 different stakeholder groups and 5 constituencies; supporting
> it probably accounts for half of ICANN’s large budget. GNSO, GAC, ALAC, in
> some sense all compete for power and influence in the ICANN policy process,
> and the form of separation John refers to would unbalance existing
> equilibria and force them to renegotiate their relationships. This would
> open quite a can of worms).
>
>
>
> What I proposed and discussed was a much simpler alternative: take IANA out
> of ICANN rather than the other way around. IANA is small and its functions
> less political. It is easy to divest it structurally.
>
>
>
> Further, while I acknowledged concerns about capture and stability of a
> separated IANA I did not say those concerns were valid. In fact, they are
> not. If we are talking about pulling IANA out of ICANN, talk of capture is
> not to be taken seriously. If the IFO for names is a mere contractor of
> ICANN, and does not even directly publish the root zone, it controls nothing
> and there is no point to “capture” it. If for some reason it was, a
> “captured” IFO could be fired and disposed of.
>
>
>
> Re: “stability” one could I suppose worry about the standard hiccups
> associated with any form of organizational change, but since we are taking
> the existing IANA department as the basis, it’s hard to make a rational case
> that this is some big destabilizing change.
>
>
>
> The main opposition to separating out IANA has come from ICANN itself, for
> reasons one can conjecture about, but that is outside the scope of our
> discussion here.
>
>
>
> So unless the community comes back with a clear message of “separate IANA
> completely” we are stuck with the middle ground solution. And there would
> still be strong opposition from certain quarters to full separation. And a
> completely internal model can certainly be ruled out at this stage -- it is
> no accident that the CWG has twice proposed a solution involving some form
> of externalization. So let me emphasize that unless this basic approach is
> confirmed in this round of comments, there will be at least another 6 months
> delay in the CWG proposal as it would be forced to renew the search for a
> model that can gain consensus.
>
>
>
> I believe such a delay will put the completion of the entire transition at
> risk. Outside the US, it will be interpreted as a failure of the MS model to
> deliver, and inside the US, it will give opponents of the transition a
> chance to renew the ICANN contract for a year and in the next year play all
> kinds of other games during an election year to impede implementation.
>
>
>
> Bottom line: how serious are your little gripes and cavils about how CWG has
> chosen to constitute PTI? Frankly I haven’t heard anything serious here. Are
> you focusing on the big picture, or are you entertaining the illusion that
> this transition can happen without any uncertainty and that one stakeholder
> can specify and get exactly what it wants?
>
>
>
> Of course, if your intention is to kill the transition altogether – and
> there are people who want to do that – then keep picking away at these
> things.
>
>
>
> --MM
>
>



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no