Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

"Peterson, Jon" <jon.peterson@neustar.biz> Fri, 07 November 2014 22:00 UTC

Return-Path: <jon.peterson@neustar.biz>
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 57F391A1B39 for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 14:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level:
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 o5NdKK2kl2mV for <ianaplan@ietfa.amsl.com>; Fri, 7 Nov 2014 14:00:30 -0800 (PST)
Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BB31A1A80 for <ianaplan@ietf.org>; Fri, 7 Nov 2014 14:00:30 -0800 (PST)
Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id sA7LvxV8007620; Fri, 7 Nov 2014 17:00:30 -0500
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1qh56704dq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 07 Nov 2014 17:00:29 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 17:00:28 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Milton L Mueller <mueller@syr.edu>, 'Miles Fidelman' <mfidelman@meetinghouse.net>, "'ianaplan@ietf.org'" <ianaplan@ietf.org>
Thread-Topic: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
Thread-Index: AQHP960iQbkZx6Ao80Cv4+wEz5Ij95xPyGuAgAA0/ACAAADXAIAAAw4AgACLogCAACs6gP//uiCAgADC1gCAAAfPgIAACgwAgAAESoD//32igIAAiAgAgAAA6YCAAAWHAIAAKOGAgAASLoCAAErKAIAAeYgAgAAktgCAAAkQAIAAaaqAgAAbPACAAAd4AIAAZEGA//+U/oAAVsNggP//ld8AgACgnQD//5QagA==
Date: Fri, 07 Nov 2014 22:00:27 +0000
Message-ID: <D0826BB8.137BBD%jon.peterson@neustar.biz>
References: <GLEAIDJPBJDOLEICCGMNIEOJCNAA.rhill@hill-a.ch> <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <D0805C27.136BE7%jon.peterson@neustar.biz> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <bcb86b6995de41feba256567c114265d@EX13-MBX-13.ad.syr.edu>
In-Reply-To: <bcb86b6995de41feba256567c114265d@EX13-MBX-13.ad.syr.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [192.168.128.84]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <436F1CA00AFC134AAF272BBBEFA2F6A1@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7615 signatures=670576
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.13383252786647e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.997362837850562 urlsuspect_oldscore=0.997362837850562 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.997362837850562 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411070183
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/e8EG97KjZZssN6wLe0oKmOh1h5E
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
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: Fri, 07 Nov 2014 22:00:33 -0000

On 11/7/14, 12:26 PM, "Milton L Mueller" <mueller@syr.edu> wrote:


>So if I were you I would focus on whether it is a good idea - for the
>general good of the Internet and for the IETF - for to have control of
>the iana.org domain and the trademark in the hands of the IETF trust or
>whether it is better for the public and the IETF to have it in the hands
>of ICANN. That's all that matters. The purpose of this exercise is to
>rearrange the institutional design to accommodate the withdrawal of the
>NTIA. The purpose is not to be polite or nice, or to avoid offending
>anyone. The purpose is to get it right.

I get that you believe ICANN shouldn't own iana.org and that someone else
should, but you're barking up the wrong tree when you nominate us for the
job. Ownership of the iana.org domain doesn't matter very much to the
IETF. We don't need to own it to use IANA, given that we don't own it and
we use IANA today. If for some reason we couldn't continue to use IANA the
way we do today (and I'm only talking about the protocol parameters here),
we as the IETF would just do something else for protocol parameters that
would serve our needs as an organization.

I am sympathetic to your dedication to an open Internet, and I understand
that your advice here is intended to further those beliefs we share. The
real gulf between us is that you are placing your faith in politics, and I
am placing mine in engineering. When you worry over contingencies, you
think the IETF needs to seek the protections of careful "institutional
design" to retain our powers. I give us better odds if we instead engineer
around potential failures, because the people who self-select to
participate in the IETF are experts in engineering, not politics.

We should answer the ICG and continue to work with existing partners in
the multistakeholder model, but what is paramount to us is the flexibility
to innovate as we see fit - that is the crux of an open Internet, and
where the true power of the IETF lies. I don't think owning iana.org would
protect us from anything I worry about, but insisting on it would alienate
our partners and, should we succeed, ultimately leave us with a bunch of
powers and responsibilities which are extraneous to our job.


>If you sincerely believe that IETF should be permanently locked in to
>ICANN as IANA provider, should have no choice as to who performs those
>functions for it, and therefore the marks and domain should stay with
>ICANN, then fine. Please argue that position. I will engage with those
>arguments respectfully. But please let's not argue about etiquette!

... again, this is absolutely backward. The protocol parameter registry
exists because we choose to populate it. If circumstances alter to a point
where we don't want to use it anymore, then it will have no value to
anyone, because we'll be populating something else. That's why I have
confidence that the stewardship of IANA will remain aligned with our
needs. The only way we will get "permanently locked in" to anything here
is to lobby for some ossified "institutional design" that awards IANA or
any other component of our model an undue permanence in our processes. I
do believe you are advocating in good faith here to prevent a bad outcome,
but the path you suggest leads us somewhere even worse.

Jon Peterson
Neustar, Inc.