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

Milton L Mueller <mueller@syr.edu> Wed, 20 May 2015 21:53 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 265D41A9085 for <ianaplan@ietfa.amsl.com>; Wed, 20 May 2015 14:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p2fWKLkZoodn for <ianaplan@ietfa.amsl.com>; Wed, 20 May 2015 14:53:36 -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 5C9621A8902 for <ianaplan@ietf.org>; Wed, 20 May 2015 14:53:36 -0700 (PDT)
Received: from EX13-MBX-06.ad.syr.edu (ex13-mbx-06.ad.syr.edu [128.230.108.137]) by smtp2.syr.edu (8.14.7/8.14.7) with ESMTP id t4KLrYsG008963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2015 17:53:34 -0400
Received: from EX13-MBX-13.ad.syr.edu (128.230.108.144) by EX13-MBX-06.ad.syr.edu (128.230.108.137) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 20 May 2015 17:53:34 -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; Wed, 20 May 2015 17:53:21 -0400
From: Milton L Mueller <mueller@syr.edu>
To: 'Christian Huitema' <huitema@microsoft.com>
Thread-Topic: [Ianaplan] CWG draft and its impact on the IETF
Thread-Index: AQHQjBpMEY3mz9BPA0WCyomEcYFu4J13fEsAgACeGQCAAGDXAP//wXfAgAC8H4CAALm3kIAD1/wAgAQiyoCAABXxEIAAT7wAgAANw4D//7750IAA+0WAgAA+JQCAAFIfkIAA5ESAgAErWgCAACaIgIAABnCAgAAGGYD//78xgA==
Date: Wed, 20 May 2015 21:53:21 +0000
Message-ID: <a78386a2666240d48be0aba1fb543e75@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> <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>
In-Reply-To: <DM2PR0301MB065543B4DCBCB751656B563DA8C20@DM2PR0301MB0655.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.230.182.126]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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-20_05:2015-05-19,2015-05-20,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-1505200286
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/WXXWVXTtbJgA8OBTS6Rq18LfR7Q>
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, 20 May 2015 21:53:38 -0000

> -----Original Message-----
> 
> There is an underlying question: would the system be less stable if
> protocols numbers, IP addresses, and domain names were managed
> by three different structures? Or would it be more stable? 

That is the right question. 

Although not all comments are in yet, it looks like the concept of a legally separate PTI has sufficient support from the names community to become part of the plan (indeed, the most salient dissents are calling for more separation, not less). And it's also clear that numbers community is not objecting to this structure and does not see any risk in it, though they have made it clear that they want to continue to contract directly with ICANN.

This means that comments questioning "what problem PTI is trying to solve" or "whether we should move in the PTI direction" are quite misdirected. We are not discussing whether PTI will happen, but whether IETF will choose to secede from it. 

To put the question more bluntly: 

Does IETF want to add to the transition a new process of extracting itself from the current IANA department and leaving the protocols registry as a stand-alone service within ICANN? 

Or does it want the protocols functions to move with the names and number functions into PTI? 

That's the real choice. 

How anyone can portray the first option as less destabilizing than the second, is beyond me. I view the second one as simpler. I hope no one at this point is pretending that the status quo ante is an option. It isn't. 

> Having system concentrated creates a concentration of
> power that increases risks for abuse. 

Remember that while all three functions might be provided by the same organization, each community would have its own distinct contract for those functions. In that respect there is a pretty powerful check/balance in place against abuse of concentrated power. Furthermore, extracting the supply of the IANA functions from an organization that is overwhelmingly dominated by the money and politics of names policy development is also a step in the direction of less concentration of power.