RE: [ga] is ICANN or is ICANN not?

[Hugh Dierker <hdierker2204@xxxxxxxxx>]

Maybe I am missing something here. If ISO designates, IANA follows, no question except when IANA makes a mistake??? If this is wrong I surely would like to know.
   
  Eric

Roberto Gaetano <roberto@xxxxxxxxx> wrote:
      JFC,
   
  Thank you for your extended essay, that I read with interest.
  Some of the things you write I agree with, some I don't, but I have no intention to start a discussion on the many disagreements.
  I only note that you did not answer the question, which was "What should, in your opinion, IANA do in case ISO decides to reallocate SU [to a different country]?"
   
  Cheers,
  Roberto
   

      
---------------------------------
  From: JFC Morfin [mailto:jefsey@xxxxxxxxxx] 
Sent: 29 January 2007 03:22
To: Roberto Gaetano; 'Kim Davies'
Cc: 'ga'; lrosen@xxxxxxxxxxxx
Subject: RE: [ga] is ICANN or is ICANN not?


  
At 13:56 26/01/2007, Roberto Gaetano wrote:
  I have a simple question for JFC.
What should, in your opinion, IANA do in case ISO decides to reallocate SU, or any one of the codes that have been discontinued and moved to 3166-3?
If you think this should not happen, be aware that this has been already the case for CS, that used to be in 3166-1 as Czekoslowakia, then moved to 3166-3 when the country split in Czech and Slowak Republics, then moved back to 3166-1 as Serbia and Montenegro, and finally moved in its current position in 3166-3 only after the split of Serbia and Montenegro in two separate countries (with separate codes).
And what are the consequences of whatever decision is taken on the integrity and stability?
To me these questions are far more important than how often, and on which subject, IANA is in contact with whom. But that's only my own opinion and preference.

Dear Roberto,
There is a lot of semi-confusion over this issue, and regarding the incertitude created by the IETF, ICANN, and the mails from Kim Davis.  I will attempt to provide you with an impartial comprehensive report, summarising the facts and the questions posed. Then, I will succinctly provide you with my own opinion, for what it is worth


Country designation in the digital world

As the manager of international naming at Tymnet (operating under FCC license), and Secretary (Intlnet) of the international operator consensus, I was directly involved, after the bilateral use of "UK", in the choice of ISO 3166 in 1978, and then in its deployment as alpha3, and further on, the ITU X.121 interoperable plan. The target was peace and stability through a neutral, universally accepted, and interoperable political description of the digital ecosystem. 

