Introductory Note by the Staff

The document below was drafted by members of the Business Constituency (BC) of the GNSO and will be submitted to the public consultation on the New gTLD Draft Applicant Guidebook version 3. You can add your thoughts on the BC Draft Statement by clicking the "comment" button above.

Please indicate whether you would you be in favor of an ALAC endorsement of the BC Statement on the DAG v3. Comments will be taken into account until Sunday, 29 November 2009.

---

Draft BC Position on new gTLD Draft Applicant Guidebook v.3

The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on version 3 of the Draft Applicant Guidebook, and commends ICANN Staff and the broader community for the progress being made towards orderly introduction of new gTLDs.

ICANN Staff Recommendations for Rights Protection Mechanisms

The Rights Protection Mechanisms (RPMs) proposed were offered by the Implementation Recommendation Team (IRT) as a package (“tapestry”) for an important reason. Each remedy solves a different problem at a different part of the process. By making some RPMs optional and weakening others, that package is diluted from a minimum baseline of necessary solutions to a series of proposals that do not scale nor adequately address the rights to be protected and concerns of BC members. Please note that the BC's sequence of commenting on each RPM should not be read to mean they are discussed in any priority of importance and the BC considers each RPM to be vital in addressing a specific set of problems.

Uniform Rapid Suspension (of domain names) (URS):

1. Process as detailed by Staff must be mandatory in all newTLD registries

• a) Substantive standard of UDRP must be exactly replicated in URS

> Making URS a best practice is analogous to making seat belts optional

2. The link of the URS for pre-registration in the IP Clearing house as recommended by the IRT should be maintained.

3. The IRT had suggested a fee be imposed on registrant to file an answer if more than 26 domains are at issue. This should be maintained.

4. It would be advisable to mandate issuance of notices in all three modes (email, fax, post) in order to avoid Respondents claiming, subsequent to default, in their Answer that they had no notice of the proceedings.

5. Where in case of default by the Respondent to submit an Answer, the Examiner renders decision is in favour of the Complainant and the site is taken down, if any right of restoration or right to subsequently (after default) enter the process is to be given to the Respondent, they should not have the opportunity to base their Defense (solely or mainly) on the argument that:

• a) they did not receive the notice in any of the three modes (as mentioned above); or
• b) they did not receive the notice since they had not updated their WHOIS/registration information; or
• c) they did not receive the notice since the WHOIS/registration information was inaccurate.

Items b and c and any failure thereto should be the Respondents’ responsibility (otherwise bad actors may use this excuse to game the system)

Moreover, if the Respondent appears after default and taking down of the site, the site should only go back up after a decision is rendered in favour of the Respondent (in order to avoid gaming by bad actors)

6. Successful complainant must have option to transfer the name or cancel, if no appeal filed within 90 days from date of URS decision.

• a) Successful complainant must also have option to have domain suspended until end of its current registration term, and then indefinitely flagged
• b) Flag shall be recorded in clearinghouse so that if anyone seeks to register such name(s) again, they would get a notice.

7. Complainant abuse shall be defined same as Reverse Domain Name Hijacking under UDRP.

8. Meaningful appeal process required, Staff hasn’t made any proposal on that yet, so we cannot comment.

Trade Mark Clearinghouse:

1. Sunrise processes must be standardized and mandatory.

2. The definition of identical match should:

• a. At least be the same as IRT;
• b. should also take into account singular and plural of the Mark; and
• c. take into account typographical variations (for typosquatting)

3. TM notices (misnamed “IP claims”) must be mandatory:

• a. All applications for newTLD domain registrations will be checked against the TMC, regardless whether application is during sunrise period or thereafter (i.e. IP Claims should be available post launch)
• b. If applied-for domain string anywhere contains text of trademark listed in TMC, then TM notice given to applicant per proposal listed in Staff recommendation, if domain is registered then TM owner is notified
• c. TM owners will have option also to trigger notices in the event that applied-for domain string includes the trademark string altered by typographical errors, as determined by an algorithmic tool. For example, yaho0.new would trigger a notice if Yahoo! elected to exercise this option.
• d. Domain applicant must affirmatively respond to the TM notice, either on screen or email, and registrar must maintain written records of such responses for every domain name. TM owner must get notice of every registration that occurs.
• e. The TM Notice should allow registrant to have the option of stipulating their intended purpose.

