Amsterdam report

[Mawaki Chango]

All,

Please find herein the debriefing note of the Amsterdam meeting, from
Aug 29 to 31.)


** IDN **

Starting by the end, IDN was only discussed a couple of hours -- the
last ones of the whole meeting (that is, in the afternoon of Thursday
31 Aug.) Ms. Tina Dam, ICANN newly appointed IDN Program Director,
updated the committee on the testing process. The root server
operators has agreed to the tests. ICANN has contacted two
laboratories in Europe to run the tests, and is waiting for their
response to make the ncessary adjustments and kick-start the lab
tests. The tests will be private in order to avoid disrupting the
Internet, but the comprehensive protocol will be made publicly
available so that anyone who's willing to conduct the same tests in
lab or a private network, etc. could do so. The results will also be
made publicly available.

Cary Karp (Registry Const. but apparently also member of the Tina's
technical team) also provided insights about a few technical hitches
with IDN, e.g. Cyrillic characters that perfectly read in roman
alphabet (ASCII) but are meant to be different from what they look
like to the non-Cyrillic reader => risk of confusion for the end
users. This relates to some criteria the GNSO Committee has been
developping  about typo confusion in the policy for the new gTLD
(expected to take into account issues that may be raised with the
upcoming IDN.)

The meeting did not discuss at all the current IDN Issues Report. So
far, the GNSO Council has an inoperating WG on IDN -- I guess because
there is not yet formally a PDP on IDN, though TORs have been drafted
-- so I confirm (to a question asked by Chun Eung Hwi a while ago)
that it is the President's Advisory Committee and Tina who are
leading the dance (or running the show) if you will. So we may have
to wait for IDN PDP to be formally launched, if at all, to voice any
concerns (through constituency input/statement)!

** NEW gTLD **

The Committee reviewed the draft policy recommendations on new gTLD
resulting from its work so far, the constituency statements and the
public comments, with the objective of identifying the those that
have got consensus or a stronger support than others, etc. Also those
that might need further clarification have been discussed and
improved. Notably, the meeting spent a great deal of time discussing
the criteria of differentiation of the gTLD (typo, purpose, meaning,
etc.)

At the end of the day (literally), and despites the draft outcome
pasted below (see at the bottom of this message; subject to update,)
the trend in the Committee was that we should not try to address in
detail issues of differentiation in meaning and in purpose (e.g.,
.com and .biz?), so long as the possible resulting confusion for the
users will not threaten the stability and security of the Internet,
but the most important is to address typo-confusion (e.g., .com and
.c0m). Please note that this would bring more competition at registry
level, especially in an IDN space where, for example, VeriSign would
no longer be entitled to claim that it should own the
transliterations of the .com in the other language strings,
especially those spoken by huge populations ;) Well that was just an
example; the dominant opinion in the meeting (including mine) was
that it would be healthy to have some sort of competition at registry
level, and it certainly shouldn't be ICANN business to make policy in
order to secure business interests (it is up to the registries to
take business decisions as to how to secure, protect and expand
theirs assets.)

I will forward the latest draft recommendations as soon as they are
posted (they are still in the hands of the chair, Bruce Tonkin, I
beleive.)

Below is a part of the outcome of the discussion on the allocation
methods (with indent mark >). Failing to have time to discuss this
further during the meeting, I sent a message to the Council list
submitting a couple of amendements (without indent mark >), pending
the follow up...

Thanks for your attention.

Mawaki

==== (below starts the aforesaid message copied-pasted) ====

I'd like to suggest below two additions (paragraphs 5 [new] and 8)
to the outcome to this discussion. I was hoping we would have the
opportunity today to review also the outcome of this part of our
yesterday discussion, but apparently we won't. I'm however hoping
that I will get a response from the committee on this - whatever that
is. Thank you for your consideration.


Mawaki

N.B. Some of the language is taken from .berlin public comment.
The recommendation is not that ICANN will necessarily need to
implement all the options put forward, but that ICANN takes heed of
the issue and consider the proposed options and, possibly, explore
some others it may think of.


--- Bruce Tonkin <Bruce.Tonkin at melbourneit.com.au> wrote:

<snip>
>
> 1. Principle - that ICANN recovers its costs of evaluation from the
> application fees
>
> 2. That the fee will be set at the start of the process.
>
> 3. Some applications may cost different amounts to evaluate.
> Therefore
> there maybe different fees depending on the type of application.
>
> 4. It is possible that applicants could pay different amounts
> depending
> on what stage in the process the application reaches.

5. It should also be noted that the possible extra-costs that may
result from the differences in the applicants' working languages as
well as legal systems (as opposed to a specific dominant language and
legal system) should not be held against them, and be left to the
expense to the concerned communities. After all, the Internet is and
must remain a global facility both from the user and demand side and
from the operation and supply side.
>
> 6. ICANN should have a system of grants for applicants that would
> find
> cost recovery a barrier to entry.   This grant would only allow the
> applicant to apply, without any presumption that the application
> would
> be successful.   Grant applications would go through an evaluation
> process.
>
> 7. ICANN should evaluate options for funding the grants.

8. In addition to considering the grant options, other options for
ICANN to address the same concern may include, but not limited to:

-	Organizing periodic awareness and training workshops for interested
stakeholders on the issues of gTLD operation, with the possible
cooperation of relevant global and regional entities or fora;
-	reducing avoidable indirect costs incurred by the applicant
(including shorter and more predictable approval process with fixed
and reliable timelines, standardized contracts, public pre-evaluation
hearings of applications);
-	providing assistance during, and reporting with recommendations at
the end of, the pre-evaluation hearings.
>

======

Outcome of the discussion in Amsterdam regarding
strings that are confusingly similar.


(a) That the gTLD string should not be confusingly similar to an
existing gTLD string.  Confusingly similar means there is a
likelihood
of confusion on the part of the relevant public.   A public comment
process should be used to assist ICANN staff in making this
determination.

 e.g A new gTLD proposal should avoid names that have the potential
to
confuse net users because they are typographically similar to,
variants of, or derived words from, existing gTLDs.

(b) A dispute resolution process using independent arbitrators where
existing registry operators could challenge a decision made by ICANN
staff regarding whether or not a new gTLD string is confusingly
similar to an existing gTLD string.

(c) If a string is successfully challenged as being misleadingly
similar, then no operator may subsequently register it.