[Ianaplan] You told us not to trust you anymore [was Process concern regarding the IETF proposal development process]

Jefsey <jefsey@jefsey.com> Wed, 21 January 2015 18:09 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 840041A1B57 for <ianaplan@ietfa.amsl.com>; Wed, 21 Jan 2015 10:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.131
X-Spam-Level: **
X-Spam-Status: No, score=2.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_PAYLESS=0.5, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] 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 h3c2p-Wru6WK for <ianaplan@ietfa.amsl.com>; Wed, 21 Jan 2015 10:09:50 -0800 (PST)
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 BBB871A1B49 for <ianaplan@ietf.org>; Wed, 21 Jan 2015 10:09:50 -0800 (PST)
Received: from 213.218.130.77.rev.sfr.net ([77.130.218.213]:57832 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1YDziu-000730-MA; Wed, 21 Jan 2015 10:09:49 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Jan 2015 19:05:56 +0100
To: John C Klensin <john-ietf@jck.com>, Bernard Aboba <bernard.aboba@gmail.com>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <081020B9508A6D83480B48CF@JcK-HP8200.jck.com>
References: <C172BBB7-9BA4-4BA7-848C-C7FE5B66CBF7@cooperw.in> <8B1EC865-AD1F-4165-8C3A-258BA18C4823@gmail.com> <CAD_dc6j_762J_6wRiFt1Fx3mgLGJ5Q+p1p58eMOtf7Pt6F1GWQ@mail.gmail.com> <CAOW+2dtbq0WFjnYuKk-9aQU-SMDGhxvV4etTYj74m7feeVtVbQ@mail.gmail.c om> <CAD_dc6gqmqUnqwGA8JR=R4U=wpUhsRWZ7HNfnkripWHYGYS8vg@mail.gmail.com> <CAOW+2ds_dC7pyN2E5VYznjHNHkho+HB6w4uUDaH+GMQn7r08sg@mail.gmail.c om> <081020B9508A6D83480B48CF@JcK-HP8200.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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:
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/ADwuEH6yWlN8Ggr_tsDy0yCgS9c>
Cc: ianaplan@ietf.org, Richard Hill <rhill@hill-a.ch>, Alissa Cooper <alissa@cooperw.in>
Subject: [Ianaplan] You told us not to trust you anymore [was Process concern regarding the IETF proposal development process]
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, 21 Jan 2015 18:09:52 -0000
X-Message-ID:
Message-ID: <20150121180955.6138.88480.ARCHIVE@ietfa.amsl.com>

At 16:29 21/01/2015, John C Klensin wrote:
>Again IMO, none of this has anything to do with Richard's
>complaint.  The issue there seems to be very simply a situation
>in which he asked for some things, couldn't persuade the WG that
>they were important, and is now trying to turn his
>dissatisfaction with that outcome into a process complaint.

Dear John,

I am afraid that you do not grasp the stakes. This is only a question
of trust in you, Bernard, Russ, Brian, Jari, Vint, Andrew, Dave,
Steve, Miles, etc.: the concerned IETF leaders.

Until now, we trusted you to keep the TCP/IP consistent with all the
RFCs, along the RFC 3935 core values, and we wished for you to
continue.

However,
1) this draft declines this trust.
2) Jari published that you yourselves entrust your own decisions in
the NTIA, making you the leaders of a USIETF.

Richard asked you to document the reasons for your position; if he
still is not statisfied he will appeal the IESG decision.

I will appeal because I accept your (you = collective leadership)
reasons but I need you to correct your new lack of clarity.

1) this is your IETF and it decides what it wants as per its RFC 2026
procedures that have been respected as they will respect my appeal
once an RFC will have been allocated. As Brian has shown it: this is
not a leadership decision but a rough consensus to adopt the position
proposed by your leadership. Alles klar.

2) You have already documented these reasons in RFC 6852: the IETF is
no longer the unique authoritative source for the internet technology,
its innovation is led by the economy, and the internet technology is
no longer the only technology being used on the catenet.

3) I have appealed RFC 6852 because it does not say who replaces the
IAB as the ultimate referent, both in technology choices and in a
global community markets economic reading. Now, Jari Arkko has
answered me: the NTIA.

---

As a catenet co-owner (one among billions of omnistakeholders):

1) We trust you. Even when you say you are not in a position anymore
to assume the responsibility that we trusted you would trustingly assume.
2) We do not trust the NTIA as your replacement.

Where does that lead us non-US citizen users?

Like billions of people, I own interconnected processors. On those
processors, I load FLOSS software that permits me to use the catenet
that these processors of mine cooperatively form with these billions
of other people's systems. I am not dogmatic about any standard: I
just want this FLOSS software to best work to support my needs in
relating with the other people's systems through our common catenet.