Globally Protected Marks List (GPML):

The BC sees the rejection of the GPML as a major setback as it leaves open the issue of defensive registrations without any solution being made available to address or remedy this problem related to the launch of new gTLDs.

Absence of this from the Proposed RPMS means that TM holders and Businesses will HAVE TO undertake Defensive Registrations. Effectively PAY for unwanted domains in EVERY new gTLD.

With this in mind, the intended pro-competitive impact of new gTLDs, which we argue must still be confirmed by sound economic research that includes a valid assessment of demand, would be undermined due to such defensive registrations. This therefore, simply imposes an additional cost on business and individual users of the domain name system.

Post Delegation Dispute Resolution Procedure:

The limitations in scope and effectiveness of this RPM when compared to the IRT Report recommendation raise much concern for the BC.

The Staff Proposal is radically different in substance and effectiveness from the IRT Report.

(a) The Registry Operator’s manner of operation or use of a TLD is inconsistent with the representations made in the TLD application as approved by ICANN and incorporated into the applicable Registry Agreement and such operation or use of the TLD is likely to cause confusion with the complainant’s mark; or

(b) The Registry Operator is in breach of the specific rights protection mechanisms

*enumerated in such Registry Operator’s Agreement*and such breach is likely to cause
confusion with complainant’s mark; or

(c) The Registry Operator manner of operation or use of the TLD exhibits a bad faith intent to profit from the systemic registration of domain name registrations therein, which are identical or confusingly similar to the complainant’s mark, meeting any of the following conditions: taking unfair advantage of the distinctive character or the reputation of
the complainant’s mark, or (ii) unjustifiably impairing the distinctive character or the
reputation of the complainant’s mark, or (iii) creating an impermissible likelihood of
confusion with Complainant’s mark. | From Staff Proposal up for Comments:
For a Registry Operator to be liable for toplevel
infringement, a complainant must assert
and prove by clear and convincing evidence that the Registry Operator’s affirmativeconduct in its operation or use of its gTLD, that is identical or confusingly similar to the complainant’s mark, causes or materially contributes to the gTLD: (a) taking unfair advantage of the distinctive character or the reputation of the complainant’s mark, or (b) unjustifiably impairing the distinctive character
or the reputation of the complainant’s mark, or

(c) creating an impermissible likelihood of confusion with the complainant’s mark.
For a Registry Operator to be liable for the conduct at the second level, the complainant must assert and prove by clear and convincing evidence:

(a) that there is substantial ongoing pattern or practice of specific bad faith intent
by the registry operator to profit from the sale of trademark infringing domain names; and

(b) of the registry operator’s bad faith intent to profit from the systematic registration of domain names within the gTLD, that are identical or confusingly similar to the complainant’s mark, which:

takes unfair advantage of the distinctive character or the reputation of the complainant’s mark, or
(ii) unjustifiably impairs the distinctive character or the reputation of the complainant’s mark, or
(iii) creates an impermissible likelihood of confusion with the complainant’s mark. In this regard, it would not be nearly enough to show that the registry operator was on notice of possible of trademark infringement through registrations in the gTLD. |

The Staff Proposal would put the interests of TM holders (and possibly Communities if this applies to Communities also) at risk since once the delegation is made they would not have any recourse or rights to institute Post Delegation Disputes under this policy based on:

• breach of representations in the gTLD application
• breach of Registry Agreements
• systemic breach of TMs in the gTLD as a result of wilful lacunas in Registry Operations leading to infringements__

Registry operations for adding new names are often a highly-automated function. However, a Registry Operator who fails to perform the specific rights protection mechanisms enumerated in its Registry Operator’s Agreement should be subject to PDDRP claims, as set forth in the IRT Final Report.

