[Ianaplan] The seventh stakeholder [was: Time frame inquiry]

JFC Morfin <jefsey@jefsey.com> Mon, 01 June 2015 00:51 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 69F661A6F15; Sun, 31 May 2015 17:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.649
X-Spam-Level: **
X-Spam-Status: No, score=2.649 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, URIBL_RHS_DOB=1.514] 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 tEwQax2-0Vog; Sun, 31 May 2015 17:51:13 -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 0F3031A6F29; Sun, 31 May 2015 17:51:13 -0700 (PDT)
Received: from i15-lef01-t2-62-35-238-138.ft.lns.abo.bbox.fr ([62.35.238.138]:14398 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from <jefsey@jefsey.com>) id 1YzDwd-0006cO-TO; Sun, 31 May 2015 17:51:12 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 01 Jun 2015 02:51:06 +0200
To: "iucg@ietf.org" <iucg@ietf.org>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <763565D0-92BF-4A1B-9C1D-C9AC94A57506@gmail.com>
References: <D15A3C14-F268-4CF1-B942-BAE57B281C58@cooperw.in> <556D3AAA-1655-4785-9395-8F6CD0B73E44@vigilsec.com> <5F8F0771-C77B-4D90-811B-501A4EC79268@istaff.org> <893FE3E3-A2DD-40D8-B39F-1EB24DFE1806@vigilsec.com> <97267ED7-D8A2-4A64-AB74-07434190DD89@piuha.net> <CA+9kkMBZq_U+CC5Jzv5T3pL7qasUHSfv-Gu8q4P36+phABXxzg@mail.gmail.com> <4AB120DC-AFB1-4915-B6C5-7417FB989878@piuha.net> <55669A78.3020309@cisco.com> <C8B9D0E8-C363-4618-8941-D0027B86EB7A@piuha.net> <20150528170435.GQ85071@mx2.yitter.info> <763565D0-92BF-4A1B-9C1D-C9AC94A57506@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_150667544==.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: <20150601005113.0F3031A6F29@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/zyJHxM11HqXjIhgrqLnOsufpUbc>
Cc: "Ianaplan@Ietf.org" <ianaplan@ietf.org>
Subject: [Ianaplan] The seventh stakeholder [was: Time frame inquiry]
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: Mon, 01 Jun 2015 00:51:16 -0000

Dear Folks,

We are supposed to represent the IETF/IANA (Informed) Users 
community. The IETF IPRs, the lack of attention that we received and 
the hacking of our site has not led us to develop as an IETF body, 
while some have initiated the IUWG lists. I think, however, that it 
is time for us to try to help the IETF and ourselves in the current 
circumstances of the IANA transition process, and to counter the new 
evolution of Paul Twomey's "IANA war".


1. A six-body complication

We are confronted with six stakeholders (IETF, RIR, ICANN, IANA, PTI, 
NTIA) that only seem to share in common their disdain for our user 
community (which pays for them all!). There are two possible POVs:


1.1. Political point of view

Clausewitz teaches that one always must consider the worst that can 
result from a given situation. The worst seems simple enough to describe:
- a transfer of the 5,000 billion internet worth (through TMs - the 
RFC 6852 "huge bounty") from NTIA/WIPO oversight, to ICANN, under 
FCC/Congress legal control
- and extend it to everything digital (i.e. capitalizing on the 
internet to oversee the whole multitechnology development, i.e. the 
1985 delayed IEN 48 initial project).