>From whet I saw, Jon Postel endorsed this choice in 1984 (RFC 920), when we pasted his team a copy of the alpha2 list we used (for traffic refilers, such as Telex operators and ccTLDS) on our own Gateway with the ARPANET Internet. He confirmed it in his 1994 RFC 1591, legitimising most of the current ccTLDs agreements in saying that the IANA is not in the business of deciding who is a country or not and that ISO 3166 in fact is. This was endorsed by ICANN in its 1999 ICP-1 document (which also quotes Jon Postel ccTLD Memo # 1). In this document, ICANN confuses ISO with a UN body, and links the string "ISO 3166" to an "ISO 3166-1" only page (ISO 3166 extended in size since 1978). ICANN still confirmed that decision, which provides the Internet its stability, in ICP-3 (against wild DNS roots): it explains that our consensual agreement of 1984 (transcribed into RFC 920) is the basis of their own legitimacy.

(NB. The initial namespace was left to right and did not use dots. The TLD concept was created by Robert Trehin and Joe Rinde in 1977. They were called "root names".  Internet TLDs were created to support relations with external networks such as Tymnet (com), Telenet (net), etc. The first one was ".arpa" appended to every Internet name in 1983/84.  The conversion occurred at the Gateway. To avoid confusion with IP addresses (as Tymnet supported addresses [IP and X.121]) as numeric names, conversion only occurred when there was a final dot (the "dot-root"). Root names also had the purpose to split accounting data and statistics among the registries through a simple sort on names in session records).


What does ISO 3166 provide?

As expected, we attained peace and stability for 30 years, because ISO is a universally accepted non-UN association of the national standardisation organisations (ANSI in USA, AFNOR in France, BIS in UK, DIN in Germany, etc.) and because ISO 3166:

- is considered neutral in deciding who a country is and a (special accepted case is ,such as Palestine and the EU)
- is bilingual, and therefore, not associated with any country or culture. 
- addresses the representation of the formerly used names of countries. 
- documents national administrative structures and languages.
- adapts to the needs expressed by the world community and pays special attention to the Internet, having accepted IANA/ICANN as a member of the ISO 3166 MA (However, ICANN only attended twice).
- is the most widely used international standard. It is the basis of the international applications/communications stability and interoperability. It is consistent and interoperable with all of the other international codes (IATA, Banks, Posts, Customs/EDI, E.164, X.121, etc.). The only code built to progressively diverge from it, in not respecting its evolution rules, is the IANA LSERegistry.

ISO 3166 is currently comprises three parts. 
- ISO 3166-2 concerns the administrative national divisions, which should be a basis for the local TLDs. 
- ISO 3166-1 and ISO 3166-3 provides country codes for the present and passed country names. ISO 3166-1 also provides administrative languags.

County codes includes four alpha2, alpha3, alpha4, and digit3 tables:
- alpha3 are numerous enough to designate a country name for ever. We chose alpha3 for national monopoly services.
- digit3 also are numerous enough to designate a country name forever. 
- alpha2s limited numbers obliges the reuse of the code elements that are not in actual use. This is why this list is only adequate for matters related to current sovereignties and names. We chose them for traffic refilers because their practice was related to the then current monopolies. They were used for ccTLDs for the same reason. However, with the deregulation and creation of ICANN they should have switched to alpha3, and thereby permanent stability. Countries may change, but people, registrants, Internet domains, archives, etc. stay. 
-  alpha4 are for the country names documented in alpha3 and not in apha2: countries that no longer have national sovereignty or which changed their name. These codes are for History, archives, genealogy, statistics, and the support of acquired or contracted rights. As such ".su" should have switched to ".suhh", ".yu" to ".yucs", ".cs" to ".cshh".


ISO 3166 answer to the IETF/ICANN worries

IETF members and ICANN staff quoted the ".cs" case as a problem for them (since they did not respect the switch to ".cshh", nor previously changed ccTLDs to apha3 [in this case ".csk"])

For that reason, ISO 3166 MA extended the shorted possible reuse delay from 5 years to 50 years. This obviously provides all the time necessary to freeze the concerned ccTLD registry file, to rename it with the corresponding alpha4, and to have interested users implement an optional plug-in in order to decode the old alpha2 links into their new alpha4 format.


Current worries

There is an increasing worry among the international community (industry, civil society, government, R&D, IGF) due to:

- a lack of respect of ISO 3166 in transferring ".cs" to ".cshh".

- a lack of implementation of ".cs" for Serbia and Montenegro. ICANN says it is because there was no claim. Serbian users say it is because at that time USA was bombing Serbia and Serbia did not consider an US agency like ICANN as neutral. (the same remark was made by Iraqi registrants concerning the management of ".iq" a few years ago).

- the current investigation, which does not refer to ICANN's disrespect of ISO 3166, does not ask as how they should respect ISO 3166, freezing two letter TLDs and transferring their file to ther new four letter TLD under IANA operations, or the switch to their three letter TLD.

- the IETF refusal to consider liaising with ccTLDs on technical issues, when the US Government published its Statements of Principles calling for co-operation with ccTLDs.

- the IETF refusal to consider ccTLD, IDN, and IANA IDN language tables, country code deprecation (or the use of alpha3) related issues when discussing RFC 4646, which creates the LSERegistry documenting subtags to be used to designate languages, scripts, countries, and to link to extended subtag registries. Such subtags can be used for language tags, content filtering, locale file designation, etc.

- the RFC 4646 decision to use ISO 3166 alpha2 to permanently designate a country - instead of alpha3 - and to not respect the ISO 3166 policy for formerly used names of countries, making the IANA LSERegistry non-ISO 3166 interoperable.

- the decision of the IESG and IANA to not implement the RFC 4646 reviewing list, keeping an obsolete private list for that role that commenced to oppose ISO 3166 over "EU", refusing to consider "en-EU", the English used in the European Union regulation, and trade documents.

- the discussion by this same reviewing mailing list of further non-ISO-interoperable entries in the IANA LSER for language variant codes and extensions.

- the Free Software and EU concerns in the WG-IPR documents, which permits IETF standards to be built atop of US software patents while most of the world does not want a software patent system.

- the questionable reference to the ISO 3166 MA into the ICANN/".name" contract and some confusion about ICANN's expectations

- the discussed possible closing of ".ai" for not being in ISO 3166-1 as a code element for a country name, but not of ".uk" in a similar situation.

- the increasing confusion maintained in the ICANN staff mail between ISO 3166 (RFC 1591, ICP-1) and the sole ISO 3166-1 part.

- the delusive responses from Kim Davis when asked to simply state if he is or isnt currently switching the normative axis of ICANN/IANA from ISO 3166, to a progressively non-fully interoperable IANA LSER for example, entering thereby into the "business" of deciding who an e-country is, and favouring in this way on-line applications that are interoperable with the IANA/LSER, to the subsequent detriment of the ISO 3166 interoperable ones.

- his indications that NTIA was kept closely informed, and that ISO 3166 could no longer be the reference "in the fullness of the time" if this was the consensus of an undefined community.

Due to all this, two Rio IGF workshops are already planned (to my knowledge) to discuss/present ISO conformant IANA equivalent systems. This is an Internet split.


Proposition

I hereby repeat the proposition I made. I plan to introduce an IETF Draft and search for co-authors and support for it to be approved as a BCP. It should only state that:

(1) all the IANA registries MUST stay fully _interoperable_ with ISO 3166, 639, 15924, 15897, 11179, 8106 series (country, languages, and scripts names, locale file registration, metadata registries, and time/date areas). 

(2) the LSERegistry will be supervised by an iana-subtags@xxxxxxxx reviewing list, with a veto capacity of a delegate of the ISO 3166, 639, 15924, 15897, 8106 MA. This would annul all of the above-mentioned concerns.

(3) IANA will maintain a public XML version of its registries and co-operate with every effort tending to ensure ISO 11179 conformance and IANA reference information multilingual distribution.


Personal comment 

Due to my initial involvement, I am rather attentive to whatever might affect the normative stability of the digital ecosystem based on ISO, and primarily, the key ISO 3166 and ISO 639 international standards that concerns the Multilingual and Semantic Internet. 

Kim Davis responses were important, just as was Paul Twomey's and David Gross' attitude in Athens when we talked about this. The important thing for me in advocating the interest of users' relational spaces (the role of Intlnet) is to determine who is in the lead, who takes advantage, who obeys, who is manipulated, and what the real attempt is. Additionally, because we are in a real world and the fact that the Tunis deal accepted that the Legacy Internet's governance would remain with ICANN. What are the targets of the Bush administration? What are the Democrats' interests? How should the IGF-organised Multilingual and Semantic Internet develop in order to remain interoperable?

My reading is that there are several US/US industry/ICANN converging/yet different families of interests that are based upon an incorrect hypothesis. This incorrect hypothesis is the assessment that: 

- they can keep forcing technical and administrative status quos, even at the WSIS/IGF, 

- and use them to extend a de facto normative (hence political, societal, and economic) American influence 

- giving the lead to (US) software patented solutions (even in Europe and China, through globality).

There is also an outdated understanding of

(1) the compared role of industry and lead users (all the Internet innovation was developed and develops outside of the IETF)

(2) the IANA function can be developed in size by industry and in this way support the distributed user-centric network architecture evolution. 

All this creates a major risk for world stability, because it will lead to a technical conflict between the US Industry and its own customers, and on-line IANA and off-line ISO conformant applications. The bet is that people will adopt the IANA supported standard. Actually, it may boost civil and governmental initiatives to correct that situation through various architectural evolutions, in disfavour of the commercial current equilibrium and actually balkanizing the internet.

The Members of my Intlnet organisation consider that it is its job to maintain stability in advocating ISO interoperability. This is why I tweaked the work of the IETF WG-LTRU and obtained an RFC 4646 text that still permits (so far) ISO 3166 and 639 interoperability. You may have heard how the interests I contained in this way have reacted to discredit me. This has succeeded to some extent within the IETF community. However, it dramatically helped me outside, as well as within the IETF when using adapted new forms of tweaking. However, I do not have the time or money to continue trying to preserve interoperability between ISO and a deliberately divergent IETF/ICANN/IANA LSERegistry.

My goal was to expose a strategic error and its promoters/supporters. The actions engaged against me, IESG and IAB appeals, and my posts have fully shown who the Members are of a now well identified US Community of Interests. This means that civil society, the economic world, political decision makers, normative and standardisation bodies now have all of the elements. I can certainly provide them with more information if they need it. I intend now to focus on the practical distributed and multilingual "IANA" function that is necessary for the Multilingual and Semantic Internet, after losing two years time blocking and exposing what is probably the first world coup attempt.

Cheers.
jfc
  
 

 
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.