__

Most importantly creating space in the Staff Proposal so that the Registry is not subject to PDDRP where there is systemic TM infringement based upon breaches mentioned above, dilutes the practical efficacy of the RPM and raises concern with the BC.

Translations of Strings from ASCII to Other Scripts or Languages

The Business Constituency draws ICANN’s attention to an omission of language regarding an appropriate way to address translations of strings from ASCII to other scripts or languages, and the cost of such gTLD applications.

Background

Staff has yet to address Business Constituency concerns, which were posted in DAG v2 public comments, regarding translations of strings. The BC’s previous comment noted:

_We believe that allowing a different entity to apply for and secure the right to manage a transliteration or translation of another TLD string would violate the GNSO recommendation that new TLDs must not be confusingly similar – in sound, sight or meaning ­­-- to any existing TLD._

ICANN must not force TLD operators and applicants to spend financial and human resources on needless challenge processes. Both money and time would be much better spent on development of their TLD on behalf of the global internet community.

The BC encourages ICANN to make it easier for new and existing gTLD applicants and operators to offer multiple variations of their ASCII TLD string, so long as 1) the variations are legitimate translations or transliterations of the applied-for string, and 2) all pre-existing and new registrants in these TLDs have the opportunity to bundle their second level names along with all of the other variations offered by that TLD. For example, .travel should be allowed to pay one application fee for .viajes, and perhaps a small additional fee for “travel” translated or transliterated into Japanese, Korean, German, etc. Furthermore, the registrant of trademark.travel should be given the opportunity to register the equivalent in any additional scripts offered by the TLD operator.

General Comment

A community-based application is inherently one community. The BC believes that a single community must have one TLD operator to manage its space.

In order to best support the widespread use of IDN domains (which are a critical component of a global, multi-lingual Internet), it is important that new gTLD registry operators have an ability to offer registrants their chosen domain names in the many different languages and/or scripts that internet users wish to register.

Once an applicant has been deemed to meet the technical, financial and operational criteria as detailed in the final Applicant Guidebook, and has been approved to have its string delegated, an additional $185,000 for each translation of the approved string could not be justified as cost recovery. The fees should be far less, since the vast majority of the criteria are the same if the same operator runs multiple strings, and not impacted by additional volume. ICANN should encourage registry operators to run IDN gTLD strings, as that is a primary purpose for expansion of the gTLD space. Thus ICANN should offer lower fees, while still recovering its costs.

Also, there are further safeguards in the DAG to ensure operational capability with respect to each additional script the operator seeks to register.

Community support

The BC supports the concept of top-level domain names that are targeted towards a community as the optimal way to expand the gTLD name space. The Business Constituency has consistently stated this for almost 10-years. Allowing new gTLD community-based applicants the ability to serve their markets, in whichever script a registrant would like to register, should add value to the DNS.

The final Applicant Guidebook should facilitate the ability of community-based gTLDs to offer their respective communities the option of registering the same string name in any language or script that the registrant may choose.**

Revised Comparative Evaluation Scoring

The Business Constituency welcomes the opportunity to comment on Draft Applicant Guidebook v3 and draws ICANN’s attention to an inequity in the comparative evaluation scoring.

Background

The Expressions of Interest documentation created by ICANN to recruit evaluators clearly states that the comparative evaluation section will require a high degree of subjectivity; but, at the same time, ICANN does not allow for any subjectivity failure on the part of the reviewer.

ICANN staff, in its Analysis of Public Comment—Amended Guidebook Sections and Explanatory Memoranda DAGv3 noted that “while some comments welcome the tentative lowering of the scoring threshold to 13 out of 16 points, others claim that this level unduly will facilitate gaming and request a return to the previous threshold, 14 out of 16. Since the addition of the explanatory notes in the next version will clarify scoring and additional testing has occurred, it is intended to set the threshold at the previous mark of 14, although still as a tentative approach awaiting consolidated views and comments on this section as expanded.”

General Comment