The mechanism is simple. The IANA is the unique authoritative 
repository. It will be operated by the DNSSEC operator, PTI Inc., 
incorporated in the US as a 100% ICANN affiliate replacement for 
Verisign, that should statisfy our new internet masters : ICA 
(http://www.internetcommerce.org/). This "simplification" could even 
permit ICANN to transfer to Geneva, as the WIPO, ITU, etc. while 
everything "commercially real" would stay under US jurisdiction.

Even with the WEF support and commercially led multistakeholderism, 
this depends on the lasting multilateral credibility of the US State 
"IN" (ICANN/NTIA) CLASS "unique authoritative root" fairy tale that 
China politely/politically has respected externally for years. But 
for how long now? We know this implies a risk and a cost the common 
users cannot accept. This is the reason why we sponsor the "FL" 
(Free/Libre) CLASS experimentation project [within the limits of the 
ICANN ICP/3 constraints in order to avoid any confusion] and MYCANN 
Plugs-in - moreover after 
<http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html>http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html.


1.2. normative point of view

The WG/IANAPLAN has permitted to experiment the lack of documentation 
that I opposed in RFC 6852 (the NTIA transition process follows +/- 
the OpenStand multistakeholderism):
-  nothing on how to address a situation where another community 
architectonically (i.e. more fundamentally than at its own 
architectural level) disagree with another community.
-  nothing on how a new "global community" can emerge and be acknowledged.

In this case:
- I fully understand and accept that this WG Draft and debate 
represents the rough IETF consensus
- however, as an informed user community member, I oppose this Draft 
because it is uncompleted.

My 
<http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf>http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf 
appeal and their response shows that the IESG refuses to consider the 
pending issues. However, some of these issues are already emerging. I 
will, therefore, wait until the mid-June limit to appeal the IAB in 
order to see how they are adapting to the reality evolution.

What seems obvious is that the IETF is downgraded from the 
"iana.arpa" referent having a right of life and death on ICANN (MOU) 
to one of the technical SDOs being using the ICANN coordinated names 
and addresses. Protocols pass but names and addresses remain; they 
survive technologies. The NTIA transition is the beginning of the 
post-TCP/IP era.

Lawrence Strickling words this clearly when he speaks of "ICANN's 
three customers". I certainly understand how names and numbers can 
foot an ICANN's IANA bill. How will the IETF cope if RFCs and 
parameters stay in the public domain: Russ Housley seems to be out of 
context...


2. We need an RFC 6852 solution

A structural solution is to be found. It is necessarily part of the 
NTIA transition. Otherwise, we users (informed users, end users, 
corporate users, governments, providers, cities, etc.) will look 
for/build it outside of this process. We need to help the NTIA 
clearly understand it: we are neither in a master/slave nor in a 
client/server situation. We are in a Masters and Masters relationship.

I certainly accept that the complication of the NTIA legacy is not 
easy to revamp into a seamless neutral intergovernance of the world 
digital ecosystem, Europe and BRICS can accept in the middle range.

This is why I propose that we proceed:
- (1) step by step.
- (2) from an informed user (IUser) point of view.
- (3) along a simple criteria that supersedes - on the middle/long 
global range - every political local arrangement/revolution: the 
"bubb" criteria: Biggest User Bang for a Buck.


2.1. Basic note

Please note that I do not oppose any local/political arrangement; I 
just want to check that each of them:

- consistently sustains the general use stream (and will, therefore, 
stay around being probably more and more reinforced)
- and not oppose or attempt to deflect it (because it would erode, 
degrade, and ultimately be replaced).

I do not oppose the idea that something might be replaced or 
improved, but I do not know how it will be replaced: I cannot support 
something that I don't know. This is also a French constitutional 
precautionary duty for the French citizens among us.

Is this sterilizing?

On the contrary. This is because we are in a particular case where:

- our charter pleads for a status quo (what I think leads to 
technical jeopardy)
- our AD, also the IETF Chair, explains to us that "we are trying to 
bring about a significant transition in the internet ...at the IETF 
we are lucky to be on the easier side, but we also want the best for 
the whole Internet". If I read this as usual, i.e. the "internet" as 
a technology and the "Internet" as the "I*Core" deployed network 
system, I am in total agreement.

We are truly establishing:

- new ***initial conditions*** for the internet
- in a new context for the Internet.

What is particular about the initial conditions is that you cannot 
change them afterward, only patch them.

This is why I am attentive to the latent embarrassments/extensions of 
the propositions that we may discuss. To clearly identify them, I 
will call them "bubbles": Biggest User Bang for a Buck Latent 
Embarrassment Suspicions or Extension Solutions.


2.2. The bubble list

To be pragmatic:

2.2.1. I suggest that we collect, extend, and maintain a bubbles 
list. With only a description of the issue.

2.2.2. so, anyone or global community can use the list and 
documentation to explore and document a decision tree 
(<http://en.wikipedia.org/wiki/Decision_tree>http://en.wikipedia.org/wiki/Decision_tree) 
from the first buck invested/spent by a user to the latest possible 
returned bang.

2.2.3. this will, therefore, result into a clear method enabling the 
ability to clearly support/follow/document each choice that users are 
to make depending on their project and the technologies they may use.

2.2.4. In order to support the corresponding effort for consistent 
multiple decision tree multi-consensuses, I suggest a common study 
for a "<http://netbubbles.net/>netbubbles.net" tool.


3. The seventh stakeholder

The advantage I am looking for here is to transform,
- what may look like a "users ectoplasm" to the honnest members of 
the names, numbers, and protocols communities
- into a seventh stakeholder that they can clearly identify as a 
"usedocs" community - documenting how to consistently deal with the 
digital ecosystem and multitechnology intricacy. The "usedocs.net" 
site could then be created. It could feed the IANA with its own use 
oriented references, becoming a fourth ICANN "customer" ?

I understand that at least several decision line families may quickly 
emerge with options such as: ICANN, MULTICANN, multistakeholderist, 
omnistakeholderist, self-restricted RFC use, permissionless 
innovation, LIBRE Relationware, Open Source, proprietary solutions, 
etc. without even considering national/continental enhanced 
cooperation projects. Having them clearly documented will probably 
help many in better understanding the pros and cons of the various 
solutions that they are considering, thereby driving sustainable innovation.
Sustainable innovation in turn contributes to the achivement of an 
"Inclusive, People Centered, Development Oriented and Knowledgeable 
Information Society for All" (Tunis Declaration).

jfc