[142163] in North American Network Operators' Group
Re: unqualified domains, was ICANN to allow commercial gTLDs
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Jun 19 20:05:21 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <AD2C5346-1AA5-49AC-8378-1AFC6E2A520C@virtualized.org>
Date: Sun, 19 Jun 2011 17:02:57 -0700
To: David Conrad <drc@virtualized.org>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 19, 2011, at 11:59 AM, David Conrad wrote:
> On Jun 19, 2011, at 8:49 AM, Chris Adams wrote:
>> Once upon a time, Randy Bush <randy@psg.com> said:
>>>> Now I'm tempted to be the guy that gets .mail
>>> express that temptation in dollars, and well into two commas.
>> Imagine the "typo-squating" someone could do with .con.
>=20
> See section 2.2.1.1 (and section 2.1.2) of =
http://www.icann.org/en/topics/new-gtlds/rfp-clean-30may11-en.pdf
>=20
> Regards,
> -drc
>=20
To save others some eye strain (apologies for the format when pasted =
from PDF):
2.1.2 History of cybersquatting
ICANN will screen applicants against UDRP cases and legal databases as =
financially feasible for data that may indicate a pattern of =
cybersquatting behavior pursuant to the criteria listed in section =
1.2.1.
The applicant is required to make specific declarations regarding these =
activities in the application. Results returned during the screening =
process will be matched with the disclosures provided by the applicant =
and those instances will be followed up to resolve issues of =
discrepancies or potential false positives.
If no hits are returned, the application will generally pass this =
portion of the background screening.
and
2.2.1.1 String Similarity Review
This review involves a preliminary comparison of each applied-for gTLD =
string against existing TLDs, Reserved Names (see subsection 2.2.1.2), =
and other applied-for strings. The objective of this review is to =
prevent user confusion and loss of confidence in the DNS resulting from =
delegation of many similar strings.
Note: In this Applicant Guidebook, =E2=80=9Csimilar=E2=80=9D means =
strings so similar that they create a probability of user confusion if =
more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is =
intended to augment the objection and dispute resolution process (see =
Module 3, Dispute Resolution Procedures) that addresses all types of =
similarity.
This similarity review will be conducted by an independent String =
Similarity Panel.
2.2.1.1.1 Reviews Performed
The String Similarity Panel=E2=80=99s task is to identify visual string =
similarities that would create a probability of user confusion.
The panel performs this task of assessing similarities that would lead =
to user confusion in four sets of circumstances, when comparing:
=EF=82=B7 Applied-for gTLD strings against existing TLDs and =
reserved names;
=EF=82=B7 Applied-for gTLD strings against other applied-for gTLD =
strings;
=EF=82=B7 Applied-for gTLD strings against strings requested as =
IDN ccTLDs; and
=EF=82=B7 Applied-for 2-character IDN gTLD strings against:
o Every other single character.
o Any other 2-character ASCII string (to protect possible future =
ccTLD delegations).
Module 2 Evaluation ProceduresApplicant Guidebook (30 May 2011)
2-5
Module 2 Evaluation Procedures
Similarity to Existing TLDs or Reserved Names =E2=80=93 This review =
involves cross-checking between each applied-for string and the lists of =
existing TLD strings and Reserved Names to determine whether two strings =
are so similar to one another that they create a probability of user =
confusion.
In the simple case in which an applied-for gTLD string is identical to =
an existing TLD or reserved name, the online application system will not =
allow the application to be submitted.
Testing for identical strings also takes into consideration the code =
point variants listed in any relevant IDN table. For example, protocols =
treat equivalent labels as alternative forms of the same label, just as =
=E2=80=9Cfoo=E2=80=9D and =E2=80=9CFoo=E2=80=9D are treated as =
alternative forms of the same label (RFC 3490).
All TLDs currently in the root zone can be found at =
http://iana.org/domains/root/db/.
IDN tables that have been submitted to ICANN are available at =
http://www.iana.org/domains/idn-tables/.
Similarity to Other Applied-for gTLD Strings (String Contention Sets) =
=E2=80=93 All applied-for gTLD strings will be reviewed against one =
another to identify any similar strings. In performing this review, the =
String Similarity Panel will create contention sets that may be used in =
later stages of evaluation.
A contention set contains at least two applied-for strings identical or =
similar to one another. Refer to Module 4, String Contention Procedures, =
for more information on contention sets and contention resolution.
ICANN will notify applicants who are part of a contention set as soon as =
the String Similarity review is completed. (This provides a longer =
period for contending applicants to reach their own resolution before =
reaching the contention resolution stage.) These contention sets will =
also be published on ICANN=E2=80=99s website.
Similarity to TLD strings requested as IDN ccTLDs -- Applied- for gTLD =
strings will also be reviewed for similarity to TLD strings requested in =
the IDN ccTLD Fast Track process (see =
http://www.icann.org/en/topics/idn/fast-track/). Should a conflict with =
a prospective fast-track IDN ccTLD be identified, ICANN will take the =
following approach to resolving the conflict.
Applicant Guidebook (30 May 2011)
2-6
Module 2 Evaluation Procedures
If one of the applications has completed its respective process before =
the other is lodged, that TLD will be delegated. A gTLD application that =
has successfully completed all relevant evaluation stages, including =
dispute resolution and string contention, if applicable, and is eligible =
for entry into a registry agreement will be considered complete, and =
therefore would not be disqualified by a newly-filed IDN ccTLD request. =
Similarly, an IDN ccTLD request that has completed evaluation (i.e., is =
validated) will be considered complete and therefore would not be =
disqualified by a newly-filed gTLD application.
In the case where neither application has completed its respective =
process, where the gTLD application does not have the required approval =
from the relevant government or public authority, a validated request =
for an IDN ccTLD will prevail and the gTLD application will not be =
approved. The term =E2=80=9Cvalidated=E2=80=9D is defined in the IDN =
ccTLD Fast Track Process Implementation, which can be found at =
http://www.icann.org/en/topics/idn.
In the case where a gTLD applicant has obtained the support or =
non-objection of the relevant government or public authority, but is =
eliminated due to contention with a string requested in the IDN ccTLD =
Fast Track process, a full refund of the evaluation fee is available to =
the applicant if the gTLD application was submitted prior to the =
publication of the ccTLD request.
Review of 2-character IDN strings =E2=80=94 In addition to the above =
reviews, an applied-for gTLD string that is a 2- character IDN string is =
reviewed by the String Similarity Panel for visual similarity to:
a) Any one-character label (in any script), and b) Any possible =
two-character ASCII combination.
An applied-for gTLD string that is found to be too similar to a) or b) =
above will not pass this review.
2.2.1.1.2 Review Methodology
The String Similarity Panel is informed in part by an algorithmic score =
for the visual similarity between each applied-for string and each of =
other existing and applied- for TLDs and reserved names. The score will =
provide one objective measure for consideration by the panel, as part of =
the process of identifying strings likely to result in user confusion. =
In general, applicants should expect that a higher visual similarity =
score suggests a higher probability
Module 2 Evaluation Procedures
that the application will not pass the String Similarity review. =
However, it should be noted that the score is only indicative and that =
the final determination of similarity is entirely up to the Panel=E2=80=99=
s judgment.
The algorithm, user guidelines, and additional background information =
are available to applicants for testing and informational purposes.2 =
Applicants will have the ability to test their strings and obtain =
algorithmic results through the application system prior to submission =
of an application.
The algorithm supports the common characters in Arabic, Chinese, =
Cyrillic, Devanagari, Greek, Japanese, Korean, and Latin scripts. It can =
also compare strings in different scripts to each other.
The panel will also take into account variant characters, as defined in =
any relevant language table, in its determinations. For example, strings =
that are not visually similar but are determined to be variant TLD =
strings based on an IDN table would be placed in a contention set. =
Variant TLD strings that are listed as part of the application will also =
be subject to the string similarity analysis.3
The panel will examine all the algorithm data and perform its own review =
of similarities between strings and whether they rise to the level of =
string confusion. In cases of strings in scripts not yet supported by =
the algorithm, the panel=E2=80=99s assessment process is entirely =
manual.
The panel will use a common standard to test for whether string =
confusion exists, as follows:
Standard for String Confusion =E2=80=93 String confusion exists where a =
string so nearly resembles another visually that it is likely to deceive =
or cause confusion. For the likelihood of confusion to exist, it must be =
probable, not merely possible that confusion will arise in the mind of =
the average, reasonable Internet user. Mere association, in the sense =
that the string brings another string to mind, is insufficient to find a =
likelihood of confusion.
2.2.1.1.3 Outcomes of the String Similarity Review
An application that fails the String Similarity review due to similarity =
to an existing TLD will not pass the Initial Evaluation,
2 See http://icann.sword-group.com/algorithm/
3 In the case where an applicant has listed Declared Variants in its =
application (see subsection 1.3.3), the panel will perform an analysis =
of the listed strings to confirm that the strings are variants according =
to the applicant=E2=80=99s IDN table. This analysis may include =
comparison of applicant IDN tables with other existing tables for the =
same language or script, and forwarding any questions to the applicant.
Applicant Guidebook (30 May 2011)
2-7
Module 2 Evaluation Procedures
and no further reviews will be available. Where an application does not =
pass the String Similarity review, the applicant will be notified as =
soon as the review is completed.
An application for a string that is found too similar to another =
applied-for gTLD string will be placed in a contention set.
An application that passes the String Similarity review is still subject =
to objection by an existing TLD operator or by another gTLD applicant in =
the current application round. That process requires that a string =
confusion objection be filed by an objector having the standing to make =
such an objection. Such category of objection is not limited to visual =
similarity. Rather, confusion based on any type of similarity (including =
visual, aural, or similarity of meaning) may be claimed by an objector. =
Refer to Module 3, Dispute Resolution Procedures, for more information =
about the objection process.
An applicant may file a formal objection against another gTLD =
application on string confusion grounds. Such an objection may, if =
successful, change the configuration of the preliminary contention sets =
in that the two applied-for gTLD strings will be considered in direct =
contention with one another (see Module 4, String Contention =
Procedures). The objection process will not result in removal of an =
application from a contention set.