The BC is concerned that staff may be using the threat of ‘gaming’ as a way to ignore the larger ICANN community’s loud and clear call to allow for 13 of 16 points, as a fair demonstration of nexus to community.

ICANN returning the scoring to 14 of 16 points after the community clearly made its wishes known in comments in DAGv1 and v2 breeds mistrust on the part of applicant and constituent communities alike. Further adding to the frustration are statements such as “additional testing has occurred”, which is hard, if not impossible for the community to measure or verify. We encourage ICANN to publish these test methods and results for community review.

More importantly, the BC believes that ICANN needs to lower the threshold for community-based applicants, otherwise the narrow parameters will undoubtedly lead to a significant number of unnecessary auctions. ICANN has stated that auctions are the solution of last resort, but in not allowing for a reasonable demonstration of nexus to community, ICANN makes it exceedingly difficult for community-based applications to succeed. By allowing for subjectivity on both sides of the equation, ICANN can easily correct this matter.

Recommendation

The BC again recommends that community nexus demonstration scoring be returned to 13 of 16 points to allow for one point (plus or minus) due to human error based on subjective judgment. Unless and until all subjectivity has been removed from the process, ICANN has a duty to provide a fair process for applicants by allowing for one point of subjective error by its evaluators.

Market Differentiation Between New gTLDs

The Business Constituency welcomes the opportunity to comment on Draft Applicant Guidebook v3, however we are concerned that ICANN is failing the test of the GNSO Final Report by overlooking the significant differences between market differentiation and competition.

Background

The BC is apprehensive about what appears to be ICANN’s laissez-faire approach to rolling out new TLDs in the name of ‘competition’. We, along with the GAC, ALAC, IP, ISP constituencies wish to see an orderly rollout of new TLDs that is in keeping with the requested implementation of the GNSO Final Report on the Introduction of New gTLDs. The current approach is contrary to that document, which called for market differentiation, among other key recommendations.

The main argument we are hearing is that now is the time for ‘competition’ – but there has been little discussion about how any new competition might benefit the registrants, or the users of the Internet, and how ‘competition’ will impact the DNS in the longer term.

General Comment

Domain names are mnemonic addresses to enable users of the Internet to access the information or resources that they are seeking. ICANN is presently developing a process which will lead to the introduction of potentially significant numbers of new ASCII gTLDs and IDNs at the top level, both as ccTLDs and gTLDs.

ICANN’s fundamental responsibilities include the coordination of unique indicators, with a recognition that a single authoritative root is a ‘shared space’.

The Internet is nothing like the automobile market or any other consumer goods market where consumers expect there to be many multiples of the same product. The Internet is a unique, shared resource for global use and must be managed according to its special nature.

The current implementation plan is contrary to the GNSO Final Report of the Introduction of New gTLDs to the Board wherein the instruction was to facilitate the introduction of new gTLDs in an orderly way… as well as introducing new gTLDs to include market differentiation. These two aspects refer back to Principle A and Principle C of the seven principles that had consensus from all GNSO constituencies and Nominating Committee representatives. Principle C specifically notes: In addition the introduction of new TLD application process has the potential to promote competition in the provision of registry services, to add consumer choice, market differentiation and service-provider diversity.

ICANN, as the body responsible for the stability and integrity of the unique indictors of the Internet was expected from its inception to avoid domain name and trademark collisions and confusingly similar domains in the DNS. In developing the present version of the new gTLD introduction process, the Board and community has recognized the need to limit defensive registrations, and to prevent the introduction of confusingly similar top level strings.

There is a high risk that defensive registrations will become the norm, rather than achieving the communities’ long-standing goal of ending the practice that forces involuntary defensive registrations in multiple domain name spaces.

With some 24 gTLDs today, one might say there is relatively little concern about this horizon issue; however 5 to 10 years from now – without the protections we are recommending – new applicant registry operators will have no impediment to undermining successful TLDs by selecting names that would undoubtedly diminish established domain spaces. That would be anything but an orderly introduction of new TLDs to the DNS.