For 40 years, people (me included) have tried to make money with this
need of ours. This was mainly because they had to pay for the catenet
substructure, selling us the concatenation of our systems with theirs
and those of others, using telephone lines we partly already paid for
with our taxes. Their proof of concept is completed, and we now can
also locally connect our various home appliances for free, and
cooperate with our neighbors through our Wi-Fi based catenet
non-profit local cooperatives.

Our priority now is to pay less and to get more, as a return on all
the money and intelligence we have invested and continue to invest
into all of this. Our only question is: (now  we cannot trust you
anymore) how do we best achieve that it at least neutrally, surely,
and securely work?

* We do not like ICANN and its TLD mafia that costs us a lot of money
   and prevents us from using the names we wish as we wish it.
* we do not like the RIRs that cost us a lot of money for addresses
   that we already have (everyone has a telephone number).
* we do not like TCP/IP that brings us SPAM and the NSA,
* we will have to competitively (as per RFC 6852) check your IETF
   propositions as being adequate to our needs or to your deciders' needs.

---

Therefore, being now clearly by ourselves:

1. the first thing we need is to get rid of ICANN and the NSA.

2. then, a no-SPAM technology architecture.

3. then, a universally consistent free and sensible numbering scheme.

4. then, a TCP/IP stack improvement or a trustable technology
     replacement (cf. IAB's call for that).

5. then, cheaper, safer, and easier:

5.1. file transport (NDN),
5.2. meaning inter-comprehension support (intersem),
5.3. cloud distributed processing (SDN),
5.4. inter-application on an ASAP (AS A Protocol) basis,
5.4. on a global and local catenet network multitechnology
5.4.1. we can consistently supervise from our own Intelligent Use
           Interface system
5.4.2. as our sure, secure, transparent, resilient, etc. VGN (virtual
          glocal network).

6. then to cooperatively develop, test, and document how to make the
     other catenet users' systems address our common needs : we will call
     the Libre solution Netix. It will embed:
6.1. a security/multilinguistic/format/intelligence etc. OSI layer six+
6.2. a set of traffic adapted middle layer innovative technologies (as
        a result of global communities' market economies as documented by
        RFC 6852).

7. then a multitechnology IANA extension to jointly support the
     related names, numbers, and parameters, and use documentation of
     reference.

That is to say, Vint Cerf's IEN 48, 1978 objective a- nd what I managed
and sold as a public international service 30 years ago (but to
thousands fewer users).

----

We already have:
1. many Libre tools to build this Netix solution.
2. ITU and many others have provided and will provide OSI layer six+
     documentation, and libraries.
3. at the IETF you have stabilized a widely used middle layer technology
4. you have also documented some level seven services that we may
     share, improve, and consistently extend among new technologies (such
     as OPES and DDDS).

What we need is to make sure:

1. our multitechnology Intelligent Use Interface (IUI) includes the
necessary routines,
2. we keep their documentation up to date,
3. we cooperatively consider how to improve them.

----

The problem is the coexistence between you and us, and the transition.

1. We would have loved the IETF people to continue to act as a unique
     authoritative referent through their http://iana.arpa source, and as a
     result keep controlling the ICANN technical fancies in the DNS "IN"
     CLASS.

2. Now, however, you have formally decided that

2.1. the NTIA is to decide for you because you cannot be the only
        ICANN responsible accountability referent after the NTIA departure
2.2. you are not interested in making sure that the IETF technology
        stays compatible with other network technologies like ours.
2.2.1.  we have to collectively assume the job - at least among us.
2.2.1.  we will keep relating with you as the US industry global
            community technical referent.

Our Catenet cooperative corporation will implement a Libre repository
for all the technologies that the catenet will support. The best way
to keep this multiple source consistent would be to document an IANA
protocol. This could be best carried out within the OpenStand
framework, along the RFC 6852 principles.

----

All of this may create some confusion if this is not clear for all
that this is what you want the NTIA to organize, and we prefer to
organize on our own for those interested from the Libre community.

In addition, some people may want the IAB to continue,
* assuming its unique authoritative referent role for the
"mono-internet+catenet" technology that they use
* technically balance the ICANN/Rosetta/WEF economic weight.

This is why I will have to appeal this WG's RFC once it is published.

This will make the IESG, IAB, and ISOC officially and formally clarify
things, for them; telling the world that the IAB http://iana.arpa is
only to be the source of reference for the IETF brand among RFC 6852
various internet technology lines of economically competitive innovations.

jfc