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

John Curran <jcurran@arin.net> Mon, 18 May 2015 17:24 UTC

Return-Path: <jcurran@arin.net>
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 3E3211A7015 for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 10:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 47lZRBapoGrG for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 10:24:26 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45D1A86E2 for <ianaplan@ietf.org>; Mon, 18 May 2015 10:24:26 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id BFD2F164F12; Mon, 18 May 2015 13:24:25 -0400 (EDT)
Received: from chaedge01.corp.arin.net (chaedge01.corp.arin.net [192.149.252.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id 0B4A4164EDE; Mon, 18 May 2015 13:24:25 -0400 (EDT)
Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge01.corp.arin.net (192.149.252.118) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 18 May 2015 13:29:58 -0400
Received: from CHAMBX01.corp.arin.net ([fe80::1cef:1d7:cca9:5953]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0224.002; Mon, 18 May 2015 13:24:18 -0400
From: John Curran <jcurran@arin.net>
To: Milton L Mueller <mueller@syr.edu>
Thread-Topic: [Ianaplan] CWG draft and its impact on the IETF
Thread-Index: AQHQkXQR6mbfotxNbkO1G1Gw+JTR5g==
Date: Mon, 18 May 2015 17:24:17 +0000
Message-ID: <C40875C4-FE0A-4AEE-BE92-E07BB6D6F48E@arin.net>
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>
In-Reply-To: <ad1d0707ff1b44eb9e48fef18d8e1268@EX13-MBX-13.ad.syr.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.149.252.96]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A395E906F79104BBF61D68C8FA5B629@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/VLPktOMJskw_xLa6Gkfn3be5Qks>
Cc: John C Klensin <john-ietf@jck.com>, "ianaplan@ietf.org" <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: Mon, 18 May 2015 17:24:30 -0000

On May 18, 2015, at 11:12 AM, Milton L Mueller <mueller@syr.edu> wrote:
>> (From John Klensin)
>> ...that there are reasons why it might not be in the interest of those bodies
>> to provide that consent.
> 
> Except that you have not provided any plausible reasons why they shouldn’t. ...


Milton - 

An agreement with ICANN provides absolutely clarity on the party which is accountable for the 
delivery of the specific IANA registry services, and does so in a manner which is independent 
of any other circumstances within ICANN.

An agreement for IANA services with PTI must acknowledge numerous dependencies on ICANN 
(e.g. budget, internal services, actions of the ICANN Board, etc.) - these dependencies all become 
risks which now the contracting party  (IETF, RIRs) must now deal with during contracting with 
regards to potential PTI non-performance.  For example, an ICANN/PTI disagreement that materially 
impacts PTI’s ability to deliver on IANA services to a particularly community may result in little direct 
liability to ICANN, if indeed that community contracted with PTI rather than ICANN.  That’s one very
plausible reason not to contract in that manner.  Another reason is that PTI is likely to have rather 
limited assets and reserves, and thus unable to directly address any serious performance issues 
that might arise without seeking additional capital from ICANN.   In general, it is not a prudent move
for businesses to allow assignment of their contracts to entities that are less capable of delivering
on the obligations therein.

/John