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

["Roberto Gaetano" <roberto@xxxxxxxxx>]

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
  
   <http://i.msgtag.com/anx/ktwbnFpaucmourvk/asm/zlmhlD/uecz.gif>