From nobody Sun May 31 17:51:17 2015 Return-Path: X-Original-To: iucg@ietfa.amsl.com Delivered-To: iucg@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 ) 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" From: JFC Morfin In-Reply-To: <763565D0-92BF-4A1B-9C1D-C9AC94A57506@gmail.com> References: <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> <4AB120DC-AFB1-4915-B6C5-7417FB989878@piuha.net> <55669A78.3020309@cisco.com> <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: Cc: "Ianaplan@Ietf.org" Subject: [iucg] The seventh stakeholder [was: Time frame inquiry] X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 00:51:16 -0000 --=====================_150667544==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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. 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 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) 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 "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 --=====================_150667544==.ALT Content-Type: text/html; charset="us-ascii"
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 .


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 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) 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 "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
--=====================_150667544==.ALT--