[governance] ICANN declined Bulgarian IDN fast-track

[JFC Morfin]

Dear all,

This mail follows from the apparent ICANN denial of the IDNccTLD 
U-label that was chosen by the people and government of Romania.

Introduction

1. This mail comes after years of ICANN's active lack of preparation 
of the only ICANN concern in the WSIS' Internet. ICANN's role, as 
assigned by the USG, is (1) a coordination of the cooperative 
governance and adminance of the so-called legacy "root file" and its 
(2) relations with RIRs (ICP-2). The rules to apply are defined in 
RFC 1591 and ICP-1. Their evolution is defined in the long forgot ICP-3.

ICANN improperly considered the issues created by the IDNA, in which 
its positions are:

- unfit to match the IDNA2008 context,
- intrinsically foreign to the so-called IDNA2010 (practical 
application of IDNA2008 on the user side)
- and IDNA2012 (administration, operations, maintenance, and future 
of the IDNA2008/IDNA2010 system).
- In particular, ICANN is ignorant of the constraints imposed by the 
virtual root open unique matrix ("vroum") evolution.

2. This is why this mail is copied to those who have, or have partly, 
omitted the actual responsibility to address this point in 
conformance with the Internet design/architectural consistency 
principles as defined by RFC 1958, 3439, and IDNA2008:

- the governance at list.cpsr.org mailing list (Annex 1 - debate on the 
list) where the Romanian question was raised.
- the Chair of the ISO 3166 maintenance agency that decides on ccTLDs 
(RFC 1591, ISO 3166, and ICP-1) and ICANN is one of the ten members 
for that reason.
- the IDNA2010 working list on the practical user implementations of 
the IDNA2008, not yet published, RFC set.
- the IETF WG/NEWPREP that is under preparation (Annex 2 - Mail on 
the Internet Users preliminary questions before a possible Stringprep 
replacement cooperative work is to be carried out).
- the Internet User Contributing Group.

3. This mail and its annexes will be attached to my appeal to the IAB 
that is under preparation prior to June 7. This appeal discusses the 
fundamental issues created by the lack of an IESG warning to the 
community in general, and to ICANN, in particular, due to the 
technical impossibility and risks of running a testing project such 
as FAST TRACK, especially if it only involves non-roman IDNccTLDs 
instead of temporary IDNgTLDs that are selected at least for their 
technical neutrality to phishing.

4. This mail must be considered in the IDNA2008/FAST TRACK/Internet 
Users triangular context. As emphasized yesterday in my mail to 
brother at arms George Sadowsky: (in ANNEX 3), in this domain, ICANN 
is technically impaired, its BoD is unaware of the Internet Users' 
world, and its CEO is politically nimble.



TECHNICAL SITUATION SUMMARY

The IDNA2008 success is based upon the fact that no "MUST" affects 
the users. Therefore, the Use side can be entirely flexible in the 
way it matches the Network side limitation in transcoding the user's 
presented characters in what IDNA may accept (this replaces 
stringprep). However, there MUST be a way for this flexibility to be 
organized among users. Otherwise, the way a domain name is mapped 
into an IDNA2008 conformant U-label in a browser may differ from the 
way it is mapped in another one.

An attempt to document this has shown that it was possible, which in 
turn permitted the IDNA2008 consensus. That attempt was consensual at 
the WG (some considering it as the response, others - like me - as a 
default guidance). This is why the Area Director did not accept it 
and the document was declared "dead". Here is the final wrap-up on 
the matter by Vint Cerf (WG Chair) and Lisa Dusseault (Application AD).


<quote from Vint Cerf, Chair>
"Although the last poll regarding the "mappings" document seemed to 
show that most respondents wanted to proceed with submission to the 
IESG, the AD felt that there were mapping issues not addressed to her 
satisfaction. We were unable to agree on a version of mapping that 
would satisfy all concerns among the AD and editors. Reference to 
TR46 seemed to be desired by the AD but as you see from Patrik 
Faltsrom's detailed review of that draft document, there is much to 
discuss and debate. In the end, the only way forward seemed to be to 
declare the WG "mappings" document to be "dead" and to allow a 
version of it to be submitted for publication as an independent submission.
vint"
<end of quote>


