Hi Kurt, Thanks for the response. Nevertheless, as mentioned during our Sunday session, it does seem to me that the staff has mistaken the point of the resolution and what it was directed towards. Just to reiterate a couple of comments mentioned: 1. I feel that the staff briefing to the board you referred to missed the point (especially after the conversation on Sunday) and it appears that staff is confused between the distinct concepts of: - confusingly similar - visually similar / similar - user confusion While there could be overlaps, none of the above are subsets of another. The GNSO new gTLD recommendation 2 was rather clear in that "Strings must not be confusingly similar to an existing top-level domain or a Reserved Name." and had a very extensive set of reference materials on what it meant and was proposed after very thorough deliberations. What the GNSO resolution in July 2010 sought was NOT to seek any changes to our policy recommendation to avoid confusingly similar string, but to request for a change to the AG to more appropriately implement it, which the current version does not. 2. Another item is the confusion with the issue with IDN variants. More specifically, IDN variants are not separate applications, what the GNSO resolution sought was to deal with situations where they are separate applications. The staff briefing seems to have confused the issue because the issue is not similar to the issue of IDN variants. Furthermore, while the staff briefing and your email below seems to assert that the request was not well considered by the wider community and implementation was not straightforward, in fact, the GNSO resolution / letter provided very clear examples of situations where it is straightforward and implementable, and it is based on and not any changes to the GNSO new gTLD recommendations which has wide community input. That along with the lengthy explanations in the original new gTLD policy recommendations and its references do provide very clear explanation on "confusingly similar" and it should be relatively straight forward to understand that if it is the same entity submitting the application there should be no confusion as to source, which is what Recommendation 2 is about. That does not mean that we throw away Recommendation 4: "Strings must not cause any technical instability", so the applicant will still have to pass such evaluation. And be able to explain in the extended evaluation process. Edmon

-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Sunday, December 5, 2010 10:45 PM To: Edmon Chung Cc: Council GNSO Subject: Re: [council] AG changes reflecting council resolution 20100715-1

Edmon, et.al.:

The Board considered that the changes proposed by the GNSO deserve proper consideration and may ultimately prove to be beneficial, but that they could not be considered a simple change to the policy implementation. Issues that should be agreed upon include, for example, operational requirements or contractual conditions as safeguards. Thus, the Board's resolution on string similarity was passed as noted at http://icann.org/en/minutes/resolutions-25sep10-en.htm#2.4, and the language in the proposed final version of the guidebook is in accordance with that resolution.

The position arrived at and presented to the Board in September at the Trondheim workshop was essentially that the exact criteria and requirements for such a situation to be unequivocally fulfilled should be clearly defined and need to be agreed upon by the wider community. This is detailed more fully in the Board paper posted at http://icann.org/en/minutes/board-briefing-materials-1-25sep10-en.pdf.

In relation to the question about the GNSO's motion and corresponding letter recommending that exceptions be granted from a finding of string similarity/confusion, it emerged from discussion and consideration of the request that the criteria and requirements for operation of similar TLDs in a "non- detrimental" manner are not obvious or straightforward.

The GNSO's request is also discussed in the comment summary and analysis on draft version 4 of the guidebook, http://icann.org/en/topics/new-gtlds/summary- analysis-agv4-12nov10-en.pdf, noting that this is a complex issue and should be subject to additional policy consideration. ICANN supports additional work on this being undertaken in the GNSO.

I hope this is helpful and clear. I can answer additional questions.

Regards,

Kurt

On Dec 4, 2010, at 6:36 AM, Edmon Chung wrote:

...

Hi Everyone,

Finally had a chance to look through the proposed final AG...

I refer to our resolution in June and July about Confusingly similar TLD

strings and our request for the AG to be updated regarding the issue: http://gnso.icann.org/resolutions/#201006 (20100610-1) and http://gnso.icann.org/resolutions/#201007 (20100715-1)

...

It seems to me (based on the redline version) that nothing to that

effect seems to have been put in place, and the String Similarity review still says:

...

An application that fails the String Similarity review due to similarity to an existing TLD will not pass the Initial Evaluation, and no further reviews will be available.

I wonder if anyone did find the changes relevant to our resolution...

and whether staff can help explain what actions were taken with regards to the above resolutions...

...

Edmon