[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
- [iucg] prior to he today virtual meeting JFC Morfin
- Re: [iucg] [Ianaplan] prior to he today virtual m… Jari Arkko
- [iucg] Response to Jari Jefsey