<quote from Lisa Dusseault, AD>
"To answer the question about my concerns, I was particularly worried 
about client implementations of mappings: the WG consensus call 
indicated that those who had plans to implement mappings, planned to 
implement TR46 rather than the WG product.

"The WG had a lot of discussions a year ago about whether to leave 
mappings as a free-for-all and what I heard at that time was that a 
lot of people saw the value in consistent mappings across 
implementations -- so a user going from one browser to another, or 
from email to a browser, won't be surprised at where they end 
up.  Unfortunately, we didn't arrive at a conclusion that provided 
that consistency, with one set of mappings proposed by the Unicode 
Consortium and another set proposed by this WG.  I still hope for 
Unicode and IETF participants both to work on understanding why there 
are conflicting requirements and gain a realistic view of what is 
likely to be implemented (and over what transition period).  So, work 
can continue thanks to individual contributions and reviews, or even 
through the possibility of a future WG.

Lisa"
<end of quote>

Such a work does/will continue:

- through my appeal to IESG/IAB for the needed clarifications and 
guidance and then the IUCG workon at iucg.org mailing list as well as 
under the supervision of the iucg at ietf.org mailing list.
- the WG/NEWPREP preparation in order to discuss a consistent 
stringpreps convergence
- possibly through the "locked" ICANN WG/IDNA, as Vint Cerf initially 
proposed it and Internet Users opposed it, since they do not feel 
that they are represented by ICANN.

This work still to be done is actually what FAST TRACK should mainly 
test. So, FAST TRACK is a political way to make believe it was 
carried out and to influence or to block it. The rest of FAST TRACK 
is to test the ICANN IDNcc/gTLD selection and deployment process.



NETWORK NEUTRALITY

The main problem that Internet technology meets is to sustain network 
neutrality for all, that is: no one can be technically privileged for 
whatever reason.

1. The Internet had a linguistic bias. The task of reducing that 
architectural bias was started with IDNA2003.

2. IDNA2008 represents impressive steps ahead in that direction: one 
of them is to have IDNA disconnected from Unicode, while using 
Unicode codepoints to document the Internet User character set. This 
means that whatever the variations on the Internet use, the Internet 
DNS technology will remain unaffected. Since this is the part that 
ICANN is involved with, it means that there is _nothing_ to be tested 
related to the Internet.

3. However,

3.1. IDNA (on the user side and general adminance) is not completed,
3.2. Its architecture is questioned by the IAB and the Applications AD,
3.3. Several Internet users' sides are developing more or less 
actively RFC 1958/3439 and IDNA2008 conformant open alternatives,
3.4. Its punycode algorithm has not unified/simplified the Internet 
linguistic support.

This means, in other words, everything that FAST TRACK is supposed to 
test (i.e. not the technology but the use of the technology) has not 
been agreed upon or documented yet.


Rod Becktrom's action, therefore, tends to replace the Internet 
linguistic technical bias, by an Internet ICANNistic political bias, 
before the IETF, industry, standards, and users agree that the time 
has come for a new naming paradigm - where ICANN and its "naming 
industry" seek to continue to be a part of.

There are many new architectural features, possibilities, and 
opportunities opened by IDNA2008 that will put Internet neutrality 
into a new perspective. In that perspective, it is entirely possible 
to navigate an immensely extended Internet (and its service and 
semantic continuations) without using a single root server system - 
from ICANN or any other root system. This means that no one can 
impeach Romanians from choosing and operating the xn-- tld that they 
want and to safely interoperate on the Internet - even if some of 
their customers start getting Brazilian friends and business by 
error. They will just not pay ICANN for what is worth $10 a year 
(registering a single DN).


THE GRASSROOT SOLUTION WE (USERS) NEED AND WORK ON

