<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] AG changes reflecting council resolution 20100715-1
- To: "'Kurt Pritz'" <kurt.pritz@xxxxxxxxx>
- Subject: RE: [council] AG changes reflecting council resolution 20100715-1
- From: "Edmon Chung" <edmon@xxxxxxxxxxxxx>
- Date: Wed, 8 Dec 2010 00:52:12 +0800
- Cc: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
- In-reply-to: <C085E952-81D4-4F71-B46D-745C4419A148@icann.org>
- List-id: council@xxxxxxxxxxxxxx
- References: <0f4801cb93c0$b291bad0$17b53070$@asia> <C085E952-81D4-4F71-B46D-745C4419A148@icann.org>
- Sender: owner-council@xxxxxxxxxxxxxx
- Thread-index: AcuUiwZRkLasxb2ESxaYxgRYP/gYlQBkmsNw
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@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
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
> >
> >
> >
> >
> >
> >
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|