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 <[log in to unmask]> 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.