Recommendation 1: The BC recommends inclusion of two questions in the final AG:
__

> (1) Which users/registrants/organization/group/community do you intend to serve?
> (2) How does your TLD differentiate itself from others in the DNS?

Answers to these questions will (1) demonstrate consideration given to each domain name space an applicant intends to manage on the Internet; and (2) their differentiation within the DNS. With sharper criteria, ICANN can approve those TLDs that valuably expand the name space and strengthen diversity on the Internet pursuant to the terms of the Affirmation of Commitments.

Leaving this serious omission uncorrected at the start of this new gTLD process i.e., approving applicants irrespective of knowledge that they overlap or undercut other registries, is antithetical to the first principle guiding the new gTLD policy development process, that being that new gTLDs will benefit registrant choice and competition.

As a reminder to all concerned, significant esults we seek in gTLD expansion are reduced user confusion and reduced duplicative, defensive registrations essentially forced upon registrants.

Recommendation 2: Start the process cautiously:

The BC recommends that ICANN start with these safeguards for an orderly approach to market differentiation and, if and when necessary, make adjustments in future Applicant Guidebooks.

Without safeguards for market differentiation in place, applicants and incumbents might be forced to spend precious resources – financial and otherwise – opposing every string that overlaps or undercuts their strings.

ANNEX A

BC Position on Adding Value to the Namespace while Avoiding Unfairness

April 2007

Background

The document draws on existing positions of the ICANN GNSO Business Constituency (BC), and adds detail on the concepts of community support, transparency and rights protection in light of the 2007 process for new generic top-level domain names (gTLDs).

Five principles to determine future expansion

Name space expansion should create added-value. Where there is added-value there will be user demand. In this way expansion will enhance choice, competition and be in the public interest. In a global market economy added-value means differentiation and a practical way to achieve this is if all new names meet five principles:

—
It looks like Ron's position (through the BC) on market differentiation is a rewording of Patrick Baumann's, Chairman of the dotSport LLC Policy Advisory Council letter to PDT. For those who do not know, Ron Andruff is the CEO of dotSport LLC. Full disclosure: I am also a potential applicant for a .sport TLD, under a competing bid and in no way affiliated with dotSport LLC.

http://www.icann.org/correspondence/baumann-to-dengate-thrush-20aug09-en.pdf

in which he basically claims that there would be "no differentiation" if ICANN would allow any other TLD that is more or less close in spirit to the one they are proposing. Hence, .tennis, .golf, etc would conflict with .sport and ICANN should not accept them. At the time, many within the community considered this a bad move.

I also observe that under recommendation 1 (2) above, how can an applicant explain how it differentiates itself from other TLD strings if they are unknown to him at the time of application ? At best, the applicant could comment on how its application differs from com/net/org/info, but not other applications.

Recommendation 1 (1) is already included in the DAG under the community-based TLD criteria. If Ron wants this applied to open TLDs as well, in that case, they are not "open" anymore. I do not see the point.

Regardless of my personal interest in the matter, I think it would do At-Large no good to associate itself with this part of the proposal. Especially, the way the paragraph is worded: " We, along with the GAC, ALAC, IP, ISP constituencies wish to see an orderly rollout of new TLDs ..." leaves one to think that ALAC supports the rest of the text. We may support some of it, but I do not think ALAC really means that "all your sport-related TLDs belong to us"

Regarding the Revised Comparative Evaluation Scoring , I agree with Ron that the scoring should be lowered, if only for the fact that auctions are basically contrary to the public service nature of community-based TLDs. DAGv2 suggested 12 points. DAGv3 upped it to 14. I am concerned that even clearly identifiable communities by applying common sense, the gay community for example, would fail to qualify under the current rules

I would suggest that community-based applicants should preferably have a not-for-profit legal status and how they intent to use their ^profits in the interest of the community they serve. That would help demonstrate they have a clear commitment of offering a public service to the community, rather than pursuing private interests on the back of a community.

contributed by patrick@vande-walle.eu on 2009-11-24 14:36:13 GMT