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

Milton L Mueller <mueller@syr.edu> Thu, 21 May 2015 15:19 UTC

Return-Path: <mueller@syr.edu>
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 BE9071A7017 for <ianaplan@ietfa.amsl.com>; Thu, 21 May 2015 08:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level:
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 pY_PfSKiNxbV for <ianaplan@ietfa.amsl.com>; Thu, 21 May 2015 08:19:42 -0700 (PDT)
Received: from smtp2.syr.edu (smtp2.syr.edu [128.230.18.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953A31A09CF for <ianaplan@ietf.org>; Thu, 21 May 2015 08:18:21 -0700 (PDT)
Received: from EX13-MBX-07.ad.syr.edu (ex13-mbx-07.ad.syr.edu [128.230.108.138]) by smtp2.syr.edu (8.14.7/8.14.7) with ESMTP id t4LFIINs012296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 May 2015 11:18:19 -0400
Received: from EX13-MBX-13.ad.syr.edu (128.230.108.144) by EX13-MBX-07.ad.syr.edu (128.230.108.138) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 21 May 2015 11:18:06 -0400
Received: from EX13-MBX-13.ad.syr.edu ([128.230.108.144]) by EX13-MBX-13.ad.syr.edu ([128.230.108.144]) with mapi id 15.00.0847.030; Thu, 21 May 2015 11:18:07 -0400
From: Milton L Mueller <mueller@syr.edu>
To: Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [Ianaplan] CWG draft and its impact on the IETF
Thread-Index: AQHQjBpMEY3mz9BPA0WCyomEcYFu4J13fEsAgACeGQCAAGDXAP//wXfAgAC8H4CAALm3kIAD1/wAgAQiyoCAABXxEIAAT7wAgAANw4D//7750IAA+0WAgAA+JQCAAFIfkIAA5ESAgAErWgCAACaIgIAABnCAgAAGGYD//78xgAALkocAAAE49FA=
Date: Thu, 21 May 2015 15:18:06 +0000
Message-ID: <02097952b35d46f0a9583d58a0ba54a2@EX13-MBX-13.ad.syr.edu>
References: <5550F809.80200@cisco.com> <55511064.2000300@gmail.com> <CAOW+2dvBb4n4W=q7NoO_V1X+JoqvO1TWYBqPAEseY9T7vybj9Q@mail.gmail.com> <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> <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> <CA+9kkMDDUuc7ViXPHy60d52j5KmGwFku4Dh1-11sLaVD9wwKmg@mail.gmail.com>
In-Reply-To: <CA+9kkMDDUuc7ViXPHy60d52j5KmGwFku4Dh1-11sLaVD9wwKmg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [108.26.56.166]
Content-Type: multipart/alternative; boundary="_000_02097952b35d46f0a9583d58a0ba54a2EX13MBX13adsyredu_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-21_05:2015-05-20,2015-05-21,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505210205
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/i8Al0cMwpS9iBUl3NDZHSrSS8Pw>
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: Thu, 21 May 2015 15:19:48 -0000


Your statement is not clear.  Are you saying that the numbers community is not objecting to this structure for the names community and does not see any risk in that community choosing that for its use?

MM: Yes, I am saying that. But I am also saying that the RIRs have expressed no fears about or objections to the numbers functions being provided by the new legal entity (PTI), as long as they can contract with ICANN (a known entity).

That is a very curious idea of secession.  The IETF community came to consensus on a document that was completed prior to the PTI proposal being made.  Having the IETF community continue to contract with ICANN is not secession.​

MM: Agreed, having the IETF community continue to contract with ICANN is not secession. It’s perfectly understandable and reasonable for IETF to want to continue that. And indeed that is what the numbers people are proposing too. You just need to understand that while you will contract with ICANN, ICANN could fulfill that contract via PTI.

It is “secession” – more accurately, a split - if IETF insists that protocol functions of IANA remain inside ICANN when all the other functions are moving into PTI. That is the issue I was addressing. I hope that distinction is clear now.

The various objectives and benefits of creating PTI for names are fully explained in countless documents from the CWG, including professional legal analyses of the advantages and disadvantages.

I’ve engaged in this debate only because I am concerned that objections to PTI may lead to splitting the IANA functions into separate provider entities, one inside ICANN and the other one outside. This imho would be an added complication in the transition process, a bit more disruptive than simply letting them stay together in PTI. And in terms of the overall environment surrounding ICANN, I think it’s better to get all IANA functions out of the DNS policy making entity. But of course it’s IETF’s call. I just hope that the call is not made based on misconceptions of what PTI is and what the options are.

--MM