Message-Id: <6.2.1.2.2.20050702103242.04447710@pop.online.fr>
Date: Sun, 03 Jul 2005 03:15:16 +0200
To: ietf@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <42C64CB9.9090507@i-dns.net>
References: <6.2.1.2.2.20050630110931.04a66eb0@pop.online.fr>
	<42C64CB9.9090507@i-dns.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: the networks within the network - if ain't broke, let build on it.
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I have often been controverted due to my underlying vision of the 
international nature of the internet. The new US position documents this 
vision. It also confirms the most proper channels (ccTLDs as the trustees 
of their national internet communities) to address its evolution. It also 
puts the IETF under the competition of other fora.

I organised a two years long experimentation answering the ICANN ICP-3 
call. It documented both the need (here expressed by the USA) and ways for 
every nation to control its national naming and numbering spaces and of a 
network intergovernance of the national/specialised/communities 
governances. This is a universal need of surety and stability for the 
national critical infrastructures, a competitive offer of regalian services 
to their citizens, culture, languages and economy, of national Defence and 
persons' security, privacy and legal protection. This should prevent 
balkanisation, pulverisation and US dominance attempts. The suggestion of 
the 18 months work of the exploratory non-profit we incporated, is to 
proceed through an evolution of the core parameters of the Internet from 
"mono" to "multi" (no competion over any space, but coexistence of multiple 
spaces). There may be other propositions. Building on these experiences, I 
would suggest we focus right now on three targets:

1. a doctrine to support national, lingual, social empowerments over shared 
network virtual spaces (users can belong to a multiplicity of them) 
(a)  without endangering the global nature of the international network 
("the networks within the network"), (b) extending the end-to end concept 
to person-to-person (interintelligibility) and to community-to-community 
(common life). The USA challenge us: if ain't broke, ... let build on it.

2. to preserve the IANA IETF part from national and cultural disputes. 
ICANN relations with the USG result from the IANA contract 
http://www.icann.org/general/iana-contract-09feb00.htm. The last thing we 
need are national disputes over the IETF part (protocols) of the IANA due 
to this. This is why I wasted so much time fighting RFC 3066 bis: every 
Registry referring to ISO 3166 should be transferred into the ICANN/GAC 
IANA area. Government, cultural, commercial issues are not the IETF 
business. We want a distributed extended IANA, not 191 national anti-IANAs.

3. to establish a liaison between IETF and ccTLDs. I invited Brian 
Carpenter to address the ccTLD Luxembourg meeting on this. He declined, 
after consulting with Leslie Daigle. They saw no need for a liaison at this 
stage while IETF already has liaisons with ICANN. Remarks: (a) There are 
two liaisons: BoD (John Klensin), and technical: not manned. (b) ICANN has 
no vocation to represent the ccTLDs but to relate with them.

However, Brian welcomed a direct technical dialogs, on an ad-hoc basis, 
with the concerned ADs. At the present time ccTLDs cannot do that as a 
community. I therefore studied the way for them to address Brian's demand. 
I will present it on Sunday at the ccTLD meeting. My invitation to Brian 
(or Leslie) holds: it would be a timely way to show the IETF is involved 
and was ready.

This proposition, which meets the agreement and support of every concerned 
party I met f2f, consists in (a) an open forum sponsored by ccTLDs where 
every technical need, from bandwidth to lingual support, could be 
introduced by their Managers (b) an independent multi-technology/multimode 
(convergence) task force to translate it into coordinated technical specs, 
to dialog with the IETF, W3C and other fora, and to keep updated an 
internet developer/user guide (c) a running code experimentation and 
validation community test-bed, along with the ICANN guidelines.

Comments and suggestions welcome.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf