DotConnectAfrica Comment- Model 2

[DotAfrica Exec Director <support@xxxxxxxxxxxxxxxxxxxx>]

*Ethiopia:*
**
*Module 2*
2.1.1.1  *String Confusion Objection:*  The applicant guidebook is
very vague in its presentation of the agreed-upon distinctions in this
wording.  The gNSO IDN Working Group two years ago after much discussion and
debate for months unanimously concluded in a 100+ page report that ONLY
visual could lead to string confusion and not one that arises out of
"phonetic or aural or sound" similarity or "meaning" similarity.

The first year-long Katoh IDN committee (the first of a few IDN committees
at ICANN) of several years ago came to only 2  recommendations regarding
future new IDN gTLDs - one of them in essence was explicitly state that IDN
gTLDs of "similar meaning" should not go to existing incumbent registries in
ASCII (or presumably by extension another IDN language/script). Therefore,
ICANN should not pursue something that is not agreed by anyone. There is a
clearly documented evidence for this within ICANN history.   The
recommendations on record is uniform and clear over a decade but the
applicant guidebook is confusing "string confusion" issue.   There is no
confusion across languages, only within a language (for which it is
plausible to consider sound or meaning confusion).   ICANN therefore, needs
to clearly and transparently state that when it comes to strings between
different languages/scripts ONLY visual objection and not sound or meaning
for not only the string similarity confusion stage in Module 1 but also in
any subsequent objections in Module 3 relating to confusion with existing or
currently applied-for strings.

2.1.1.3.2 String requirements:  The current guidebook has to categorically
state in the main text transparently that one or more characters of IDN TLDs
will be allowed with "some possible restrictions that are being discussed"
etc.  There are many scripts, that use ideographs and pictographs that are
information-rich descriptors and not low-information alphabets and
restricting strings to 3 or more characters amounts to insisting  that only
short sentences can be top level domains. .

2.1.1.4.1 and 2.1.1.4.2 Geopolitical Names:

 It might be reasonable to require applicants of names of  countries (either
official or widely  understood or short forms ) and possibly larger regional
(like continental names) or capital or largest/larger cities to produce
non-objection or simple support letters from appropriate authorities.

The requirement that the approving authority will have to read over 300
pages of  ICANN documents,  requiring bypassing of court rights, and
imposing the security rights of another more powerful country, and
indemnifying everyone and agreeing to pay exorbitant fees (by the average
poor country standards) is ludicrous.  It seem like ICANN has no clue how
government works.

There is also no need for any of these sub-country name level restrictions,
since the the current ascii cctlds and the upcoming IDN cctlds already
ensure that every country gets its own TLD to run/operate in a name form
that it either chooses (IDN).   We recommend that we should leave this issue
the way it was in the first Guidebook version - where local jurisdictions
get some say when it comes to country names and major cities when it is
exact or close to the names and no more.

2.2.1 Technical Exchange: ICANN should not limit technical exchange or
correspondence to only one time with an applicant, as appplicants whose
first language is not English would have difficulty reading
complex documentation.    _____________________