This means that other solutions/agreements/behaviors have to be 
found, documented, experimented, deployed, supported, and 
collectively operated, if possible after negotiation with all the 
stakeholders of this new game. You are welcome to join 
workon at idna2010.org 
(http://idna2010.org/mailman/listinfo/workon_idna2010.org) in order 
to start discussing this issue.

The basic need that we have, and are working on, is a tool that is 
able to support network linguistic neutrality on the user side, which 
is the equivalent of  as how IDNA2008 is currently able to ensure 
network linguistic neutrality on the network side. This means that 
IDN should not mean an "internationalized domain name" any more, but 
rather an "Internet domain name" differentiating them from other 
private, community, and (foreign) technologies interoperable domain names.

To achieve this, the rule "first come, first serve" MUST continue to 
apply without resulting in possible visual confusion, phishing risk, 
and class conflicts. This means that

1.  the IDNA2008 charset must be revised in two directions:

- to support metadata (such as French majuscules) in order to not 
occlude any orthotypography
- to be visually coded: this means that visual sorting and indexing 
do match. It also means that the Internet has its own charset where 
codepoints (Unicode) are regrouped by "visual equivalence codes" and 
registrations are "netically" (per netiquette) made on a first come 
first use basis (1) in using this Unisign/Unigraph (name it the way 
you want) charset (2) exclusively reserving the "two 0-Z" table to 
ISO3166 (3) other stringprep processes ranging from IETF technology 
to banks, police, IDs, etc. converge towards the same code standard. 
(this means that we do not speak anymore of "o", "cyrilic o", 
"omicron", but of "half-size circle on the bottom line".

2. the namespace governance is to be renegotiated before unilateral 
confusing decisions are taken by local, cultural, trade groups, or 
mafias...and by private Internet Users. This is to jointly explore 
all of this (rather than imposing a grass-root free of charge, but 
messy, system). Therefore, we created the workon at idna2010.org mailing 
list (http://idna2010.org/mailman/listinfo/workon_idna2010.org)


The internet is an open @large place without monopoly but with alliances.
jfc



ANNEX 1 - Debate over the ITLD Romanian request.

At 20:09 28/05/2010, krum.jonev at dir.bg wrote:
>Hello,
>
>I am new to this list, but I would like to bring to your attention 
>an issue that recently appeared in Bulgaria.
>
>The Ministry of Transport, IT and Communications announced that 
>ICANN has declined the Bulgarian application in the new IDN ccTLD 
>fast-track process, as the proposed string .бг looked too much 
>like the existing ccTLD of Brazil (.br).
>
>However, the people in Bulgaria that are in favor of introducing an 
>IDN ccTLD are practically mad of this decision. A few user groups 
>sent protest letters to the Ministry, advising them to appeal the 
>ICANN`s decision. Others just sit and doesn't know what to do.
>
>Therefore, I am looking for your opinion on those questions - do you 
>think that the string .бг "presents an unacceptably high risk of 
>user confusion" with .br (as said in ICANN reply); and does Bulgaria 
>have any chance if decides to appeal, as this is the desire of the 
>majority of the Internet community? There were even two proposals of 
>imposing a requirement for the IDN ccTLD registry, to allow only 
>registration of domain names that contain an unique Cyrillic letter 
>- in this way, all similarities would be avoided.
>
>Thank you in advance for you time.
>
>Kind regards,
>Krum Jonev

At 20:13 28/05/2010, McTim wrote:

>Hi,
>
>On Fri, May 28, 2010 at 9:09 PM,  <krum.jonev at dir.bg> wrote:
> > Hello,
> >
>
><snip>
>
> > Therefore, I am looking for your opinion on those questions - do you think
> > that the string .бг "presents an unacceptably high risk of user 
> confusion"
> > with .br
>
>yes
>
>  (as said in ICANN reply); and does Bulgaria have any chance if
> > decides to appeal, as this is the desire of the majority of the Internet
> > community?
>
>maybe, is there an appeals process for IDNs?
>
>--
>Cheers,
>
>McTim

At 20:24 28/05/2010, Hong Xue wrote:

>Thanks for the information. Is it a formal "announcement" of ICANN? I
>cannot find it on ICANN website. Or, is it only an outcome of string
>evaluation? In the latter case, you may wish to further communicate
>with ICANN. The restrictive registration policy you mentioned may
>somewhat erase the concerns of user confusion. But domain names are
>accessible globally. An IDN string non-confusing to local  community
>might inflict phishing in other part of the world.
>
>Well, we are right in the mud of how to evaluate "confusingly
>similarity" between IDN scripts and Latin scripts.
>
>Hong

At 22:28 28/05/2010, Yrjö Länsipuro wrote:
>Hi,
>
>Would there be another meaningful Cyrillic string that would stand 
>for Bulgaria? After all, in many cases IDN ccTLD's are not exact 
>translitterations of the ASCII ccTLD, since in many 
>languages/scripts such abbreviations don't make sense.
>
>Please note, too, that Russia could not have a Cyrillic 
>translitteration of .ru, because it would have been identical with 
>ASCII .py (Paraguay)
>
>Best
>
>Yrjö Länsipuro

At 23:00 28/05/2010, krum.jonev at dir.bg wrote:

>Hi,
>
>.бг is the most meaningful representation (was selected with a 
>full consensus between all interested parties) - and the local 
>Internet community doesn`t want to give it up without at least an 
>"appeal attempt" from the government.
>
>Now we are trying to make the government communicate with ICANN and 
>actually do something. That`s why I wanted to ask if we should 
>appeal - maybe write to ICANN ombudsman, etc. However, there isn`t 
>any formal appeal process for the decisions taken in the string 
>evaluation part.
>
>Among the proposed other options are .бгр (first association is 
>Belgrade, not Bulgaria), .бул (first association is "bull") and 
>.българия (which is ridiculously long for a tld).
>
>There are more and more oppinions that any other IDN ccTLD string 
>will "kill the idea", and even some people say that if we can not 
>keep .бг, its better for Bulgaria not to have an IDN ccTLD at all.
>
>Regards,
>Krum

At 23:10 28/05/2010, Avri Doria wrote:

>On 28 May 2010, at 14:13, McTim wrote:
>
> >
> >
> > (as said in ICANN reply); and does Bulgaria have any chance if
> >> decides to appeal, as this is the desire of the majority of the Internet
> >> community?
> >
> > maybe, is there an appeals process for IDNs?
>
>
>was it already subjected to the extended review?
>
>I don't know if there are any appeals from IANA decisions, but if 
>there are, it is the ICANN Board.
>
>a.

At 23:30 28/05/2010, Karl Auerbach wrote:

>On 05/28/2010 11:09 AM, krum.jonev at dir.bg wrote:
>
>>The Ministry of Transport, IT and Communications announced that ICANN
>>has declined the Bulgarian application in the new IDN ccTLD fast-track
>>process, as the proposed string .бг looked too much like the existing
>>ccTLD of Brazil (.br).
>
>The standard of "presents an unacceptably high risk of user 
>confusion" is entirely subjective.  Normally those kinds of choices 
>need to be refined over the years by building a set of principled 
>decisions, decisions that express their logic, rationale, and 
>weighing of the competing interests.  However, ICANN is rather week 
>when it comes to building compendiums of principles to guide these choices.
>
>I have my own TLD, .ewe (not in the ICANN root - see 
>http://eweregistry.cavebear.com/ - it's a prototype, not active) - 
>Anyway, some say that it is too close to .eu to which I sheepishly 
>answer with this question:
>
>    Which came first, female sheep or the European Union?
>
>One could get into endless arguments about which came first, 
>Bulgaria or Brazil.  And they would be fruitless arguments.
>
>But such arguments would reveal a meta issue: Why should Brazil get 
>automatic priority, why is .6r considered as causing an unacceptable 
>confusion to people using .br.  Why is the question not put the 
>other way around, i.e. might .br be unacceptably confusing to users of .6r?
>
>If the principle that we pull from this is "first in time, first in 
>right", then fine.
>
>But what then do we say to people who have been using or advocating 
>certain TLDs for a long time, such as IOD's 2000 proposal to ICANN 
>(for which IOD paid ICANN a $50,000 application fee) for .web, and 
>what about the .biz that was in existence and operating before there 
>even was an ICANN?
>
>And how does the standard of "user confusion" fare when faced with 
>the increasing technical and cultural reality in which domain names 
>are fading as visible identifiers as opposed to address books, 
>shortnames (e.g. .ly, tinyurl, etc), facebook logins, twitter ids, etc etc?
>
>Perhaps that standard is more the creation of the overheated mind of 
>some trademark lawyers who, like the old monarchs of Spain and 
>Portugal, are out to plant their flag of ownership on everything 
>than it is the result of a reasoned, but perhaps transient, choice 
>among actual users on the rapidly evolving internet?
>
>The argument of "unacceptable user" confusion could have been levied 
>against the internet back in the 1970s when there were a 
>multiplicity of different email systems.
>
>And US telephone users are routinely confused by country codes on 
>telephone numbers.
>
>The point is that confusion of some degree will always exist, we 
>ought not to hold back progress because some people can't handle the 
>"future shock".
>
>                 --karl--


At 23:34 28/05/2010, Milton L Mueller wrote:
>Content-Transfer-Encoding: base64> -----Original Message-----
> >
> > Therefore, I am looking for your opinion on those questions - do you
> > think that the string .бг "presents an unacceptably high risk of user
> > confusion" with .br
>
>No. I don't have any trouble distinguishing between a 6 and a b.
>
> > and does Bulgaria have
>[žHÚ[˜ÙHif decides to appeal, as this is the desire of the majority
> > of the Internet community?
>
>ICANN has no formal accountability mechanisms. This is a problem for 
>all of us, not just you.
>However, if by appeal, you mean, "Can I get my government and a 
>bunch of other powerful people to make enough noise to scare ICANN 
>into changing its decision, it is possible. But that is about the 
>only option you have.
>
> > There were even two proposals of imposing a
> > requirement for the IDN ccTLD registry, to allow only registration of
> > domain names that contain an unique Cyrillic letter - in this way, all
> > similarities would be avoided.
>
>Some


At 00:35 29/05/2010, Lee W McKnight wrote:
>Re appeal process or lack thereof:  if there are no rules, then 
>however you play the game must be fair.
>
>And while partial to .br for many reasons, I can't imagine why 
>people or machines would confuse b with cyryllic script regularly.
>
>  In fact it would seem o be a rather low probability action for 
> either people or machines to get the 2 confused.
>
>So my 2 cents: go for it.
>
>Lee

At 01:28 29/05/2010, Desiree Miloshevic wrote:


>On 28 May 2010, at 21:28, Yrjö Länsipuro wrote:
>
>>Hi,
>>
>>Would there be another meaningful Cyrillic string that would stand 
>>for Bulgaria? After all, in many cases IDN ccTLD's are not exact 
>>translitterations of the ASCII ccTLD, since in many 
>>languages/scripts such abbreviations don't make sense.
>  is .бг is less similar to .br then .бр would be?
>
>User's confusion with IDN strings in general, not just with Cyrillic 
>and ASCII,
>is one of expected "by-products", as well as one of many trade-offs 
>we have to live with.
>
>Desiree

At 02:45 29/05/2010, Avri Doria wrote:

>On 28 May 2010, at 18:35, Lee W McKnight wrote:
>
> >
> > And while partial to .br for many reasons, I can't imagine why 
> people or machines would confuse b with cyryllic script regularly.
> >
> > In fact it would seem o be a rather low probability action for 
> either people or machines to get the 2 confused.
> >
>
>
>not that gtld review criteria have any relevance to idn cctld 
>evaluation that i know of.
>but:
>
>and if they were to follow the criteria, untested as they are, for 
>new gTLDs, then it is not the possibility of confusion that counts 
>but the likelihood of confusion.  and one could ask how many 
>Bulgarians or others  were likely to be confused.
>
>
> > 2.1.1.1.1 Review Procedures
> > The String Similarity Panel's task is to identify visual string
> > similarities that would create a probability of user
> > confusion.
>
>...
>
> > Standard for String Confusion ­ String confusion exists where
> > a string so nearly resembles another visually that it is likely to
> > deceive or cause confusion. For the likelihood of confusion
> > to exist, it must be probable, not merely possible that
> > confusion will arise in the mind of the average, reasonable
> > Internet user. Mere association, in the sense that the string
> > brings another string to mind, is insufficient to find a
> > likelihood of confusion.
>
>
>so the question is, does it meet these conditions?  if so, i would 
>suggest standing down.
>
>on the other hand if people who know what they are talking about can 
>attest that there is no probability of confusion, you might 
>have  leg to stand on.
>
>but again, new gTLD draft criteria don't really hold a lot of water, 
>just a place to start a discussion.
>
>a.

At 04:10 29/05/2010, Norbert Klein wrote:

>Yrjö Länsipuro wrote:
> >
> > Would there be another meaningful Cyrillic string that would stand for
> > Bulgaria?
>Why look for another string? It is first of all those who stand for
>Bulgaria who decide what shortcode to use in the code that stands for
>their country, in their script. (Unless there would be an exact double
>rendering like .ru  ->  .py.)
> > After all, in many cases IDN ccTLD's are not exact translitterations
> > of the ASCII ccTLD, since in many languages/scripts such abbreviations
> > don't make sense.
> >
> > Please note, too, that Russia could not have a Cyrillic
> > translitteration of .ru, because it would have been identical with
> > ASCII .py (Paraguay)
>This reference is not appropriate, though an often used irrelevant
>example: ".ru" was probably made from the English word "Russia" (as a
>two-letter ISO country code - like .hu stands for Hungary and not for
>Magyarország in Hungarian) Russia would not have used ".py" (then an
>English abbreviation in Cyrillic script - "Russia" with an "u" is anyway
>different from Россия with an "o"). What was chosen in Russia is a
>Cyrillic rendering of the "Russian Federation" - рф (Р
>усский федерации).
>
>To say that .бг is similar to .br would only be understandable if the
>many ICANN reservations and exclusions for "confusingly similar" would
>also include the "visually impaired" (I am - but I still see the
>difference)...
>
>
>Norbert Klein
>(living in the Bulgarian Embassy in Cambodia)

>At 10:54 29/05/2010, Kleinwächter, Wolfgang wrote:
>Dear List,
>
>I encourage the Bulgarian friends to be more innovative and just to 
>respect that .bg in cyrillic is confusingly similar to .br. When the 
>Russian started to discuss their string in cyrillic, their first 
>choice was .ru in cyrillic, which was confusingly similar to .py, 
>the ccTLD for Paraguay. There was a strong group in the Russian 
>Internet community arguing in favour of .ru in cyrillic as an issue 
>of "sovereignty and pride of the national Russian community". The 
>argument, .ru is owned by Russia and not by ICANN, was used in some 
>heated debates. However, constructive consultations between ICANN 
>and the Russian community led to the .rf cyrllic code (which stands 
>for Russian Federation) and now everybody in Russia is happy to have 
>it. Even President Medwedjew likes .rf. Probably the Bulgarians will 
>find a nice code which allows them to keep the national pride and to 
>accept that you should avoid to confuse users (which than often is 
>misused by all kinds of bad guys).
>
>Wolfgang



ANNEX 2 - Response of JFC MORFIN to George Sadwosky on Rob Beckstrom 
affirmation that ICANN is a nimble organization.


>At 11:33 AM +0200 5/28/10, JFC Morfin wrote:
>>At 16:37 27/05/2010, George Sadowsky wrote:
>>>Bertrand,
>>>
>>>Given Adam's comments below, perhaps you would be willing to 
>>>suggest some concrete areas in which ICANN could be more nimble 
>>>(or choose your own adjectives) while ensuring responsiveness to 
>>>community inputs.
>>
>>George,
>>
>>I am sorry, but no one could be more nimble than our current ICANN CEO!
>>
>>Nobody else, including IESG, IAB, WG/IDNABIS and its Chair (Vint 
>>Cerf), Application AD, etc. was aware that/how IDNA2008 can be 
>>tested by users. The real ICANN break-through is that  from Rod 
>>Beckstrom on, no technology is necessary anymore for the ICANNet to 
>>expand and offer new technical services.
>>
>>jfc

At 13:51 28/05/2010, George Sadowsky wrote:
>JFC,
>This is an unhelpful comment.  First, I can't understand what you 
>are saying.  Second, I sense a high level of sarcasm that occludes 
>the meaning.  Third, it is devoid of constructive suggestions. There 
>is an old Quaker saying that I recommend to you.  "Don't speak 
>unless you can improve upon the quality of silence."

Dear George,

I chair the Projet.FRA for a French speaking space, a language that - 
as you certainly know - IDNA occludes the semantics. This may explain 
that I also found some typos in your "don't speak when eating your 
oatmeal cereals unless ICANN improves their QoS" commercial. I did 
enjoyed the pun: Quicker! ICANN the Quaker (netquake nimble survivor?)!

OK, after som fun, let's turn serious now. I am not here to help, but 
rather to negotiate.

Now, I must say without sarcasm, but with sadness, that this is a 
very helpful comment of yours. It explicitly documents that ICANN 
board members have not yet realized that "their" ICANN does not 
belong to the same world as the Internet Users' world and that they 
are not even trying anymore to understand what Users are saying when 
they contribute. In addition, they jump to negative conclusions and 
engage in unproductive reactions (something of which you did not get 
us used to).

In the Internet Users' world, technology comes first because it says 
whether things are possible or not in a network made of bandwidth, 
protocols, and machines. In ICANN's world, political beliefs come 
first and says whether the intellectual network of contracts, media 
releases, reports etc. is credible enough to support the stakeholders' agenda.

ICANN is obviously not nimble. However, Rod is. What he says is 
technically absurd. However, it is politically credible.

Up to now, politics and engineers went roughly along together because 
they made a couple that roughly shared a common knowledge of what the 
other one thinks the network is (cf. Karl's post).

I am afraid that this has definitely changed on January 7, 2010. On 
that day, the IESG approved IDNA2008, (1) under the pressure of Rod's 
press announcements - cf. WG/IDNABIS Chair (Vint Cerf)'s mails on 
this, and (2) after having considered what the Internet Users' 
resulting technical, adminance, and governance moves will be 
(http://www.ietf.org/id/draft-iucg-afra-reports-00.txt). In addition 
to technology and politics, use (and adminance, i.e. what decides on 
the possible use) is now a real component of Internet life.

Therefore,
- on the one hand, ICANN is pretending to test something that is by 
far not released yet and refuses to discuss the way that it could be 
worked out, even under its proposed "technical leadership" (?),
- on the another hand, the entire IETF process (IAB ongoing work, AD 
oppositions, regular IETF appeal procedure) definitely refuses to 
consider the ICANN moves as having any technical importance.
- and the rest of the body (users' use) has now been set technically 
free to go where it wants.

In this situation,

- ICANN staff and contributors have fully shown their inability to 
make the ICANN situation internally understood and to cooperate to 
reach a solution.
- IETF has to decide if usage architecture belongs to its scope or 
not: I do not expect to have a fully documented and digested IAB 
answer before the end of the year.
- Internet Users comprise three main general categories: (1) active 
users (this kind of governance lists) (2) end users (we never hear 
from them but they vote with their dollar bills), and (3) lead users 
who face and have to admin any new problems first. Lead users now 
have an architectural place in the Internet and a 
technological/governance empowerment capacity. This is not a couple 
anymore but rather a trio.
- The stakeholders at this stage are mostly Unicode/ISOC/Google led

ICANN actually faces the choice that Rod alludes to:

- either to ossify the de facto ISOCANN enhanced co-operation (UN 
support could help but would probably lead to politico/technical confusions),
- either be de facto replaced by the long planned DNSSEC oriented USG emanation
- or to be identified with a "nimble Rod" able to contribute with 
swift responses in negotiationsor power conflicts on behalf of the 
current stakeholders' IN class and USG's DNSSEC strategy.

IN Class commercial and DNSSEC political interests will resist rogue 
users wandering around for a certain time. IDNA, not. Nimble Rod's 
IDNA "make believe" action certainly is what currently protects ICANN 
in that area. The best for all strategy of which ICANN can follow is:

- to support Rod,
- make him informed so that he has a better command of the issue,
- make him negotiate the best way out/compromise in the interest of 
the IN Class, stakeholders' Group, and USG's DNSSEC strategy - before 
the Internet is shacked by the malignant uses of the IDNA2008 implied 
Internet architectural extensions.

ICANN's mistake was to unfairly favor a few IDNccTLDs over IDNgTLDs, 
and to not ensure that they themselves understand first as to what 
IDNA2008 really is.

>I regret that you chose not to provide a constructive response to my query.

As you saw, I did provide you and ICANN with a pair's response. The 
ball is now in your field. After several other board members, you 
will not be able to claim  I did not warn you. Anyway the Draft is 
public as if my IESG appeal 
(http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf), the IESG 
response 
(http://www.ietf.org/iesg/appeal/response-to-morfin-2010-03-10.txt) 
and will be my IAB appeal in a few days and the IAB response.

Best.

jfc


ANNEX 3 - IUCG clarification requirement concerning the IETF/NewPrep project

>As you know, as Internet Users, we believe IDNA2008 represents 
>several major achievements. One is to uncouple the Internet and 
>Unicode while succeeding in using ISO 10646 Unicode generated 
>tables. This is a double big step ahead:
>
>-          giving the Internet its own independent charset.
>-          advancing towards a better transtechnology/usage 
>operational scripting methods unification.
>
>However, IDNA still has to document three major issues that affect 
>stringprep and definitely disqualify any further involvement of 
>Unicode in the network support of strings:
>
>-          lack of support of orthotypograhy (i.e. language script syntax)
>-          the multitude of "stringpreps" functions (at least one 
>per ISO 639-6 linguistic entity) that are now to be specified on the 
>users' side.
>-          how they will be administered together (what will then 
>also concern "newprep")
>
>This is why what you call "IDNA" (just what is IDNA DNS layer 
>related, not what will be User layer related) also cannot qualify at 
>this stage. Everything is to be discussed together; the different 
>stringpreps are equivalents to additional languages with their own 
>orthotypographies.
>
>Now, as users, we have a different, more pragmatic approach that 
>goes further and does not call on this endless kind of discussion. 
>This is because as Internet lead users we are more interested in 
>forward compatibility (i.e. with our needs, innovation, and 
>simplification) than in backward compatibility (installed basis).
>
>In a technological evolution, those who were in advance knew that 
>their solution might not be final. Cf. RFC 1958: the fundamental 
>Internet architectural principle of constant change. The second main 
>architectural Internet principle (RFC 1958 and 3439) is the 
>principle of simplicity. We are not interested in several stringprep 
>solutions due to historical or partial technical analysis. We are 
>interested in a stable, unique, comprehensive manner to format 
>strings in the world digital ecosystem, which is currently mainly 
>under Internet technology that prevents phishing and sustains a 
>single sorting and indexing order.
>
>This is our architectural target. Our implementation strategy is to 
>help and use every effort that can help reaching that target, and 
>oppose (IETF and real world operations) every attempt that would 
>confuse or delay it.
>
>This is because our main interest is not so much to "influence those 
>who design, use, and manage the Internet for it to work better", 
>(without a definition of what "better" may means RFC 3935is 
>meaningless anyway); our main interest is for us and our partners to 
>best use the Internet to better suit our common and present-day 
>needs. This SHOULD be the same. However, experience has shown that 
>it MIGHT not always be the same.
>
>This is why the best is to clarify this issue from the onset. I was 
>not responded to when we started the WG/LTRU on langtags and I had 
>to force the consensus the way we know. I was very clearly responded 
>to in the case of IDNA and we were able to fully support the consensus.
>
>---
>
>My question is therefore:
>
>-          "a need is identified by our Internet user contributing 
>party. This need is for a stable, unique, comprehensive manner to 
>orthotypographically format prepared strings whatever the script and 
>language. Such a format must prevent phishing and support a single 
>registry indexing and sorting order of every possible 
>orthotypographic string, throughout the Internet protocols, related 
>applications, and interoperated technologies.
>-          Is this or is this not also an immediate or ultimate goal 
>for the AD, WG Chair, and WG/newprep possible participants?"
>
>Depending on the response given, we will participate and try to help 
>this wg/newprep effort, or we will pursue our own project, with the 
>ambition to address our needs while keeping things as interoperable 
>with newprep-like endeavors as is possible.
>
>I thank you for your time, attention, and response.
>
>jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20100529/d3b6f519/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t