Message-Id: <6.2.1.2.2.20050707175801.05037630@mail.afrac.org>
Date: Fri, 08 Jul 2005 02:10:00 +0200
To: "Addison Phillips" <addison.phillips@quest.com>, <ltru@ietf.org>
From: r&d afrac <rd@afrac.org>
Subject: RE: [Ltru] please, get real!
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014E56@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0C014E56@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Addison,

At 17:00 07/07/2005, Addison Phillips wrote:
>To remove the RFC 3066 registry from IANA would require a new RFC, such as 
>we are working on here, so...

Yes. This what I am talking about. As explained, RFC 2860 is an MoU between 
ICANN, IANA and IETF. This MoU is in limbo because no one knows if ICANN 
still has the capacity to sign it. Legally speaking the IANA is an USG 
property, contracted on a yearly basis to ICANN. There are serious legal 
considerations about the right of the USG to give it away without a Bill 
(General Accounting Office, Congress). The USG said they did not want to 
give it away nor probably to continue to lease it, but to keep it - ICANN 
assisting. This is up to the ICANN lawyers to see into it and USG to 
explain/negotiate at the WSIS. The key links are under 
http://nicso.org/iana.htm

I document the reason why for four years. I ran a two year test bed 
including it and started the AFRAC exploration under public and private 
interests supervision: there is no way USA security and identity can be run 
by foreign undetermined interests, no more than France security and 
identity can be run by the USA or lose foreign undetermined interests. And 
the same is true for every other nation and culture (look at Tamils).

The US position was triggered by the Internet balkanisation (and USA adds 
to it) which results from the IETF IDN propositions and from this Draft. It 
lead to a DNS split because IDNs are not accepted (already three non legacy 
TLDs resolving in the top zone). It will lead to a IANA split, this Draft 
being the trigger, by countries and cultures not accepting to be subject to 
an US Registry nor to foreign decisions, appreciations, definitions, 
correlations other than the one they accepted/decided through ISO.

The immediate solution of compromise I propose is simple: that ISO 3166 and 
ISO 639 issues are understood as "name and numbers" issues and are 
therefore temporarily put into the ICANN part of the IANA (cf. RFC 2860), 
under the control of the GAC. This will permit countries to be involved 
when their ISO 3166 code is affected. Then to remove that Registry from the 
US IANA, to transfer a copy of it to the ICANN Common Reference Center, as 
well as to AFRAC and other national CRCs round the world, under an ISO 
11179 commonly designed intergovernance.

Other solutions will probably be discussed in different fora (as suggested 
by the US Statement of Principles). I do not expect this to be seriously 
addressed before the Tunis meeting. But preparation has started.

>For the remainder of the issues in your note below, obviously no one on 
>this list is going to convince you to change your position and at least a 
>number of us are not going to change our positions (that we have done the 
>right things with the draft). I suggest we agree to disagree and move 
>along in the process.

Unfortunately this is not possible. As I indicated it many times: I only 
object one word in your document ("replace RFC 3066" instead of "complement 
RFC 3066") but it makes that I cannot give up and that your Draft cannot be 
accepted.

Or split your Drafts in another way: what is generic for the Registry 
management in terms of metamodel in a BCP 47, and regroup everything which 
concerns your particular format and its filters in the second document.

Please understand your choice:

- either you want a US Registry, by a US IANA managed by a US ICANN (this 
is the US Statement of Principles, the US law and the increasing 
international understanding ). Do not expect a return to the position ante: 
because everything is based on trust. No one would trust the US if they 
changed their mind again. Also the US attitude is the correct one: all the 
other Govs share the obligation to do the same and the USA said they will 
help. This has a name "digital umbrella", if you add culture to it, it is 
"e-colonisation"; the counter proposition is partition if organised, 
balkanisation otherwise. My own proposition is compartmentalisation, for 
risks and interference containment, but network continuity. CRCs are a key 
element of the needed network new granularity. We created AFRAC for that.

- or you ultimately want a global distributed register for the whole 
internet (all the transitions are possible). I will then be involved since 
I am the only one having worked for four years on its preparation, having a 
team and ties assisting it, being on the board of organisations which will 
be influent there, specifying and planning to have a working server by 
September, etc.. If I am in this WG it is to gain the best knowledge of the 
Registry Language issue and Multilingual Internet, and to find the best 
solution for all through an RFC or a WSIS declaration. I think this should 
be also your target. What is sad is that I will have a running code, while 
you will still be blocked by a one single word.

The IANA/ICANN situation where a single person could decide about a 
worldwide IANA registry under the control of a few allies is coming to an 
end. I cannot document what will be the short term future because we start 
discussing it, and that the people involved are not necessarily those who 
used to be involved up to now. But I expect that by Septembre/Novembre we 
will know far better, technically and politically. I can however tell you 
from the past that this should go quickly enough (one or two years) once 
States becomes involved.

I think I cannot be clearer?
jfc











_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru