[iucg] Response to Jari

Jefsey <jefsey@jefsey.com> Wed, 08 October 2014 15:15 UTC

Return-Path: <jefsey@jefsey.com>
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 5CA311A6F11; Wed, 8 Oct 2014 08:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.632
X-Spam-Level: *
X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 Z_KBqlFG5rbL; Wed, 8 Oct 2014 08:15: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 632CD1A6F0A; Wed, 8 Oct 2014 08:15:10 -0700 (PDT)
Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:11135 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from <jefsey@jefsey.com>) id 1XbsxI-0006ef-4J; Wed, 08 Oct 2014 08:15:08 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 08 Oct 2014 17:14:18 +0200
To: Jari Arkko <jari.arkko@piuha.net>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <147A9E87-BA4E-4031-B2A1-F28881A61CD1@piuha.net>
References: <9390B5F8-8E21-40C2-9E96-168CD599419B@viagenie.ca> <542EEADA.6000206@thinkingcat.com> <20141004065827.84D7D1A8F46@ietfa.amsl.com> <DCF6FF98-8985-4401-BE42-0DFB325CAA88@piuha.net> <20141006145918.8EE1B1A6FCF@ietfa.amsl.com> <147A9E87-BA4E-4031-B2A1-F28881A61CD1@piuha.net>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_544241015==.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:
Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/3v17IO_BP2bHqOpsXsVe7DrjFE4
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>, "Leslie Daigle \(TCE\)" <ldaigle@thinkingcat.com>, Marc Blanchet <marc.blanchet@viagenie.ca>, iab@iab.org, "iucg@ietf.org" <iucg@ietf.org>, iesg@ietf.org
Subject: [iucg] Response to Jari
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg/>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 15:15:16 -0000
X-Message-ID:
Message-ID: <20141008151535.19570.82584.ARCHIVE@ietfa.amsl.com>

At 19:53 06/10/2014, Jari Arkko wrote:
>And of course, since we are an open organisation, this does not 
>limit who we listen to. It just specifies what other things besides 
>our own proposal we need to review. Obviously, we are open for input 
>with everything, including the transition proposal that awe are working.


Dear Jari,

Thank you for your response. An open organization in a changing 
context can suffer from it or catalyze it, more over in acting at the 
proprer time. Let me review this.


The past context

The IETF is a voluntary standardization organization that is supposed 
to adhere to its own RFC 6852 "Affirmation of the Modern Paradigm for 
Standards". ICANN is a US Government, non-profit contractor for 
making available the IETF IANA parameters and its own IANA names and 
numbers under the US Government oversight that also contracts to 
Verisign the permanent availability of the names (root) reference file.

The US Government legislation concerning the packet switching 
network, FCC operational licenses, and international data relations 
agreements predates by several years the creation of the Internet, as 
the internetting of the ARPANET system, which connected to the 
international packet switch services (IPSS) network in 1984.

This means that:

1. the network can economically, politically, technically, and 
legally operate without  the IETF, ICANN, and the IANA. They are only 
our today's way to attend needs that belong to the network technology 
and its governance evolution.

2. Since their inception in 1986 and 1998, each of them has always 
existed within the sole US Government oversight framework. They 
benefited from the international mutual recognition of that framework 
to enter into some agreements with international organizations, such 
as ITU, ISO, WIPO, etc. and developed their external, internal, and 
mutual practices under that sole umbrella.

This context dies and that umbrella closes on September 30, 2015.


The new context

What will remain will only be:

1) the world digital ecosystem communications infrastructure owned by 
local network providers and its use by billions of people under the 
contractual private terms that they bilaterally signed, and the World 
Communications International Treaty (WCIT) that the US Government has 
not signed.

2) private agreements and contracts between two US private 
organizations (ISOC and ICANN) specializing in a kind of usage 
(TCP/IP with a single DNS root, IANA, IPv4/6 addressing schemes) of 
that infrastructure

3) public affirmations produced by these organizations (RFCs in the 
case of IETF, and ICPs and AoC in the case of ICANN) to which people 
and corporations may refer in their own products, operations, and 
mutual contracts, subject to their (IETF Trust and ICANN) IPRs, under 
terms that are still to adapt to the conjunction of the "standard 
paradigm affirmation", the ICANN community Montevideo statement, and 
the NTIA announcement (as discussed by this WG).

4) the network of private bilateral contracts weaved by ICANN within 
the ICANN/NTIA "IN" DNS Class management framework. No one knows the 
market value of a domain name in that class after September 30, 2015 
(can increase as being famous, or lose value as being a few among a 
broad offer/private offer).

Any response, position, or question including the terms "obvious" 
and/or "of course" instead of accountable commitments bound to 
international law is, therefore, void and only leads to distrust of 
its author and the organization that he/she might represent or chair 
as being outdated or inadequate.


The IETF a pain or an help?

As a Libre and small operator, directly accountable to its user 
members, I can freely and responsibly raise the problem that I share 
with Govs, new technologies, incumbents operators, newcomers, and 
lead users. Why not give a chance to the IETF to document what is not 
"just one step" on "a long track record of evolving the IANA services"?

The WG/IANAPLAN Chair (Leslie Daigle) has clearly indicated that this 
has not been the IETF intent so far, unless the IESG decides 
otherwise. This is why there is a need to ask the IESG first if it 
wants to stay outside of the multistakeholder loop, and possibly make 
sure that it is the whole IETF position in asking the IAB.

If someone does not do it prior to 11/8 we probably have three options:

- an alternative root situation development (cf. ICANN/ICP-3 as the 
document of reference) leading to a ***possible*** technological 
breakthrough or to a ***possible*** mess.
- the emergence of a use/high level layers-oriented IETF equivalent. 
It will most probably take time.
- an ITU solution discussed within the WCIT framework. An interesting 
consequence of the NTIA initiative.


The RFC 6852 tactical opportunity

I also want to emphasize that, at this time, RFC 6852 is still 
sufficiently new for:
- its sole economic demand orientation to be accepted,
- which should help a fast and simple enough refoundation debate.

Further on, its ultimate innovation decision track, by economic power 
dominance over inter-global community competition, will disappear as 
people, cultural, political, military and many other demands, 
priorities, and R&D capacities become considered.

The responsibility is yours as the AD and as the IETF Chair.

jfc