[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.