[Ianaplan] appeal to the IESG IRT. the IETF response to ICANN concerning the NTIA IANA Transition

JFC Morfin <jefsey@jefsey.com> Wed, 11 March 2015 18:03 UTC

Return-Path: <jefsey@jefsey.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 8F94F1A1B8D; Wed, 11 Mar 2015 11:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.135
X-Spam-Level: *
X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 dbHXrIey1QsZ; Wed, 11 Mar 2015 11:03:42 -0700 (PDT)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (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 2C9CD1A1B8E; Wed, 11 Mar 2015 11:03:42 -0700 (PDT)
Received: from 114.170.199.77.rev.sfr.net ([77.199.170.114]:24452 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1YVkyp-00060s-T0; Wed, 11 Mar 2015 11:03:41 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 11 Mar 2015 19:03:34 +0100
To: lstrickling@ntia.doc.gov
From: JFC Morfin <jefsey@jefsey.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_184952523==.ALT"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20150311180342.2C9CD1A1B8E@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/8TuloBTrp7pCVxO7mfXlhbSwTBU>
Cc: ianaplan@ietf.org, IAB <iab@iab.org>, "iucg@ietf.org" <iucg@ietf.org>, iesg@ietf.org
Subject: [Ianaplan] appeal to the IESG IRT. the IETF response to ICANN concerning the NTIA IANA Transition
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, 11 Mar 2015 18:03:44 -0000

The Honorable Lawrence E. Strickling
Assistant Secretary for Communications & Information
National Telecommunications & Information Administration
United States Department of Commerce
1401 Constitution Ave., N.W.
Washington, DC 20230

Saint-Vincent de Barbeyrargues, March 11, 2015

Dear Assistant Secretary Strickling,

On March 14, 2014, you asked the Internet Corporation for Assigned 
Names and Numbers (ICANN) to convene global stakeholders to develop a 
proposal to transition the current role played by NTIA in the 
coordination of the Internet's domain name system (DNS). You also 
have informed ICANN that you expected that in the development of the 
proposal, ICANN will work collaboratively with the directly affected 
parties, including the Internet Engineering Task Force (IETF), the 
Internet Architecture Board (IAB), the Internet Society (ISOC), the 
Regional Internet Registries (RIRs), top level domain name operators, 
VeriSign, and other interested global stakeholders.

Shortly after March 14, 2014, ICANN 
<http://singapore49.icann.org/en/schedule/mon-iana-accountability>launched 
a multistakeholder process and discussion to gather community views 
and input on the principles and mechanisms for a different issue: the 
transitioning of NTIA's stewardship of the IANA functions.

Following a month-long 
<https://www.icann.org/news/announcement-d8-2014-04-10-en>call for 
input on the community-driven draft proposal, on June 6, ICANN posted 
the 
<https://www.icann.org/resources/pages/process-next-steps-2014-06-06-en>Process 
to Develop the Proposal and Next Steps.

Then, following a call for names, the IANA Stewardship Transition 
Coordination Group (ICG) was formed, comprising individuals selected 
by each represented community. These 30 individuals represent 13 
communities of both direct and indirect stakeholders who together 
will deliver a proposal to the NTIA recommending a transition plan of 
NTIA's stewardship of IANA functions to the Internet community, 
consistent with the key principles that you outlined in your March 14 
announcement.

The ICG coordinates with 13 "communities", which are:
    *  Address Supporting Organization (ASO)
    *  Country Code Names Supporting Organisation (ccNSO and 
non-ccNSO Country Code Top-Level Domain [ccTLD] operators, as 
selected by the ccNSO)
    *  Generic Names Supporting Organization (GNSO). GNSO seats from 
non-Registry representation
    *  Generic Top Level Domain Registries (gTLD Registries)
    *  Governmental Advisory Committee (GAC)
    *  International Chamber of Commerce/ Business Action to Support 
the Information Society (ICC/BASIS)
    *  Internet Architecture Board (IAB)
    *  Internet Engineering Task Force (IETF)
    *  Internet Society (ISOC)
    *  Number Resource Organization (NRO)
    *  Root Server System Advisory Committee (RSSAC)
    *  Security and Stability Advisory Committee (SSAC)
None of them represent the directly affected largest party, i.e. the 
lead and end users and the civil society organizations. As a part of 
this large and open community, a pioneer of the international 
network, and a member of the Libre community, I considered that my 
best chance to get my position heard would be through the technical 
community open, collective, and balanced work.

Does RFC 3869 of the IAB not state?
"The principal thesis of this document is that if commercial funding 
is the main source of funding for future Internet research, the 
future of the Internet infrastructure could be in trouble. In 
addition to issues about which projects are funded, the funding 
source can also affect the content of the research, for example, 
towards or against the development of open standards, or taking 
varying degrees of care about the effect of the developed protocols 
on the other traffic on the Internet."
while the RFC 6852 from the same IAB states:
"We embrace a modern paradigm for standards where the economics of 
global markets, fueled by technological advancements, drive global 
deployment of standards regardless of their formal status."

"In this paradigm standards support interoperability, foster global 
competition, are developed through an open participatory process, and 
are voluntarily adopted globally. These voluntary standards serve as 
building blocks for products and services targeted at meeting the 
needs of the market and consumer, thereby driving innovation. 
Innovation in turn contributes to the creation of new markets and the 
growth and expansion of existing markets."
The IETF document preparation work has been carried out in three phases:
    * A "status quo" position decided by the RFC 3774 socalled "IETF 
affinity group" documented in a WG/IANAPLAN charter.
    * A work accomplished by that WG/IANAPLAN
    * A review by the whole IETF mailing list open to everyone but 
me, (I am the moderator of the <mailto:iucg@ietf.org>iucg@ietf.org 
non-WG mailing list of the Internet Users Contributing Group)
This consensus leads to a technological fork of the internet 
architecture at a time where the RFC 6852 paradigm opens a 
permissionless innovation area. To avoid this leading to a technical 
jeopardy, the IETF position document should address a certain number 
of questions permitting other SDOs, Libre projects, and other 
reentrant architectures to transparently use the same basic catenet 
infrastructure without mutual negative interferences. To that end, 
the IETF consensus should be enriched by the responses to a certain 
number of questions because at this stage it is not sufficiently 
understandable.

RFC 2026 defined the internet standardization process that addresses 
this situation through the appeal process. I am, therefore, appealing 
to the IESG, with the intent to ensure that the IAB and ISOC also 
address what belongs to their own areas of responsibility.

The text of this appeal is temporarily at the URL: 
https://www.dropbox.com/s/ckqaaq0ngqed0ie/iesg-appeal-inanaplan.pdf?dl=0
It should soon be listed at http://www.ietf.org/iesg/appeal.html

Respectfully yours,

Jean-Fran├žois C. (Jefsey) MORFIN
Moderator iucg@ietf.org
IETF contributions and appeals are in private capacity.