My Cart
Toll Free
888.398.4703
International
++1.760.736.3700

Application Preview

Application number: 1-912-59314 for Big Room Inc.

Generated on 11 06 2012


Applicant Information


1. Full legal name

Big Room Inc.

2. Address of the principal place of business

332-237 Keefer Street
Vancouver BC V6A 1X6
CA

3. Phone number

+1 604 682 6673

4. Fax number

+1 604 682 6673

5. If applicable, website or URL

http:⁄⁄www.bigroom.ca

Primary Contact


6(a). Name

Mr. Jacob Joseph Malthouse

6(b). Title

President

6(c). Address


6(d). Phone Number

+1 778 960 6527

6(e). Fax Number


6(f). Email Address

jacob@doteco.org

Secondary Contact


7(a). Name

Mr. Trevor Scott Bowden

7(b). Title

Secretary

7(c). Address


7(d). Phone Number

+1 778 288 4622

7(e). Fax Number


7(f). Email Address

trevor@doteco.org

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

Canada Business Corporations Act. See http:⁄⁄laws-lois.justice.gc.ca⁄eng⁄acts⁄C-44⁄ (Canada Business Corporations Act, Department of Justice, Canada).

8(c). Attach evidence of the applicant's establishment.

Not Available

9(a). If applying company is publicly traded, provide the exchange and symbol.


9(b). If the applying entity is a subsidiary, provide the parent company.


9(c). If the applying entity is a joint venture, list all joint venture partners.


Applicant Background


11(a). Name(s) and position(s) of all directors

Anastasia Ruth OʹRourkeDirector
David LeviChairman
Jacob Joseph MalthouseDirector
Nicholas FitzpatrickDirector
Trevor Scott BowdenDirector

11(b). Name(s) and position(s) of all officers and partners

Jacob Joseph MalthousePresident
Trevor Scott BowdenSecretary

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

Anastasia Ruth OʹRourkeDirector
Jacob Joseph MalthousePresident
Trevor Scott BowdenSecretary

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility


Applied-for gTLD string


13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

ECO

14(a). If an IDN, provide the A-label (beginning with "xn--").


14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.


14(c). If an IDN, provide the language of the label (in English).


14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).


14(d). If an IDN, provide the script of the label (in English).


14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).


14(e). If an IDN, list all code points contained in the U-label according to Unicode form.


15(a). If an IDN, Attach IDN Tables for the proposed registry.

Not Available

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.


15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.


16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

Big Room anticipates the introduction of the .ECO top level domain (TLD) will be without operational or rendering problems. Based on a decade of experience launching and operating new TLDs, Afilias, the back-end provider of registry services for the .ECO Community TLD, is confident the launch and operation of this TLD presents no known challenges.
The rationale for this opinion includes:
* The string is not complex and is represented in standard ASCII characters and follows relevant technical, operational and policy standards;
* The string length is within lengths currently supported in the root and by ubiquitous Internet programs such as web browsers and mail applications;
* There are no new standards required for the introduction of this TLD;
* No onerous requirements are being made on registrars, registrants or Internet users, and;
* The existing secure, stable and reliable Afilias SRS, DNS, WHOIS and supporting systems and staff are amply provisioned and prepared to meet the needs of this TLD.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).


Mission/Purpose


18(a). Describe the mission/purpose of your proposed gTLD.

The Global Environmental Community, the Community to be served by Big Room’s application and that would be implicitly targeted by any application for the .ECO top level domain (TLD), is an alliance of diverse, long-established, and internationally recognized environmental institutions with millions of members worldwide, a clear majority of which support this application.

Formal international evidence of the Community dates back to 1948, with the founding of the International Union for Conservation of Nature (IUCN). The Community has been organizing for over 60 years with respect to specific events, geographies, and issues through a variety of international alliances like 350.org, the Green Economy Coalition, TckTckTck, and since 1972, the United Nations Environment Programme.

The “eco” label has long been used to identify individuals, organizations, and activities committed to respectful, responsible, and sustainable use of the environment. As this label is widely understood as a representation of association with the Community’s goals and values, and to avoid consumer confusion, it is imperative that policy setting responsibility for the .ECO Community TLD be invested in a representative community member institution that provides stable and ongoing Community input and oversight.

In 2009, Big Room, itself a Certified B Corporation obliged to consider environmental, social and financial interests, launched an international multi-year stakeholder consultation process with the Community on the potential for .ECO to exist as a Community TLD. The process included 7 in-person consultations on 5 continents. Draft policies were published for 3 public comment periods of at least 30 days each.

Key to this process was an international council of community organizations, convened by the Meridian Institute at the request of Big Room, to review and consider the results of these global consultations and to reach consensus on the purpose, principles, and policies for .ECO. The council was governed by a Terms of Reference under which participants engaged. The Terms confirmed involvement on a voluntary basis and without compensation or obligation to support Big Room’s .ECO application.

Since establishment, this international multi-stakeholder community council, made up of leading environmental organizations including WWF International, Greenpeace International, Green Cross International and others, has worked to define the mission, purpose and policies for a .ECO Community TLD that reflects the Community’s interests. The council’s work included 2 in-person meetings (Brussels ⁄ Washington, DC) and more than 20 conference calls between members. In September 2010, the council unanimously adopted a charter for the .ECO Community TLD - the .ECO Policy Consensus. The purpose and principles outlined in the .ECO Policy Consensus define what .ECO will mean as an active expression of the goals, values and interests of the Community. The Consensus has been reviewed and affirmed by the Big Room board of directors.

Consistent with the Community’s history of organizing alliances around issues, in April 2012 the council formalized into the independent, not-for-profit, Dot ECO Global Community Organization (the Organization). The Organization’s mission is to act as the representative membership institution for the .ECO Community TLD, developing and protecting it and the .ECO Policy Consensus for the greater good.

As the .ECO Registry Operator, Big Room will implement the .ECO Policy Consensus under the terms of a contract with the Organization. .ECO will be operated for the benefit of the community in accordance with the commitments and actions below.

The purpose of .ECO is to:

1. Allow members of the Community to more easily identify themselves and other Community members online and to prevent misuse of .ECO domain names that could lead to confusion.

2. Utilize the power of the Internet to foster transparency, information sharing, communication and exchange of ideas to promote environmental goals, interests and values, amongst Community members and those who are exploring that opportunity.

3. Provide a platform for accurate and non-deceptive information and reliable resources to encourage environmental awareness and action on sustainability.

The underlying principles of .ECO are:

1. PRINCIPLE OF TRANSPARENCY AND ACCOUNTABILITY:

Specific commitments include:

a) Registrants will sign a Registrant Agreement that includes, at a minimum, commitments to: maintain an accurate .ECO-profile; to update or review that .ECO-profile at least annually; to link from their .ECO website to their .ECO-profile (if the two are separate); to provide accurate contact information to the Registry; and to submit to a review of their .ECO-profile if requested by the Registry.

b) The Registry has confirmed and maintains a contract with the Organization, and will implement all elements therein including the .ECO Policy Consensus registration policies. It will ensure those policies, procedures, and agreements are publicly available, and publish environmental performance metrics and indicators as part of its annual report.

c) The Organization has established and maintains a governance structure as defined by a set of bylaws, and confirmed and implemented a contract with the Registry. It will advise on disputes and complaints as requested by the Registry, and publicly report on policy development activities, including meetings and advice.

2. PRINCIPLE OF INCLUSIVENESS

While there is an existing, delineated, historically significant Global Environmental Community, part of the purpose for .ECO is to promote diversity and inclusivity in order to advance environmental goals, interests and values, particularly in developing countries.

Specific commitments include:

a) The Registry will assist and encourage registrants in registering .ECO domains and participating in the Community, particularly in developing countries and where linguistic, cultural or socio-economic barriers may exist. It will recognize and promote credible environmental standards and⁄or ways of calculating environmental impacts and performance.

b) The Organization is governed by bylaws that set term limits on participation in its governing and advisory bodies and actively identifies and encourages diverse participation and membership.

3. PRINCIPLE OF IMPROVEMENT

Showing improvement over time while recognizing that, due to degrees of variability across sectors and geography, registering a .ECO domain name does not equate to achieving environmental goals, but that continuous improvement towards environmental goals is a key value of the Community.

Specific commitments include:

a) Registrants will update or review their .ECO-profiles at least annually and show demonstrable progress towards environmental goals over time.

b) The Registry will institute an environmental policy for its own operations and require its suppliers and contractors to meet rigorous environmental standards.

c) The Organization will review the Registry’s environmental performance and implementation of .ECO registration policies, recognizing that as environmental goals evolve and progress over time, the policies governing .ECO may also need to evolve. The Organization will review all .ECO registration policies every two years and recommend revisions to the Registry.

In summary, the .ECO purpose and principles are the result of an extensive, independently-mediated public and community consultation process. The purpose and principles are enshrined in the .ECO Policy Consensus, a charter for the .ECO Community TLD that provides Community policy guidance on Naming, Registration, Accountability, and a grant-making foundation. Together, they ensure a .ECO Community TLD created and operated in the public interest and consistent with the Community’s values.

18(b). How proposed gTLD will benefit registrants, Internet users, and others

WHAT IS THE GOAL OF YOUR TLD IN TERMS OF AREAS OF SPECIALTY, SERVICE LEVELS, OR REPUTATION?

The .ECO Community top level domain (TLD) aims to establish the .ECO System, aggregating the .ECO-profiles of registrants, as a global trusted source of environmental information. Further, the Registry aims to be an internationally-respected TLD that follows best practices in both the Internet and Environmental communities.

In line with this global scope, developing country participation will be prioritized. Recognizing that linguistic diversity is an important part of the Global Environmental Community (the Community), the Registry plans to translate key registry information and systems into the six UN languages.

The .ECO System is also an accountability and compliance tool that will prevent fraudulent registrations and deliver accountability on member actions and commitments, particularly where a lack of transparency contributes to misleading claims about environmental goals or achievements.

II. WHAT DO YOU ANTICIPATE YOUR PROPOSED gTLD WILL ADD TO THE CURRENT SPACE, IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION?

Big Room and the Dot ECO Global Community Organization (the Organization) believe that the .ECO System will provide a useful alternative to other TLDs. It will allow Community members to identify themselves and interact online, including with entities that are providing products and services aligned with Community values.

Currently, there is no unified way for members to identify themselves online. The .ECO System will be a unique and powerful tool, acting as a common global system for identifying members of the Community through the sharing of information about their actions and commitments. The ICANN DNS is the ideal structure to create an ECO identifier; the Internet community is global and organized in a way that reflects multi-stakeholder processes also prevalent in the environmental community.

Innovation

1. The .ECO System: Registrants will have to create a .ECO-profile on registering a .ECO domain. .ECO-profiles will consist of responses to questions about commitments to the environment and confirmation of community membership based on memberships, certifications, reporting, and other accreditations recognized by the Community.

Every Registrant’s .ECO-profile must be linked to their .ECO website. All .ECO-profiles will be publicly maintained by the Registry in an online database called the .ECO System. Together, .ECO-profiles and websites will create a unique resource of freely available, current, structured environmental data.

The following elements are also included in the .ECO System:

a) Verified .ECO-profiles: To speed .ECO domain activation and enhance existing community profiles, registrants with active public certification profiles at specified member organizations can utilize this profile as a proxy for their .ECO-profile.

b) .ECO-toolkits: Tools for calculating environmental performance, offered to registrants that want to improve their .ECO-profiles (eg, energy use or emissions calculators).

c) .ECO Trust-mark: Registrants can opt to make their .ECO website their .ECO-profile or to create a new website at their .ECO domain. If they choose the latter, they must include a .ECO logo (a trust-mark) on the website that links to their .ECO-profile, ensuring visitors to .ECO websites can discover the registrant’s .ECO-profile.

2. Platform Names: The Registry and the Organization will create a class of names reserved for community dialogue and information sharing. These ‘platform names’ may include industry sectors and keywords that will act as forums for community dialogue. (eg, finance.eco or forestry.eco).

3. Community Partnership: A collaborative process established in 2009 resulted in a new partnership between the .ECO Registry and the Community. This partnership comprises cross-board representation, the .ECO Policy Consensus, and the provision of explicit rights to an independent, not-for-profit community organization governed by community-agreed bylaws, connected to the .ECO Registry via a contract. This approach maximizes efficiency and independent multi-stakeholder community dialogue on .ECO policy.

4. Community Accountability: The Registry will layer community forums, online complaint and abuse reporting, dispute resolution, mediation, and arbitration to ensure eligibility, content, use and naming policies are enforced in a transparent and accountable way. The Registry will engage the Organization on matters requiring broader policy decisions. The Registry will conduct ‘spot-checks’ by reviewing .ECO-profiles to ensure compliance. These mechanisms are explained in an Accountability Policy. Also see Q20(e).

5. Independent Foundation: The Registry and Organization will create an independent foundation funded from sales and renewals of .ECO domains and dedicated to supporting environmental goals. Every user that registers a .ECO domain will know how much of their fee is going directly to the foundation, and users can suggest funding priorities.

III. WHAT GOALS DOES YOUR PROPOSED gTLD HAVE IN TERMS OF USER EXPERIENCE?

Community members will be able to rely on .ECO domains as a form of community identification for individuals, organizations and businesses as well as products and services they provide. In line with guidance from the .ECO Policy Consensus, the Registry’s goal will also be to inform and connect members of the Community and encourage actions that support the environment.

Registering a .ECO domain and creating a .ECO-profile will be inexpensive, user friendly, multi-lingual, and accessible to remote and⁄or slow internet connections and mobile platforms such as those in rural environments and⁄or developing countries. Community members will be able to access .ECO domains via existing registrar channels and through Community entities and networks.

Registrants and users will be able to flag exemplary or weak .ECO domains or .ECO-profiles, and suggest areas of improvement for the .ECO policies through the Organization. The Organization will provide a reliable and just accountability framework to resolve disputes in the interests of the Community.

Community members can provide information that highlights their environmental credentials, especially where this information is already public (eg, acknowledged member of an environmental alliance). Registrants can find new ways to engage and achieve Community goals.

Visitors to .ECO services will be able to understand and compare .ECO registrant qualifications and actions via their .ECO-profiles. Search engines will be able to identify the characteristics of a .ECO domain and crawl structured environmental disclosure information in the .ECO-profiles.

IV. PROVIDE A COMPLETE DESCRIPTION OF THE APPLICANT’S INTENDED REGISTRATION POLICIES IN SUPPORT OF THE GOALS LISTED ABOVE

The following registration policy is taken from the .ECO Policy Consensus. It represents Community guidance on the registration policies for the .ECO domain and directs .ECO Registry policies, contracts, and other documents to reflect the community interest. Please also see Q20(e). The Community will continue to review and refine the .ECO Policy Consensus in accordance with the Dot ECO Global Community Organization’s contract with Big Room as the Community Registry Operator.

Registration Policy

Registration Process: When a registrant applies for a .ECO domain, they will fill out a questionnaire that is relevant to the type of use they identify for the website associated with their domain. The answers will form their .ECO-profile. Before DNS resolution is permitted for their domain, the registrant must demonstrate a commitment to the .ECO purpose, principles and policies by agreeing to the registrant agreement, which includes a commitment to the .ECO mission and purpose, affirmation of membership in the Community, and answering the mandatory .ECO-profile questions.

The Registry will prevent DNS resolution of .ECO names until such time as the registrant submits their .ECO-profile information to support their compliance with the .ECO community eligibility requirements. Provided that this step is completed, active DNS resolution will be enabled.

The Registry will employ standard registration lifecycle mechanisms, statuses, and states such as HOLD or LOCK functions, or other existing Extensible Provisioning Protocol (EPP) commands, in order to disallow a domain to be active when a registrant is not in compliance with the community eligibility requirements or under related community dispute resolution procedures.

Use Types: Different .ECO use types will have varying impacts and potential contributions to environmental goals. Therefore, registrants will be asked to respond to different questions based on declared type of use. The five types of .ECO use initially will be: not-for-profit, business, individual, government, and product.

Not-for-profit and business may be sub-divided into categories based on a blend of indicators, including number of employees, revenue and, in the future, by resource usage.

Results of the Registration Process: Answers to the .ECO-profile registration questions will be displayed via a required link from the registrant’s .ECO website and will also be searchable through the .ECO System. Archived versions of past .ECO-profiles will also be available through the .ECO System to show progress over time, in line with the Improvement Principle.

Registration Questions: The Organization will develop a process to establish and regularly review .ECO-profile questions. The questions, which must be verifiable, will cover community-recognized memberships, accreditations, registrations, certifications, and reports that demonstrate active commitment, practice and reporting. Additional questions may: be both qualitative and quantitative; include commitments to environmental and social issues that are considered to be linked to environmental goals; and, reference robust existing environmental standards, requirements, indicators, regulations, codes, and calculators.

Registrants holding certain certifications may automatically qualify to register for .ECO domain names without providing additional details through a .ECO-profile. The Organization will establish the qualifications for certified registrations in advance and agreements with certifiers will be put in place to enable rapid, accurate validation. Certified registrants will be identified and promoted as such within the .ECO System.

Community Naming Policies

The .ECO Policy Consensus includes a Names Policy that provides Community guidance on how to align .ECO domain names with Community interests. Key points from the names policy are summarized as follows:

Premium Names - Community-priority: The Organization will approve a list of community-priority names and will work with the Registry to develop a ‘best use plan’ competition. Allocated names will be donated to the winners for a defined term. All community-priority names will be reviewed every two years against their use plans.

Premium Names - Auction-able: The Registry will publish a list of names for auction. Funds generated from these names will be used to support the Registry and the independent .ECO Foundation.

Controversial Names: While some strings could be used in a manner inconsistent with the Community’s goals, values and⁄or interests or may be highly controversial, and⁄or potentially undermine trust in the .ECO Community TLD, controversial names will not be automatically blocked. Instead, the Organization will develop a method to flag strings based on existing public policy, Community recommendations, industry sector and green-washing watch-lists, and research⁄surveys. Registrants selecting identified names will be notified that registration will be subject to additional scrutiny.

Platform Names: The Registry will reserve names that could be useful in implementing the .ECO Purpose and .ECO System (eg, names of industry sectors, environmental issues or significant nouns).

Other Policies

Other reserved names will be those required in Specification 5 of the new gTLD Registry Agreement per our response to Questions 21 and 22. The Registry’s name, operations names, and variations thereof, names related to ICANN, Internet standards bodies, and United Nations Organizations, Funds and Programs, for delegation of those names to the relevant organizations upon their request.

The complete list of reserved, platform, auction-able, community-priority, and controversial names will be published publicly prior to Sunrise. The Registry will create policies that ensure clear and fair distribution of names. For example, all employees of the Registry and its contractors will be strictly prohibited from bidding for or allocating .ECO domains.

The Registry will continue to use the Trademark Clearinghouse during general availability for notifications of new registrations only where the string is a complete match with a filing in the Trademark Clearinghouse. The Registry will address this process asynchronously to the registration process and in consideration of the technical capabilities of the Trademark Clearinghouse.

Dispute Resolution Mechanisms: Registrants and rights holders will have access to fair and transparent processes to adjudicate claims to domains that also protect registrants against reverse domain hijacking. Names registered in the Sunrise Period will be subject to a Sunrise Dispute Policy. This policy and procedure will be in effect for a finite time period, to provide special protection of qualified trademark rights. See Question 29 (Rights Protection Mechanisms).

.ECO domains will be subject to the Uniform Dispute Resolution Policy (UDRP). See Question 29 (Rights Protection Mechanisms).

.ECO domains will also be subject to the Universal Rapid Suspension (URS) policy. See the URS specifications in Applicant Guidebook Module and Question 29 (Rights Protection Mechanisms) for full details. The Registry will provide systems to take in and administer cases as per ICANN’s Registrar Transfer Dispute Resolutions Policy, allowing registrars to protect registrants by filing disputes about inter-registrar transfers that they believe were unauthorized or improperly executed.

The Registry will support a Community Eligibility Dispute Resolution Process (CEDRP) aligned with the Accountability Policy described in the .ECO Policy Consensus. This dispute process can be initiated by either a member of the .ECO Community or a member of the general public to address an alleged violation of the .ECO member policies or operating requirements by a registrant or registrar.

V. WILL YOUR PROPOSED gTLD IMPOSE ANY MEASURES FOR PROTECTING THE PRIVACY OR CONFIDENTIAL INFORMATION OF REGISTRANTS OR USERS? IF SO, PLEASE DESCRIBE ANY SUCH MEASURES.

The privacy and⁄or confidential information of registrants will be protected through several industry-standard measures. We will minimize the mining of WHOIS data by spammers and other parties who abuse access to the WHOIS. See Question 26 for details regarding searchable WHOIS and rate limiting.

The use of privacy services can protect the privacy and personal data of registrants from parties that mine zone files and WHOIS data. The Registry will allow these services where they comply with ICANN policies and requirements. We are also aware of and respect parties who may use privacy services to protect themselves from political or religious persecution. See Question 28 for details regarding privacy services, abuse management, as well as proposed policies to reduce e-crime by limiting the use of privacy services by malicious parties.

The Registry will notify each of our registrars regarding the purposes for which data about any identified or identifiable natural person (Personal Data) is collected and used, as well as the intended recipients of such Personal Data, as per the requirements of the new gTLD Registry Agreement (Article 2.17). Each registrar must also obtain the consent of each registrant in the TLD for such collection and use of Personal Data. We shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars.

Security policies and procedures will be used in order to protect the registry system and the data it contains from unauthorized access. As the Registry, Big Room will take significant steps to protect Personal Data from misuse, unauthorized disclosure, alteration, or destruction. For full details, see Question 30 (Security Policy) and Question 38 (Escrow).

Registrars must adhere to various information technology policies created to protect registrant data before obtaining accreditation for .ECO. Examples include password management protocols or standards for access to the registry system. See Question 30 (Security Policy).

In order to protect registrant’s data from unauthorized modification, domain transfers, and⁄or deletions, we will offer a registry lock service. See Question 23 (Registry Services).

The Registry will implement a privacy policy for inclusion in agreements with registrants, and⁄or users, and⁄or contractors. Key points include:

Personal Information will not be used for any other purpose without consent. The Registry will not transfer Personal Information to third parties, except for business partners who have agreed to comply with legally required privacy standards, and will use the information only for the purposes disclosed at the time of collection. The Registry may disclose Personal Information in some other limited circumstances, but will specifically describe them to registrants⁄users when we collect the information.

The Registry may disclose Personal Information to a third party without their consent if it has reason to believe that disclosing this information is necessary to identify, contact or bring legal action against someone who may be causing injury to or interference with (either intentionally or unintentionally) the Registryʹs rights or property, other registrants⁄users or anyone else that could be harmed. The Registry may also disclose Personal Information when we believe in good faith that such disclosure is required by and in accordance with the law.

The Registry will take technical, contractual, administrative, and physical security steps to protect Personal Information. We will implement procedures to ensure that Personal Information is only made available to designated staff to carry out the stated purposes communicated to registrants⁄users.

Registrants⁄users will have the right to access their Personal Information for verification. Upon receipt of a written request, the registry will provide them with a copy of their information.

VI. DESCRIBE WHETHER AND IN WHAT WAYS OUTREACH AND COMMUNICATIONS WILL HELP TO ACHIEVE YOUR PROJECTED BENEFITS

Communication and outreach will continue to play an important role in on-going engagement for .ECO registration, policy and accountability processes. Engagement on policy will ensure .ECO reflects the Community’s goals, which will drive registrations and active use of .ECO domains. Engagement on accountability will prevent misuse of .ECO.

Communication will emphasize that the .ECO Community TLD provides a meta-platform for trusted environmental data managed in the public interest by the Community, a way to identify Community members online, and the opportunity to make community-aligned choices based on reliable information. For Community members specifically, there will also be a focus on the opportunity to identify themselves via a .ECO domain, to share their actions in support of the environment, to participate in developing .ECO policies and suggest priorities for the .ECO foundation.

18(c). Describe operating rules to eliminate or minimize social costs or financial resource costs, various types of consumer vulnerabilities.

The .ECO Registry and Dot ECO Global Community Organization believe that the most critical negative consequence for consumers would be a .ECO TLD that does not reflect that the “eco” label is widely understood, both commonly and in regulatory guidance, to represent an association with the members of the environmental community as well as associated concepts and environmentally preferable products and services. 

Consumer protection authorities around the world recognize the fact that the “eco” and “green” labels are powerful tools for consumer communication. Regulators agree that environment-related claims on products and services, including eco-, should only be used when qualifying information can be provided and⁄or the claim proven, including in the following policies: US Federal Trade Commission (FTC) Guides for the Use of Environmental Marketing Claims; UK Department for Environment Food and Rural Affairs (Defra) Green Claims Guidance and Advertising Standards Authority Codes; Environmental Claims: A Guide for Industry and Advertisers in Canada; Green marketing and the Australian Consumer Law; and, European Union Guidelines for Making and Assessing Environmental Claims.

The UN Guidelines for Consumer Protection are also designed to safeguard against false environmental claims. The UN pro consumer Guidelines are designed to protect consumers’ rights, especially those in developing countries, and to raise consumer awareness about the “environmental impact of products and services should be encouraged through such means as product profiles, environmental reports by industry, information centres for consumers, voluntary and transparent eco-labelling programmes and product information hotlines.”

Accordingly, the .ECO Community TLD will restrict .ECO domains to Community members and require registrants to complete and display a .ECO-profile. Without community restrictions and mandatory disclosures, a .ECO TLD could be construed as making environmental claims that would be impossible for consumers to verify.

In order to avoid consumer confusion, it is imperative that policy setting responsibility for the TLD be invested in a representative community member organization that can provide stable and ongoing environmental community input and oversight.

Furthermore, such policy oversight and guidance must be coupled with both pro-active and community-driven enforcement tools that will work to eliminate or minimize social costs arising from such confusion.

The .ECO Policy Consensus provides guidance on enforcement via an Accountability Policy, which will be implemented by the .ECO Registry, as part of any relevant contracts or relationships that the registry enacts. The .ECO Policy Consensus’ Accountability Policy is as follows:

Accountability Policy:

The objective of this policy is to ensure that Registrants comply with the .ECO Purpose and Principles, and that the information provided in .ECO-profiles is of high quality, and is trustworthy and accurate.

.ECO-profiles: In order to use a .ECO domain name a Registrant must sign a registrant agreement that explains the actions they must take in support of the .ECO Purpose and Policies, including:

Updates: Registrants must review and⁄or update their .ECO-profiles at least annually. If they have not updated their .ECO-profile within a year’s time, the Registry will remind them 30 and 10 days prior to the mandatory review date. Domains with .ECO-profiles that still have not been reviewed or updated after 12 months following this reminder will be subject to takedown proceedings.

Cross-referencing: Anywhere that .ECO (or Dot Eco) is mentioned and⁄or the .ECO logo is displayed on a Registrant’s website or materials, that Registrant’s corresponding .ECO-profile URL must also be displayed (as a footnote or hyperlink) so that the .ECO logo cannot be used without direct reference to the Registrant’s .ECO-profile.

Registration Questions: Registrants must complete all mandatory .ECO-profile questions.

Independently Verified Information: Registrants can indicate whether or not the information in their .ECO-profile has been independently verified and if so, the verifier and the validity or expiry dates.

Reviews: The Registry will develop a set of review guidelines that will maximize .ECO System accuracy. A report on the review process and results will be submitted annually to the Organization by the Registry.

Complaints: Every .ECO-profile will have a “report abuse” link where a complaint can be submitted about that Registrant to the Registry. The Registry, or an approved dispute resolution provider contracted by the Registry, will evaluate complaints against the Registrant Agreement and decide whether and how to take action. The Organization will receive regular reports of all complaints received. In cases where there is not a clear resolution to the complaint in the view of the Registrant, Registry, or the Organization, the case may be referred to a dispute resolution process. The Registry, in keeping with the Principles of Improvement and Inclusiveness, will work with the affected Registrant through the dispute resolution process with the aim of reaching a mutually agreeable solution on behalf of the Community. In cases where complaints are not addressed to the satisfaction of the Registry and the Organization, the Registrant’s domain name may be suspended or taken down. The Registry will document receipt of a response to all such complaints.

Complaints submitted by Registrants, who will have been verified as Community members, will be given higher priority than those from the general public. The Registry will also consider the number and nature of complaints received about a given Registrant when considering suspension or take-down measures.

Dispute Resolution Process: Complaints will first be addressed between the Registry, or a dispute resolution party contracted by the Registry, and the relevant Registrant. If a Registrant is dissatisfied with the decision, they may pay a fee to seek the recommendation of an independent mediator or arbiter approved by the Registry. If the Registry is dissatisfied with the recommendation of the independent mediator or arbiter, the Registry may choose to refer the dispute to the Organization for a final decision.

Comments on .ECO-Profiles: Every .ECO-profile will have a public comment forum. The registrant whose .ECO domain name is associated with an .ECO-profile will have the right to moderate comments on their profile. Registrants may also post comments about .ECO-profiles to relevant platform name pages.

The Registry will establish and regularly review a set of recommended moderation and commenting guidelines for registrants. The guidelines will include a way for Registrants to handle malicious comments.

Community Comment Forum: The Registry will implement a community forum where community members can interact with each other, the Registry, and the Organization, consistent with the community purpose of .ECO.

Take Down Process: Registrants that are found to be in breach of the .ECO Registrant Agreement, and therefore the purpose and policies of .ECO will be notified by email and given 60 days to come into compliance or opt for dispute resolution with the Registry. If this is not done, the .ECO domain name in question will be suspended for 60 days. If compliance is still not achieved, the domain will be taken down by the Registry.

Transparency: The Registry’s process for evaluating and resolving complaints and the results of disputes will be made public. The Registry will make public an annual report to the Organization summarizing its actions regarding this policy to ensure alignment with the purpose and principles of the .ECO Community TLD.

Please see response to Question 28 for additional abuse prevention and mitigation measures. These functions are resourced by Big Room and its partners or third-parties as appropriate.

I. HOW WILL MULTIPLE APPLICATIONS FOR A PARTICULAR DOMAIN NAME BE RESOLVED, FOR EXAMPLE, BY AUCTION OR ON A FIRST-COME⁄FIRST-SERVE BASIS?

The Registry will try to provide a fair opportunity for Community members to register for .ECO while also minimizing related costs to rights holders. We will hold three registration phases with specific allocation rules, as outlined below:

Phase 1 – Rights Holders & Community:

The first phase will run for a limited time period prior to the Land-rush and General Availability phases. In the past, Sunrise periods have been used in the launch of numerous TLDs including .INFO, .BIZ, .MOBI, .TEL, .ME, .XXX and others. These efforts have proven the need for a balanced approach that provides intellectual property (IP) holders an opportunity to register names they feel apply to their IP.

Big Room will hold a Sunrise period where holders of internationally recognized filed trademarks or possibly holders of existing (legacy) gTLD strings that are a perfect match to the .ECO string that they are applying for, will have the opportunity to apply for registration. A qualified third party must verify each trademark and⁄or legacy gTLD. In addition, the applicant must have a completed .ECO-profile and meet all criteria in order to be accepted as a Community member. No application will be accepted without these verifications.

Big Room plans to use the Trademark Clearinghouse to periodically check Sunrise applications against registered trademarks. If the trademark is verified and valid, we expect to be able to inform the IP holder that a Sunrise application for their string has been submitted. IP holders are only involved if an application is submitted that is an exact match to their registered trademark.

An auction process will determine the awarding party in the event that there is more than one valid Sunrise application for a given string.

Community-priority and Platform Names

1. Premium Names, including those that could have added community value, in two categories:

a) Community-priority: Prior to launch, the Organization will approve a list of community-priority names. The Registry will, with Organization input, develop rules for a best-use plan competition. Names allocated in the competition will be donated to the winners for a defined term. All community-priority names will be reviewed every two years by the Registry against their use-plans.

b) Auction-able: The Registry will also publish a list of names available for auction during sunrise. Funds generated from these names will be used to support the Registry.

2. Platform Names: The Registry will reserve a list of names that may be useful to the .ECO System, such as: industry sectors (eg, transportation); environmental issues (eg, biodiversity); nouns with environmental significance (eg, water); and, other names deemed technically useful to the Registry’s implementation of .ECO as a community TLD (eg, council).

Phase 2 - Land Rush:

The second phase aims to reduce costs for registrants by minimizing speculation in the secondary market. It will run during a predetermined time period preceding the General Availability phase. During this period, applications will be accepted for any non-IP related strings. An auction will determine the awarding party should multiple applications be submitted for the same name. Registration restrictions to qualified .ECO members still apply.

Phase 3 - General Availability:

Phases 1 and 2 act to minimize the costs to potential registrants and provide a fair opportunity for registration. The third and final General Availability phase opens the .ECO Registry to live registrations on a first come, first served basis. Registration restrictions to qualified .ECO members still apply.

II. EXPLAIN ANY COST BENEFITS FOR REGISTRANTS YOU INTEND TO IMPLEMENT (EG, ADVANTAGEOUS PRICING, INTRODUCTORY DISCOUNTS, BULK REGISTRATION DISCOUNTS).

Specific discounts will be agreed upon with consultation and input from Community member alliances and entities. Members of these entities may receive discounts on .ECO domain names. For example, an agreement with an international environmental membership organization that allows its members to receive discounts on .ECO domains.

Registrants who register through .ECO Community members that have been through a verification process may also receive discounts. For example, certified B Corporation companies could obtain a discount on .ECO domain names.

Discounts may also be offered for business reasons to encourage growth in the number of active .ECO domain names; as a method of raising awareness or funding certain environmental campaigns and⁄or causes; and⁄or in periodic promotions to encourage innovative and creative use of .ECO domain names in support of the environment.

III. NOTE THAT THE REGISTRY AGREEMENT REQUIRES THAT REGISTRARS BE OFFERED THE OPTION TO OBTAIN INITIAL DOMAIN NAME REGISTRATIONS FOR PERIODS OF ONE TO TEN YEARS AT THE DISCRETION OF THE REGISTRAR, BUT NO GREATER THAN TEN YEARS. ADDITIONALLY, THE REGISTRY AGREEMENT REQUIRES ADVANCE WRITTEN NOTICE OF PRICE INCREASES. DO YOU INTEND TO MAKE CONTRACTUAL COMMITMENTS TO REGISTRANTS REGARDING THE MAGNITUDE OF PRICE ESCALATION? IF SO, PLEASE DESCRIBE YOUR PLANS.

The Community market will determine the viability of .ECO pricing. The Registry intends to maintain the freedom to set pricing first, based on costs and demand, in accordance with guidance from the Community, and in agreement with any ICANN and⁄or Registry Agreement criteria.

Big Room does not plan to make specific contractual price escalation commitments to our registrants. Any changes in pricing will be aligned with the mission⁄purpose of the .ECO Community TLD, will take the environmental community into account, and will be determined with input and consultation from the .ECO Organization.

Community-based Designation


19. Is the application for a community-based TLD?

Yes

20(a). Provide the name and full description of the community that the applicant is committing to serve.

The Global Environmental Community (the Community) – which the applicant Big Room Inc. commits to serve as the .ECO registry operator – is multi-stakeholder in nature, comprising individuals and entities (not-for-profit, business and government) that have come together for over 60 years through a variety of international alliances dedicated to the respectful, responsible and sustainable use of the environment.
In keeping with this tradition and in response to ICANN’s new gTLD program, the Community has established an alliance with the goal of creating and operating .ECO in the public interest and in keeping with the Community’s values.
The alliance formed in March 2009 by establishing a terms of reference for the .ECO Community Council. In September 2010 the stakeholders unanimously adopted a policy consensus for .ECO, including the purpose, principles and policies. In April 2012, council members formed the Dot ECO Global Community Organization (the Organization) to formally represent the Community in relation to .ECO. The Organization has signed an agreement with Big Room to apply to act as the registry operator of the .ECO Community TLD. The agreement was the result of 3 years of independently mediated discussion amongst the international council of Community members.
The Organization represents the majority of the Community including over 50 leading environmental groups from around the globe.
HOW THE COMMUNITY IS DELINEATED
Members of the Community are delineated from Internet users generally by community-recognized memberships, accreditations, registrations, and certifications that demonstrate active commitment, practice and reporting.
Community members include:
Relevant not-for-profit environmental organizations (ie, accredited by relevant United Nations (UN) bodies; International Union for Conservation of Nature (IUCN) member; proof of not-for-profit legal entity status with documented environmental mission).
Businesses (ie, members of environmental organizations; UN Global Compact participants; hold internationally-recognized environmental certifications; report to a global sustainability standard).
Government agencies with environmental missions (ie, UN bodies, national⁄sub-national government agencies with environmental responsibilities).
Individuals (ie, members of environmental organizations; academics; certified environmental professionals).
HOW THE COMMUNITY IS STRUCTURED AND ORGANIZED
The Community has historically structured and organized itself and its work through an international network of organizations, including millions of individual members with strongly aligned goals, values and interests. As well as collaborating via long-standing international multi-stakeholder fora and membership organizations, members traditionally organize through multi-organization alliances around specific events, geographies, and issues. The approach of forming alliances parallels the Internet community’s method of designing solutions for issues of interest, most notably the Internet Governance Forum Dynamic Coalitions and Internet Engineering Task Force Birds-Of-a-Feather sessions. The alliance supporting this application embodies this organizing tradition.
Examples include:
International multi-stakeholder fora, eg, UN Environment Programme
Membership organizations, eg, WWF,Greenpeace and Friends of the Earth (FOE), the largest environmental membership organizations in the world, collectively representing 10 million individual members
Event-focused alliances, eg, TckTckTck, an alliance of 300 organizations formed to work for a fair, binding treaty at the 2010 Copenhagen climate summit
Geography-specific groups, eg, The Northern Alliance for Sustainability (ANPED), brings together not-for-profit organizations from the Northern hemisphere to create and protect sustainable communities
Issue-specific alliances, eg, 350.org, a grassroots organization working in over 188 countries to solve the climate crisis
WHEN THE COMMUNITY WAS ESTABLISHED
1948: First formal Community institution, the International Union for Conservation of Nature (IUCN), was established. Not-for-profit organizations, businesses and governments came together to address pressing environmental challenges.
1972: Global Environmental Community recognized by the world’s governments on creation of the UN Environment Programme (UNEP), the UN’s designated authority for addressing environmental issues at the global and regional level.
COMMUNITY ACTIVITES TO DATE
Some key global historical events:
International Organizations Established – IUCN (1948); World Wildlife Fund International (WWF) (1961); Friends of the Earth International (FOE), Greenpeace International (Greenpeace) (1971); UNEP (1972)
UN Global Summits – organizations, businesses and governments participate in global environmental events: UN Conference on the Human Environment (1972); Rio UN Conference on Environment and Development (“Earth Summit”) (1992); Johannesburg World Summit on Sustainable Development (2002); Rio + 20 UN Conference on Sustainable Development (2012)
Organizations⁄UN collaborate on Global Conservation – “The World Conservation Strategy” by IUCN, UNEP, and WWF (1980); “World Charter for Nature” by IUCN adopted by UN (1982); “Caring for the Earth” by IUCN, UNEP, and WWF (1991)
Binding International Legal Conventions – Convention on Wetlands (Ramsar) (1971); Convention on International Trade in Endangered Species (1973); Convention on Biological Diversity (1992); UN Framework Convention on Climate Change (1994); Kyoto Protocol (1997)
Integration of Environmental, Economic & Social Issues – Concept of Sustainable Development is established in “Our Common Future” (1987); World Business Council for Sustainable Development (WBCSD) (1995); Millennium Development Goals (2000); UN Global Compact (2004)
Consumer Protection – 1st ecolabel, The Blue Angel, created by the German government (1978); UN amends “UN Guidelines for Consumer Protection” to include environmental issues (1999); US Federal Trade Commission issues “Green Guides” to prevent false environmental claims (1992, 1996, 1998, 2010 review)
ESTIMATED SIZE OF THE COMMUNITY
The Community’s considerable size, longevity and enduring importance are evidenced by the nature and global range of its alliances of millions of individuals and entities, the variety of multi-stakeholder processes, the number of green businesses, and continuous global intergovernmental engagement.
Estimated Membership
40,000+ Not-for-Profit Organizations, eg, 34,376 US environmental organizations (2011 Internal Revenue Service Exempt Organizations Business Master File, National Center for Charitable Statistics); 6,157 in the UK (March 2012, 1⁄3 of 18,470 Environment ⁄ Conservation ⁄ Heritage registered charities, Charity Commission);
148,000+ Businesses, eg, 68,200 US businesses committed to environmental sustainability (Pew Charitable Trust, “The Clean Energy Economy”, 2009); 80,000 small and medium enterprises in the EU use certified environmental management systems (Danish Technological Institute, “SMEs and the Environment in the European Union”, 2010);
193+ Environment-focused Governmental Bodies – eg, 193 member states (UN website, March 2012);
18 million+ Individuals, eg, International: WWF, 5M; Greenpeace, 2.8M; FOE, 2M; Ocean Conservancy, 0.5M. National: National Wildlife Federation, 4M; Sierra Club, 1.4M; National Resources Defense Council, 1.2M; The Nature Conservancy, 1M (Members, 2010).
Estimated Geographic Extent
Membership Organization Offices: WWF (62 countries & presence in 100); Greenpeace (28 countries & presence in 40); FOE (77 national groups, 13 affiliates); IUCN Membership (101 international, 875 national organizations; 89 states; 124 government agencies);
UNEP Governing Council: 58 elected UN member seats; UNEP accredited organizations from 75 countries.

20(b). Explain the applicant's relationship to the community identified in 20(a).

RELATIONS TO COMMUNITY ORGANIZATIONS
All the major international membership organizations (IUCN, WWF, Greenpeace, Friends of the Earth), the biggest global business and environment organizations (World Business Council for Sustainable Development (WBCSD), Green Economy Coalition), the largest international Community alliances (350.org, TckTckTck) and the key global environmental reporting standards (Global Reporting Initiative, Carbon Disclosure Project) support the creation of .ECO as a Community TLD. The United Nations Environment Programme (UNEP) has been an observer to the .ECO community process since 2010.
As the world’s largest and longest established organizations and alliances, these institutions represent over 190 countries, 1,000 entities, and more than 10 million individual members.
Organizations supporting the .ECO community-led approach:
Intergovernmental:
UN Environment Programme, UN Global Compact
International:
350.org, Amazon Watch, ANPED, BirdLife International, B Lab, Carbon Disclosure Project, Care2, Conservation International, DEKRA, Fauna & Flora International, Friends of the Earth International, Global Campaign for Climate Action (TckTckTck), Global Environmental Institute, Global Footprint Network, Global Reporting Initiative (GRI), Green Belt Movement International, Green Cross International, Green Economy Coalition, GreenTV, Greenpeace, Greenseal, International Centre for Trade and Sustainable Development, International Institute for Sustainable Development, IPAM Instituto de Pesquisa Ambiental da Amazônia, ISEAL, IUCN, Ocean Conservancy, People 4 Earth, Rainforest Action Network, Rare Conservation, UL Environment, UNEP⁄Wuppertal Institute Collaborating Centre, Verite, WBCSD, Wildlife Friendly Enterprise Network, WWF
National:
Akatu Institute, Canadian Parks and Wilderness Society, chinadialogue, David Suzuki Foundation, Development Alternatives, Dogwood Initiative, Ecojustice, Ecotrust Australia, Ecotrust Canada, Ecotrust US, Friends of Nature, Friends of the Earth Canada, Green America, Institute for Public and Environmental Affairs, Instituto Ethos, Pembina Institute, Project Dirt, Smart Approved Watermark, The Big Wild, YPB ⁄ LEAD Indonesia
The application explicitly addresses members active at the international level, while national-level members are implicitly addressed due to their more limited focus.
Support of .ECO continues to grow and will extend into the gTLD application review period. A current list of supporters can be found at www.doteco.org.
RELATIONS TO THE COMMUNITY AND ITS CONSTITUENT PARTS
Dot ECO Global Community Organization
Consistent with the Community’s history of organizing alliances around issues, leading members of the Community established the Dot ECO Global Community Organization (the Organization), an independent not-for-profit organization, as the representative membership institution for on-going .ECO policy development.
The Organization’s founding board comprises individuals from not-for-profit organizations involved in .ECO policy development since 2009 via the .ECO Community Council, and includes members from Brazil, France, India, Switzerland, the UK, and the US. The International Institute for Sustainable Development (IISD), founded in 1990 as a non-partisan charitable organization focused on sustainable development, acts as the secretariat for the Organization.
The 13 .ECO Community Council member organizations form the inaugural Community Council of the Organization to provide policy advice to the board: WWF International (Co-chair); Akatu Institute (Co-chair); B Lab; Conservation International; David Suzuki Foundation; Development Alternatives; Green Belt Movement International; Green Cross International; GreenTV; Greenpeace International; The ISEAL Alliance; UL Environment, and Verite. UNEP has been an observer to the Council since 2010 and in March 2012, the UN Department of Economic and Social Affairs Division for Sustainable Development indicated its interest to act as an observer.
The Organization has signed a contract for Big Room, a certified B Corporation, to apply for and act as the Registry operator for the .ECO Community TLD.
Information about the Organization background, establishment, governance and contract with Big Room is attached in 20f (20f-ECO-community-organization.pdf).
In line with the Community’s principles, Big Room’s founders, board members, investors, advisors, and observers have decades of combined environmental experience. The company is funded by a diverse group of mission-aligned leading environmental and social investors, including lead investor Working Enterprises, which has committed to donating its proceeds from .ECO to charity.
Big Room’s core business is in enhancing accountability in the green marketplace. Since 2008 it has operated Ecolabel Index (ecolabelindex.com), the authoritative global directory of environmental certifications. The site enables transparency and disclosure in the certification industry. A recognized authority on certification systems in green purchasing and supply chains, Big Room has provided advisory services to the General Services Administration of the US government, UNEP, the Sustainability Consortium, the Green Products Roundtable, and others.
Big Room was founded by Trevor Bowden, Jacob Malthouse and Dr. Anastasia O’Rourke. Trevor and Jacob previously worked at UNEP, where they launched the UN Principles for Responsible Investment. Trevor has also consulted to international banks on environmental risk. Jacob was previously Liaison to the Caribbean and Canada at ICANN. Anastasia is a leading environmental researcher, authoring over 20 reports, articles and whitepapers and has worked with INSEAD Business School, Yale University, The Carbon Trust, and the City of Sydney.
The co-founders also have environmental academic expertise: Trevor holds an MSc in Public Understanding of Environmental Change, University College London and a Diploma in Environmental Studies, McGill University; Jacob has a BA in Geography and Economics, University of Victoria; and, Anastasia holds a PhD, Yale School of Forestry and Environmental Studies and an MSc in Environmental Management and Policy, Lund University.
Big Room’s Advisory Board members include: Ashok Khosla, President, IUCN; James Gustave Speth, former Dean, Yale School of Forestry and Environmental Studies; William Nitze, former Assistant Administrator International Activities, US Environmental Protection Agency; and, Bill Knight, founding Commissioner, Financial Consumer Agency of Canada.
ACCOUNTABILITY MECHANISMS TO THE COMMUNITY
Accountability is a core principle of the .ECO Community TLD as evidenced by the multi-stakeholder process undertaken (see 20c) to develop community-driven principles and policies and to establish an independent governance structure for Community oversight of .ECO.
The Accountability Policy that forms part of the .ECO Policy Consensus includes guidelines to ensure registrants comply with the .ECO purpose and principles, and that information provided in .ECO-profiles is trustworthy and accurate. The Registry will conduct ‘spot-checks’ by reviewing a percentage of .ECO-profiles to ensure compliance.
Under the Organization’s contract with Big Room, the parties have established mutual non-voting observer board seats and defined the specific roles and responsibilities with regard to managing the .ECO Community TLD according to the .ECO Policy Consensus.
Community members can participate directly in the governance of .ECO through the Organization. Membership is free and open to all members of the Community. Entity members may apply to become voting members after two years of membership.
Big Room is committed to open, transparent multi-stakeholder engagement. It reports annually on its own environmental, social and economic impacts and requires suppliers to adopt eco-practices.

20(c). Provide a description of the community-based purpose of the applied-for gTLD.

The .ECO Community TLD will create a global trusted source of environmental information, the .ECO System, to support the goals of the Global Environmental Community.
The December 2011 UNEP Eye on Earth Declaration vision whereby “decision-making for sustainable development is empowered by the availability and equitable accessibility of credible, relevant and timely information”, and that “effective mechanisms for the collection, management and dissemination of environmental information are needed.” The .ECO System also supports Principle 10 of the 1992 Rio Declaration on Environment and Development that states “Environmental issues are best handled with participation of all concerned citizens, at the relevant level.”
In the .ECO System, all registered .ECO domains will be linked to a separate web-based profile information system of .ECO-profiles that contain key environmental data in a user-friendly format. Together, .ECO domains and .ECO-profiles will form a new global aggregator of environmental information that includes controls and incentives to maintain the quality of information, while ensuring open access and freedom to innovate.
The purpose of the .ECO System per the .ECO Policy Consensus is to:
1. Allow members to more easily identify themselves and other Community members online and to prevent misuse of .ECO domain names that could lead to confusion;
2. Utilize the power of the Internet to foster transparency, information sharing, communication and exchange of ideas to promote environmental goals, interests and values, amongst community members and those who are exploring that opportunity; and,
3. Provide a platform for accurate and non-deceptive information and reliable resources to encourage environmental awareness and action.
INTENDED REGISTRANTS
Community members can become .ECO Registrants in the following categories: not-for-profit organizations, businesses, governments, individuals, and products. By completing their ECO-profile, Registrants can demonstrate their Community credentials (memberships, accreditations, certifications, and reporting). It will allow those wishing to join the Community to see the activities of current members, and facilitate interaction with eco-minded consumers.
INTENDED END-USERS
The intended end-user of the .ECO System is anyone interested in environmental data from the online trusted source created by millions of Community members. The .ECO System will provide accurate, reliable, and timely information about individuals, organizations, businesses and products to Community members, consumers, and others looking for environmental information. As a platform for innovation, members will foster transparency and consumer education by developing new ways to track, rank and display relevant information.
ACTIVITIES CARRIED OUT IN SERVICE OF THE .ECO PURPOSE
To establish the policies for .ECO, Meridian Institute (Meridian) mediated an international, transparent, and inclusive multi-stakeholder process, in compliance with the ISEAL Alliance Code of Good Practice for Setting Environmental and Social Standards, with members of the Global Environmental Community. Meridian is an independent, non-governmental, non-profit organization that is internationally recognized and trusted for designing and facilitating neutral consensus-building and problem-solving processes.
Global Multi-stakeholder Process
1. Creation of the .ECO Community Council (the Council)
At the request of Big Room, Meridian convened a council of community organizations, governed by a terms of reference (ToR) agreed by the members, to review and consider the results of a series of global consultations and to come to consensus on the purpose, principles, and policies for submission to ICANN on behalf of the Community. The ToR under which participants engaged confirmed that involvement was on a voluntary basis and without compensation or obligation to support Big Room’s application.
2. A Global Multi-Stakeholder Consultation with the Community
Big Room held 7 regional in-person consultations about the potential for .ECO to exist as a community TLD and to gather feedback on the purpose, principles and policies that should apply to the operation of a TLD purporting to be “pro environment.” Meetings were held in Canada, Australia, Sweden, Germany, Brazil, South Africa, the US from May to November 2009, on the margins of established international meetings⁄conferences where Community members were in attendance. The consultation process included public comment periods, town-hall meetings, open letters, bilateral communications, and global social and print media outreach.
3. An Extensive Public Campaign to Raise Awareness and Support
Working with the Council, Big Room posted at www.doteco.info drafts of all versions of the policies as they became available, and solicited Community input including 3 public comment periods from May 2009 to September 2010 of no less than 30 days each. In April 2010, the Council publicly announced its goal to develop a .ECO Policy Consensus by releasing an open letter to the Community by press release, posting to www.doteco.info, and delivery by Meridian to a number of community organizations.
Results of the Process
1. An agreement by the Council on the .ECO Policy Consensus, that defines the purpose, principles and policies for operation of the .ECO Community TLD.
2. The creation of an independent community-led organization, the Dot ECO Global Community Organization to act as the representative community member institution for .ECO and to provide on-going policy formulation, guidance, and advice to the Registry operator on behalf of the Community.
3. A contract between the Organization and Big Room defining their respective roles and procedures.
4. Support for the .ECO Community TLD application from over 50 environmental groups representing more than 10 million individual members and over 1,000 entities across 190 countries.
HOW THE PURPOSE AND PRINCIPLES ARE OF A LASTING NATURE
The over-arching purpose of the .ECO Community TLD is to support the goals, values and interests of the Global Environmental Community through increased transparency and awareness. The prevention of misuse of .ECO domain names that could lead to consumer confusion is a critical aspect of the .ECO mission. The Community’s goals are inherently of a lasting nature as it works, in the words of the Declaration of the 1972 UN Conference on the Human Environment “to defend and improve the human environment for present and future generations.” The importance of the consumer protection component of the Community’s work is recognized by many governments and organizations that have established standards for use of “green” or environmentally-friendly labelling.
Governance
The long-standing reliance on the multi-stakeholder model to pursue Community goals is reflected in the Dot ECO Global Community Organization. Its governance structure provides a community-led membership framework to manage .ECO for the long-term benefit of the Community including the opportunity to discuss and participate in the development and modification of .ECO policies and practices. The International Institute for Sustainable Development acts as secretariat for the Organization. On-going funding will be by the Registry. The Organization is linked to the Registry by a contract that defines the relationship between both parties and with ICANN.
Foundation
Per the .ECO Policy Consensus, a portion of sales from .ECO domain names will be donated to an independent foundation to support the Community’s goals, with a focus on building capacity in developing countries. The Organization and the Registry Operator will review the funding arrangement every 2 years, and publish annual financial reports to ensure transparency of funds allocated.

20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).

RELATIONSHIP TO THE ESTABLISHED NAME OF THE COMMUNITY AND TO THE IDENTIFICATION OF COMMUNTY MEMBERS
The term “eco” has long been used to identify members of the Global Environmental Community (the Community), as well as concepts, products and services associated with the Community’s goal of a respectful, responsible and sustainable use of the environment. The term appears in common usage and is clearly associated by consumers with environmentally responsible practices.
The Oxford English Dictionary (OED) offers the following examples:
Individuals and organizations (eg, eco-activist, eco-charities, eco-group)
Concepts (eg, eco-advocacy, eco-activism, eco-justice, eco-cultural, eco-historical, eco-literacy, eco-philosophy, eco-minded, eco-savvy, eco-awareness, eco-consciousness)
Products and services (eg, eco-product, eco-label, eco-house, eco-holiday, eco-resort, eco-bottle, eco-bulb, eco-forestry, eco-car)
(Oxford English Dictionary, 3rd edition, Mar. 2008; online version Sept. 2011)
Eco in Consumer Protection Public Policy
Consumer protection authorities around the world recognize the fact that the “eco” and “green” labels are powerful tools for consumer communication. Regulators agree that environment-related claims on products and services, including eco-, should only be used when qualifying information can be provided and⁄or the claim proven, including in the following policies: US Federal Trade Commission (FTC) Guides for the Use of Environmental Marketing Claims; UK Department for Environment Food and Rural Affairs (Defra) Green Claims Guidance & Advertising Standards Authority Codes; Environmental Claims: A Guide for Industry and Advertisers in Canada; Green Marketing & the Australian Consumer Law; and, European Union Guidelines for Making and Assessing Environmental Claims.
The UN Guidelines for Consumer Protection are also designed to safeguard against false environmental claims. The UN pro-consumer Guidelines are designed to protect consumers’ rights, especially those in developing countries, and to raise consumer awareness about the environmental impact of products and services “through such means as product profiles, environmental reports by industry, information centres for consumers, voluntary and transparent eco-labelling programmes and product information hotlines.”
Accordingly, the .ECO Community TLD will restrict .ECO domains to Community members and require registrants to complete and display a .ECO-profile. Without community restrictions and mandatory disclosures, a .ECO TLD could be construed as making environmental claims that would be impossible for consumers to verify.
Government-sponsored Research
Recent government-sponsored studies in the US and UK on consumer understanding clearly demonstrate that “eco,” “earth,” “environmentally-friendly” and to a lesser extent, “green” are commonly used and widely recognized by consumers to convey environmentally responsible practices.
Studies in the UK paid for by Defra show 70% of respondents were very familiar or fairly familiar with the term eco-friendly, being “explicitly linked to environmental issues, but only in as much as they show a product or claim broadly relates to the environment.” (DEFRA, “An Assessment of Green Claims in Marketing”, 2010; Consumer Understanding of Green Terms, 2011.)
Studies conducted as part of a 2010 review by the US Federal Trade Commission (FTC) Green Guides also noted a convergence of green, and eco- ⁄ earth- ⁄ environmentally-friendly as the most common general environmental terms. (FTC, “Green Marketing Internet Surf”, 2008). The studies also confirm the potential for misuse of such terms: “unqualified claims that an item is ‘environmentally friendly’ or ‘eco-friendly’ are likely to convey that it has specific and far-reaching environmental benefits.”
Independent Research
In February 2012, Vision Critical, on behalf of Big Room, conducted a survey to understand public perception around the term eco and of the .ECO TLD in general.
The majority of respondents (58%) indicated they would expect domain names ending in .ECO (eg, anyname.eco) to be members of an environmental organization, professional association or have made a specific commitment to the environment. Only 10% indicated they would not expect an environmental connection, while 32% said they did not know. Two-thirds (67%) of respondents also indicated that they would expect a website that had a domain name ending in .ECO to contain environmental⁄ecological related information. Half (51%) said they would be, and 25% said they might be confused by a .ECO TLD not associated with the Community.
The survey was a random online Omnibus survey of 1,016 US adults from diverse ages, incomes, ethnicities and regions, conducted 15-16 February 2012 among a sample of Americans who are also Springboard America panel members. The margin of error, which measures sampling variability, is +⁄-3.10%, 19 times out of 20. The sample was balanced by age, gender and region according to the most recent American Community Survey (2009).
Academic References
The OED defines the prefix eco- as a shortened form of ecology (noun) or ecological (adjective). When eco is used as stand-alone word, it is defined as shortened form of ecological (adjective), with the meaning environmentally friendly.
The OED lists over 30 words beginning with the prefix eco-, all of which relate to combined form adjectives with the sense “ecological and – –” or nouns with the sense “ecological –”. Throughout the over 70 years of documented use in the OED, eco has always been associated with ecology or ecological concepts, never as a shortened or combining form for words such as economy.
Support for a comparable use of “eco” in French is provided by Dr Pascaline Dury’s bilingual corpus-based study of the migration of vocabulary from scientific to non-scientific use. Of the 21 lexical units that appear in the study’s French news corpus, “all of them are semantically-related to the field of ecology and can be easily defined.” (Dury, P. “The rise of carbon neutral and compensation carbone”. Terminology 14(2): 236, 2008.)
POTENTIAL CONNOTATIONS BEYOND THE COMMUNITY
The OED identifies the potential for “greenwashing,” defined as “disinformation disseminated by an organisation, etc., so as to present an environmentally responsible public image; a public image of environmental responsibility promulgated by or for an organisation, etc., but perceived as being unfounded or intentionally misleading.” (BSR &Futerra, “Understanding and Preventing Greenwash: A Business Guide”, 2009.) Misuse of the “eco” label can negatively affect Community interests by making people skeptical of environmental initiatives and impeding consumers’ understanding of the impacts of their buying decisions.
While “eco” has no significant meaning other than as a short form for environment⁄ecology, it infrequently occurs as an acronym. Known international acronyms and uses are:
European Communications Office (ECO): All European Conference of Postal and Telecommunications Administrators (CEPT) divisions are housed as part of the CEPT website (www.cept.org⁄eco). There is no confusion anticipated between this usage and the .ECO TLD.
Economic Cooperation Organisation (ECO): an intergovernmental regional group established by Iran, Pakistan and Turkey to promote economic cooperation in the region (www.ecosecretariat.org). As the focus is regional rather than global and on economic rather than environmental issues, there is no confusion anticipated between this usage and the .ECO TLD.
eco Association of the German Internet Industry: Confirmed in writing that it does not intend to apply for .ECO or object to Big Room’s .ECO application. See attached letter of non-objection in 20f (20d-eco-non-objection.pdf). There is no confusion anticipated between this usage and the .ECO TLD.

20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.

The policies developed by the .ECO Community Council form the .ECO policy consensus, a key result of the process discussed in 20c. Policies are also discussed in 18b. The Dot ECO Global Community Organization (the Organization) provides for continued community discussion and participation to develop and modify .ECO policies and practices.
The registry will prevent DNS resolution of .ECO names until the registrant submits information to support their compliance with the .ECO community eligibility requirements. Registrants will be required to satisfactorily complete their .ECO-profile, the central eligibility verification system. Provided that this step is completed, active DNS resolution will be enabled.
The registry will employ standard registration lifecycle mechanisms, statuses, and states such as HOLD or LOCK functions, or other existing Extensible Provisioning Protocol (EPP) commands, in order to disallow a domain to be active when a registrant is not in compliance with the community eligibility requirements or under related community dispute resolution procedures.
ELIGIBILITY
Eligibility is limited to individuals and entities (not-for-profit, business and government) that are members of the Global Environmental Community (the Community) that meet community-recognized standards:
1. Not-for-profit environmental organizations that affirm and can provide proof on request of:
A) Accreditation by relevant UN agencies (ie, UNEP, UN Economic and Social Council) or
B) Proof of legal establishment and environmental mission⁄purpose.
2. Business entities that affirm and can provide proof on request of:
A) Membership in environmental organizations and initiatives including:
i. Organizations as in 1 A)-B) or
ii. The United Nations Global Compact or
iii. Other memberships approved by the Organization
B) Accreditation by voluntary environmental certifications, standards and reporting systems of:
i. Organizations as in 1 A)-B) or
ii. UN member states, national and sub-national governmental bodies and entities or
iii. The International Organization for Standardization or
iv. Other certification, standards and reporting systems approved by the Organization
3. Governments, including environment-related departments and initiatives of UN member states, national and sub-national governmental bodies, and UN bodies
4. Individuals that affirm and can provide proof on request of membership, financial support for, or accreditation including:
A) Organizations as in 1 A)-B) or
B) Certified environmental professional qualifications approved by the Organization or
C) Academics⁄scientists affiliated with recognized universities
Registrants holding certain environmental certifications may qualify to register for .ECO domain names without providing additional details through a .ECO-Profile. The Organization will establish the required qualifications and agreements with certifiers to enable rapid, accurate validation. Certified registrants will be promoted as such within the .ECO System.
NAME SELECTION
Community-priority: Prior to launch, the Organization will approve a list of community-priority names and with the Registry, develop a best-use plan competition. Allocated names will be donated to the winners for a defined term. All community-priority names will be reviewed biennially by the Registry against their use plans (eg, Forest, Finance).
Platform Names: Registry will reserve a list of names that may be useful to the .ECO System like industry sectors, environmental issues, nouns with environmental significance and other names deemed useful to the Registry’s implementation of .ECO (eg, Council, Community) for allocation in a manner to be determined by the Organization.
Auction-able: Registry will publish a list of remaining names available for auction during sunrise. Funds generated from these names will be used to support the Registry and Organization.
CONTENT⁄USE
Registrants must comply with the .ECO Purpose and Principles and provide accurate information in their .ECO-profiles.
Applicants must complete a .ECO-profile that includes a series of mandatory and voluntary questions about commitments, memberships, certification, reporting and other activities undertaken in support of Community goals.
Responses will form a .ECO-profile webpage that will be added to a public online database called the .ECO System. Registrant .ECO-profiles will be linked to the registrant’s .ECO domain via a .ECO logo trust-mark.
The Organization will develop a process to establish, regularly review, and update the .ECO-profile Registrant questions.
The types of .ECO use will be not-for-profit, business, individual, government, and product.
Controversial Names: Organization will develop a method to flag controversial strings based on: existing public policy, community recommendations; industry sector and green-washing watch-lists; and research⁄surveys. Controversial names will not be automatically blocked but registrants selecting flagged names will be notified that registration will be subject to additional scrutiny.
.ECO-profiles: Registry, in consultation with Organization, will develop a set of review guidelines to maximize .ECO System accuracy and to ensure compliance with the .ECO eligibility requirements. Registry will report annually on review process and results to the Organization.
To use a .ECO domain name a registrant must sign a Registrant Agreement that explains the actions they will need to take in support of the .ECO purpose and policies.
Registrants must review and⁄or update their .ECO-profiles at least annually. Non-compliant Registrants will be reminded by the Registry 30 and 10 days prior to the mandatory review date. Domain names with .ECO-profiles that remain non-compliant 12 months after the review date will be subject to takedown proceedings. This requirement further strengthens our rights protection and WHOIS accuracy mechanisms. See also Question 29.
Anywhere a registrant references .ECO (or Dot Eco) and⁄or the .ECO logo, the registrant’s corresponding Eco-profile URL must also be displayed (ie, as a footnote or hyperlink) as the .ECO logo must directly reference the registrant’s .ECO-profile.
Registrants must complete all mandatory .ECO-profile questions.
Registrants can indicate if the information in their .ECO-profile has been independently verified, and if so, include the verifier and validity⁄expiry dates.
ENFORCEMENT
Complaints: Every .ECO-profile will have a report abuse link where a complaint can be submitted about that registrant to the Registry. The Registry will evaluate complaints against the Registrant Agreement and decide whether and how to take action.
Where the registrant, Registry or Organization sees no clear resolution, the case may be referred to a dispute resolution process. The Registry, in keeping with the principles of improvement and inclusivity, will work with the registrant through the process to reach a mutually agreeable solution on behalf of the Community.
Where complaints are not addressed to the satisfaction of Registry and Organization, the registrant’s domain name may be suspended and⁄or taken down.
Complaints submitted by verified Community member registrants will be given priority over the general public. The Registry will review the number and nature of complaints about a registrant when considering suspension and take-down measures.
Dispute Resolution Process: Registry will support a Community Eligibility Dispute Resolution Process (CEDRP) aligned with the Accountability Policy described in the .ECO Policy Consensus. The CEDRP can be initiated by .ECO community member or the general public to address alleged violations of .ECO member policies or operating requirements by a registrant or registrar. Complaints will be first be addressed between the Registry, or a dispute resolution party contracted by the Registry, and the relevant Registrant. If not resolved to the satisfaction of the registrant, the registrant may pay a fee to seek the recommendation of an independent mediator or arbiter approved by the Registry. If not resolved to the satisfaction of the Registry, the Registry may choose to refer the dispute to the Organization for a final decision.
Comments on .ECO-profiles: .ECO-profiles are tools used to confirm Community membership and eligibility. Every .ECO-profile to have a public comment forum and the registrant whose .ECO domain name is associated with an .ECO-profile will have the right to moderate comments on their profile. Registrants may post comments about .ECO-profiles to relevant Platform Name pages. The Organization will establish and regularly review recommended moderation ⁄ commenting guidelines, including handling malicious comments.
Community Comment Forum: Registry will implement a .ECO community comment ⁄ debate forum for members to interact with each-other, the Registry and the Organization
Take-Down Process: For Registrants found to be in breach of the .ECO Registrant Agreement: receipt of a 60 day email notice to come into compliance and⁄or opt for dispute resolution, if no action, domain to be suspended for 60 days, if remains non-compliant, domain to be taken down by the Registry.
Transparency: Registry process for evaluating and resolving complaints and results of disputes will be made public. An Annual report of all complaints and actions taken will be made to the Organization.
Controversial Names: Registry mechanisms for community enforcement include: reporting controversial names, implementation of complaints, dispute resolution, takedown mechanisms per the Accountability Policy, and the right to take down names and sites that it or the Organization deem to be in breach of the .ECO Purpose and Registrant Agreement.

20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Not Available

Geographic Names


21(a). Is the application for a geographic name?

No

Protection of Geographic Names


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

Big Room Inc., the proposed .ECO registry operator, will protect names with national or geographic significance by reserving the country and territory names at the second level and at all other levels within the TLD, as per the requirements in the New TLD Registry Agreement (Specification 5, paragraph 5).

We will employ a series of rules to translate the geographical names required to be reserved by Specification 5, paragraph 5 to a form consistent with the ʺhost namesʺ format used in domain names.

Considering the Governmental Advisory Committee (GAC) advice “Principles regarding new gTLDs”, these domains will be blocked, at no cost to governments, public authorities, or Intergovernmental Organizations (IGOs), before the TLD is introduced (Sunrise), so that no parties may apply for them. We will publish a list of these names before Sunrise, so our registrars and their prospective applicants can be aware that these names are reserved.

We will define a procedure so that governments can request the above reserved domain(s) if they would like to take possession of them. This procedure will be based on existing methodology developed for the release of country names in the .INFO TLD, which is operated by Afilias, the registry services provider for the .ECO Community TLD. For example, we will require a written request from the country’s GAC representative, or a written request from the country’s relevant Ministry or Department. We will allow the designated beneficiary (the Registrant) to register the name, with an accredited .ECO Registrar, possibly using an authorization number transmitted directly to the designated beneficiary in the country concerned.

As defined by Specification 5, paragraph 5, such geographic domains may be released to the extent that Registry Operator reaches agreement with the applicable government(s). Registry operator will work with respective GAC representatives of the country’s relevant Ministry or Department to obtain their release of the names to the Registry Operator.

If internationalized domains names (IDNs) are introduced in the .ECO TLD in the future, we will also reserve the IDN versions of the country names in the relevant script(s) before IDNs become available to the public. If we find it advisable and practical, we will confer with relevant language authorities so that we can reserve the IDN domains properly along with their variants.

Regarding GAC advice regarding second-level domains not specified via Specification 5, paragraph 5, all domains awarded to registrants are subject to the Uniform Domain Name Dispute Resolution Policy (UDRP), and to any properly-situated court proceeding.

We will ensure appropriate procedures to allow governments, public authorities or IGOs to challenge abuses of names with national or geographic significance at the second level. In its registry-registrar agreement, and flowing down to registrar-registrant agreements, the registry operator will institute a provision to suspend domains names in the event of a dispute. We may exercise that right in the case of a dispute over a geographic name.

Registry Services


23. Provide name and full description of all the Registry Services to be provided.

Throughout the technical portion (#23 - #44) of this application, answers are provided directly from Afilias, the back-end provider of registry services for the .ECO Community TLD. Big Room chose Afilias as its back-end provider for .ECO because Afilias has more experience successfully applying to ICANN and launching new TLDs than any other provider. Afilias is the ICANN-contracted registry operator of the .INFO and .MOBI TLDs, and Afilias is the back-end registry services provider for other ICANN TLDs including .ORG, .ASIA, .AERO, and .XXX.

Registry services for the .ECO Community TLD will be performed by Afilias in the same responsible manner used to support 16 top level domains today. Afilias supports more ICANN-contracted TLDs (6) than any other provider currently. Afilias’ primary corporate mission is to deliver secure, stable and reliable registry services. The .ECO Community TLD will utilize an existing, proven team and platform for registry services with:

* A stable and secure, state-of-the-art, EPP-based SRS with ample storage capacity, data security provisions and scalability that is proven with registrars who account for over 95% of all gTLD domain name registration activity (over 375 registrars);
* A reliable, 100% available DNS service (zone file generation, publication and dissemination) tested to withstand severe DDoS attacks and dramatic growth in Internet use;
* A WHOIS service that is flexible and standards compliant, with search capabilities to address both registrar and end-user needs; includes consideration for evolving standards, such as RESTful, or draft-kucherawy-wierds;
* Experience introducing IDNs in the following languages: German (DE), Spanish (ES), Polish (PL), Swedish (SV), Danish (DA), Hungarian (HU), Icelandic (IS), Latvian (LV), Lithuanian (LT), Korean (KO), Simplified and Traditional Chinese (CN), Devanagari (HI-DEVA), Russian (RU), Belarusian (BE), Ukrainian (UK), Bosnian (BS), Serbian (SR), Macedonian (MK) and Bulgarian (BG) across the TLDs it serves;
* A registry platform that is both IPv6 and DNSSEC enabled;
* An experienced, respected team of professionals active in standards development of innovative services such as DNSSEC and IDN support;
* Methods to limit domain abuse, remove outdated and inaccurate data, and ensure the integrity of the SRS, and;
* Customer support and reporting capabilities to meet financial and administrative needs, e.g., 24x7 call center support, integration support, billing, and daily, weekly, and monthly reporting.

Afilias will support the .ECO Community TLD in accordance with the specific policies and procedures of Big Room (the “registry operator”), leveraging a proven registry infrastructure that is fully operational, staffed with professionals, massively provisioned, and immediately ready to launch and maintain the .ECO Community TLD.

The below response includes a description of the registry services to be provided for this TLD, additional services provided to support registry operations, and an overview of Afilias’ approach to registry management.

REGISTRY SERVICES TO BE PROVIDED

To support the .ECO Community TLD, Big Room and Afilias will offer the following registry services, all in accordance with relevant technical standards and policies:
* Receipt of data from registrars concerning registration for domain names and nameservers, and provision to registrars of status information relating to the EPP-based domain services for registration, queries, updates, transfers, renewals, and other domain management functions. Please see our responses to questions #24, #25, and #27 for full details, which we request be incorporated here by reference.
* Operation of the registry DNS servers: The Afilias DNS system, run and managed by Afilias, is a massively provisioned DNS infrastructure that utilizes among the most sophisticated DNS architecture, hardware, software and redundant design created. Afilias’ industry-leading system works in a seamless way to incorporate nameservers from any number of other secondary DNS service vendors. Please see our response to question #35 for full details, which we request be incorporated here by reference.
* Dissemination of TLD zone files: Afilias’ distinctive architecture allows for real-time updates and maximum stability for zone file generation, publication and dissemination. Please see our response to question #34 for full details, which we request be incorporated here by reference.
* Dissemination of contact or other information concerning domain registrations: A port 43 WHOIS service with basic and expanded search capabilities with requisite measures to prevent abuse. Please see our response to question #26 for full details, which we request be incorporated here by reference.
* Internationalized Domain Names (IDNs): Ability to support all protocol valid Unicode characters at every level of the TLD, including alphabetic, ideographic and right-to-left scripts, in conformance with the ICANN IDN Guidelines. Please see our response to question #44 for full details, which we request be incorporated here by reference.
* DNS Security Extensions (DNSSEC): A fully DNSSEC-enabled registry, with a stable and efficient means of signing and managing zones. This includes the ability to safeguard keys and manage keys completely. Please see our response to question #43 for full details, which we request be incorporated here by reference.

Each service will meet or exceed the contract service level agreement. All registry services for this TLD will be provided in a standards-compliant manner.

Security

Afilias addresses security in every significant aspect – physical, data and network as well as process. Afilias’ approach to security permeates every aspect of the registry services provided. A dedicated security function exists within the company to continually identify existing and potential threats, and to put in place comprehensive mitigation plans for each identified threat. In addition, a rapid security response plan exists to respond comprehensively to unknown or unidentified threats. The specific threats and Afilias mitigation plans are defined in our response to question #30(b); please see that response for complete information. In short, Afilias is committed to ensuring the confidentiality, integrity, and availability of all information.

NEW REGISTRY SERVICES

No new registry services are planned for the launch of the .ECO Community TLD.

ADDITIONAL SERVICES TO SUPPORT REGISTRY OPERATION

Numerous supporting services and functions facilitate effective management of the TLD. These support services are also supported by Afilias, including:
* Customer support: 24x7 live phone and e-mail support for customers to address any access, update or other issues they may encounter. This includes assisting the customer identification of the problem as well as solving it. Customers include registrars and the registry operator, but not registrants except in unusual circumstances. Customers have access to a web-based portal for a rapid and transparent view of the status of pending issues.
* Financial services: billing and account reconciliation for all registry services according to pricing established in respective agreements.

Reporting is an important component of supporting registry operations. Afilias will provide reporting to the registry operator and registrars, and financial reporting.

Reporting provided to registry operator

Afilias provides an extensive suite of reports to the registry operator, including daily, weekly and monthly reports with data at the transaction level that enable the registry operator to track and reconcile at whatever level of detail preferred. Afilias provides the exact data required by ICANN in the required format to enable the registry operator to meet its technical reporting requirements to ICANN.

In addition, Afilias offers access to a data warehouse capability that will enable near real-time data to be available 24x7. This can be arranged by informing the Afilias Account Manager regarding who should have access. Afilias’ data warehouse capability enables drill-down analytics all the way to the transaction level.

Reporting available to registrars

Afilias provides an extensive suite of reporting to registrars and has been doing so in an exemplary manner for more than ten years. Specifically, Afilias provides daily, weekly and monthly reports with detail at the transaction level to enable registrars to track and reconcile at whatever level of detail they prefer.

Reports are provided in standard formats, facilitating import for use by virtually any registrar analytical tool. Registrar reports are available for download via a secure administrative interface. A given registrar will only have access to its own reports. These include the following:
* Daily Reports: Transaction Report, Billable Transactions Report, and Transfer Reports;
* Weekly: Domain Status and Nameserver Report, Weekly Nameserver Report, Domains Hosted by Nameserver Weekly Report, and;
* Monthly: Billing Report and Monthly Expiring Domains Report.

Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be archived for a period of six months, after which they will be deleted.

Financial reporting

Registrar account balances are updated real-time when payments and withdrawals are posted to the registrarsʹ accounts. In addition, the registrar account balances are updated as and when they perform billable transactions at the registry level.

Afilias provides Deposit⁄Withdrawal Reports that are updated periodically to reflect payments received or credits and withdrawals posted to the registrar accounts.

The following reports are also available:

a) Daily Billable Transaction Report, containing details of all the billable transactions performed by all the registrars in the SRS,
b) daily e-mail reports containing the number of domains in the registry and a summary of the number and types of billable transactions performed by the registrars, and
c) registry operator versions of most registrar reports (for example, a daily Transfer Report that details all transfer activity between all of the registrars in the SRS).

AFILIAS APPROACH TO REGISTRY SUPPORT
Afilias, the back end registry services provider for this TLD, is dedicated to managing the technical operations and support of this TLD in a secure, stable and reliable manner. Afilias has worked closely with Big Room to review specific needs and objectives of this TLD. The resulting comprehensive plans are illustrated in technical responses #24-44, drafted by Afilias given Big Room’s requirements. Afilias and Big Room also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of the .ECO Community TLD.

Afilias is the registry services provider for this and several other TLD applications. Over the past 11 years of providing services for gTLD and ccTLDs, Afilias has accumulated experience about resourcing levels necessary to provide high quality services with conformance to strict service requirements. Afilias currently supports over 20 million domain names, spread across 16 TLDs, with over 400 accredited registrars.

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

With over a decade of registry experience, Afilias has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in Afilias’ participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows Afilias to be at the forefront of security initiatives such as: DNSSEC, wherein Afilias worked with Public Interest Registry (PIR) to make the .ORG registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.

The ability to observe tightening resources for critical functions and the capacity to add extra resources ahead of a threshold event are factors that Afilias is well versed in. Afilias’ human resources team, along with well-established relationships with external organizations, enables it to fill both long-term and short-term resource needs expediently.

Afilias’ growth from a few domains to serving 20 million domain names across 16 TLDs and 400 accredited registrars indicates that the relationship between the number of people required and the volume of domains supported is not linear. In other words, servicing 100 TLDs does not automatically require 6 times more staff than servicing 16 TLDs. Similarly, an increase in the number of domains under management does not require in a linear increase in resources. Afilias carefully tracks the relationship between resources deployed and domains to be serviced, and pro-actively reviews this metric in order to retain a safe margin of error. This enables Afilias to add, train and prepare new staff well in advance of the need, allowing consistent delivery of high quality services.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

NOTE: THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (LESS THAN ⁄ GREATER THAN CHARACTERS) (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE (24-SRS-Performance.pdf), ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.
====

Answers for this question (#24) are provided directly from Afilias, the back-end provider of registry services for the .ECO Community TLD.

Afilias operates a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS meets or exceeds all ICANN requirements given that Afilias:
* Operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
* Is committed to continuously enhancing our SRS to meet existing and future needs;
* Currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
* Provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of the .ECO Community TLD, and;
* Manages the SRS with a team of experienced technical professionals who can seamlessly integrate this TLD into the Afilias registry platform and support the .ECO Community TLD in a secure, stable and reliable manner.

DESCRIPTION OF OPERATION OF THE SRS, INCLUDING DIAGRAMS

Afilias’ SRS provides the same advanced functionality as that used in the .INFO and .ORG registries, as well as the fourteen other TLDs currently supported by Afilias. The Afilias registry system is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by our massively provisioned infrastructure that mitigates the risk of disaster.

EPP functionality is described fully in our response to question #25; please consider those answers incorporated here by reference. An abbreviated list of Afilias SRS functionality includes:
* Domain registration: Afilias provides registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
* Domain renewal: Afilias provides services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry performs the automated renewal of all domain names at the expiration of their term, and allows registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund.
* Transfer: Afilias provides efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry enables bulk transfers of domains under the provisions of the Registry-Registrar Agreement.
* RGP and restoring deleted domain registrations: Afilias provides support for the Redemption Grace Period (RGP) as needed, enabling the restoration of deleted registrations.
* Other grace periods and conformance with ICANN guidelines: Afilias provides support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the Afilias registry system supports the evolving ICANN guidelines on IDNs.

Afilias also supports the basic check, delete, and modify commands.

As required for all new gTLDs, Afilias provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.

Afilias’ SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this TLD’s respective domain policies. With over a decade of experience, Afilias has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.

SRS servers and software

All applications and databases for this TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (It is possible that by the time this application is evaluated and systems deployed, Westmere processors may no longer be the “latest”; the Afilias policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources, thus reducing energy consumption and carbon footprint.

The network firewalls, routers and switches support all applications and servers. Hardware traffic shapers are used to enforce an equitable access policy for connections coming from registrars. The registry system accommodates both IPv4 and IPv6 addresses. Hardware load balancers accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.

Each of the servers and network devices are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all our data centers guarantee replacement of failed parts in the shortest time possible.

Examples of current system and network devices used are:
* Servers: Cisco UCS B230 blade servers
* SAN storage arrays: IBM Storwize V7000 with Solid State Drives
* SAN switches: Brocade 5100
* Firewalls: Cisco ASA 5585-X
* Load balancers: F5 Big-IP 6900
* Traffic shapers: Procera PacketLogic PL8720
* Routers: Juniper MX40 3D
* Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.

Technical components of the SRS include the following items, continually checked and upgraded as needed: SRS, WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).

All hardware is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device is continuously monitored by the Afilias Network Operations Center for performance and availability. The data gathered is used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review is instituted which will address the need for additions well in advance of their actual need.

SRS DIAGRAM AND INTERCONNECTIVITY DESCRIPTION

As with all core registry services, the SRS is run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see our responses to questions #32 and #35. Registrars access the SRS in real-time using EPP.

A sample of the Afilias SRS technical and operational capabilities (displayed in Figure 24-a) include:
* Geographically diverse redundant registry systems;
* Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
* Disaster Recovery Point objective for the registry is within one minute of the loss of the primary system;
* Detailed and tested contingency plan, in case of primary site failure, and;
* Daily reports, with secure access for confidentiality protection.

As evidenced in Figure 24-a, the SRS contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.

The WHOIS servers are directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.

Committed DNS-related EPP objects in the database are made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor extracts committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.

The Afilias system is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.

This interconnectivity is monitored, as is the entire registry system, according to the plans detailed in our response to question #42.

SYNCHRONIZATION SCHEME

Registry databases are synchronized both within the same data center and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) works continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction the Slony replication system ensures that each replica also processes the transaction. When there are no transactions to process, Slony “sleeps” until a transaction arrives or for one minute, whichever comes first. Slony “wakes up” each minute to confirm with the publisher that there has not been a transaction and thus ensures subscribers are synchronized and the replication time lag is minimized. The typical replication time lag between the publisher and subscribers depends on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.

SRS SERVICE LEVEL AGREEMENT (SLA) PERFORMANCE COMPLIANCE

Afilias has a ten-year record of delivering on the demanding ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Figure 24-b.

The Afilias SRS currently handles over 200 million EPP transactions per month for just .INFO and .ORG. Overall, the Afilias SRS manages over 700 million EPP transactions per month for all TLDs under management.

Given this robust functionality, and more than a decade of experience supporting a thick TLD registry with a strong performance history, Afilias, on behalf of Big Room, will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The Afilias services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The Afilias architecture is also massively provisioned to meet seasonal demands and marketing campaigns. Afilias’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.

SRS RESOURCING PLANS

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of the .ECO TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Over 100 Afilias team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate Afilias facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, Afilias also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy this TLD on the Afilias infrastructure, and maintain it. Together, the Afilias team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for the .ECO Community TLD.

25. Extensible Provisioning Protocol (EPP)

NOTE: THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (LESS THAN ⁄ GREATER THAN CHARACTERS) (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE (25-EPP-response.pdf), ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.
====

Answers for this question (#25) are provided by Afilias, the back-end provider of registry services for the .ECO Community TLD.

Afilias has been a pioneer and innovator in the use of EPP. .INFO was the first EPP-based gTLD registry and launched on EPP version 02⁄00. Afilias has a track record of supporting TLDs on standards-compliant versions of EPP. Afilias will operate the EPP registrar interface as well as a web-based interface for this TLD in accordance with RFCs and global best practices. In addition, Afilias will maintain a proper OT&E (Operational Testing and Evaluation) environment to facilitate registrar system development and testing.

Afilias’ EPP technical performance meets or exceeds all ICANN requirements as demonstrated by:
* A completely functional, state-of-the-art, EPP-based SRS that currently meets the needs of various gTLDs and will meet this new TLD’s needs;
* A track record of success in developing extensions to meet client and registrar business requirements such as multi-script support for IDNs;
* Supporting six ICANN gTLDs on EPP: .INFO, .ORG, .MOBI, .AERO, .ASIA and .XXX
* EPP software that is operating today and has been fully tested to be standards-compliant;
* Proven interoperability of existing EPP software with ICANN-accredited registrars, and;
* An SRS that currently processes over 200 million EPP transactions per month for both .INFO and .ORG. Overall, Afilias processes over 700 million EPP transactions per month for all 16 TLDs under management.

The EPP service is offered in accordance with the performance specifications defined in the new gTLD Registry Agreement, Specification 10.

EPP STANDARDS

The Afilias registry system complies with the following revised versions of the RFCs and operates multiple ICANN TLDs on these standards, including .INFO, .ORG, .MOBI, .ASIA and .XXX. The systems have been tested by our Quality Assurance (“QA”) team for RFC compliance, and have been used by registrars for an extended period of time:
* 3735 - Guidelines for Extending EPP
* 3915 - Domain Registry Grace Period Mapping
* 5730 - Extensible Provisioning Protocol (EPP)
* 5731 - Domain Name Mapping
* 5732 - Host Mapping
* 5733 - Contact Mapping
* 5734 - Transport Over TCP
* 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

This TLD will support all valid EPP commands. The following EPP commands are in operation today and will be made available for this TLD. See attachment #25a for the base set of EPP commands and copies of Afilias XSD schema files, which define all the rules of valid, RFC compliant EPP commands and responses that Afilias supports. Any customized EPP extensions, if necessary, will also conform to relevant RFCs.

Afilias staff members actively participated in the Internet Engineering Task Force (IETF) process that finalized the new standards for EPP. Afilias will continue to actively participate in the IETF and will stay abreast of any updates to the EPP standards.

EPP SOFTWARE INTERFACE AND FUNCTIONALITY

Afilias will provide all registrars with a free open-source EPP toolkit. Afilias provides this software for use with both Microsoft Windows and Unix⁄Linux operating systems. This software, which includes all relevant templates and schema defined in the RFCs, is available on sourceforge.net and will be available through the registry operator’s website.

Afilias’ SRS EPP software complies with all relevant RFCs and includes the following functionality:
* EPP Greeting: A response to a successful connection returns a greeting to the client. Information exchanged can include: name of server, server date and time in UTC, server features, e.g., protocol versions supported, languages for the text response supported, and one or more elements which identify the objects that the server is capable of managing;
* Session management controls: 〈login〉 to establish a connection with a server, and 〈logout〉 to end a session;
* EPP Objects: Domain, Host and Contact for respective mapping functions;
* EPP Object Query Commands: Info, Check, and Transfer (query) commands to retrieve object information, and;
* EPP Object Transform Commands: five commands to transform objects: 〈create〉 to create an instance of an object, 〈delete〉 to remove an instance of an object, 〈renew〉 to extend the validity period of an object, 〈update〉 to change information associated with an object, and 〈transfer〉 to manage changes in client sponsorship of a known object.

Currently, 100% of the top domain name registrars in the world have software that has already been tested and certified to be compatible with the Afilias SRS registry. In total, over 375 registrars, representing over 95% of all registration volume worldwide, operate software that has been certified compatible with the Afilias SRS registry. Afilias’ EPP Registrar Acceptance Criteria are available in attachment #25b, EPP OT&E Criteria.

Free EPP software support

Afilias analyzes and diagnoses registrar EPP activity log files as needed and is available to assist registrars who may require technical guidance regarding how to fix repetitive errors or exceptions caused by misconfigured client software.

Registrars are responsible for acquiring a TLS⁄SSL certificate from an approved certificate authority, as the registry-registrar communication channel requires mutual authentication; Afilias will acquire and maintain the server-side TLS⁄SSL certificate. The registrar is responsible for developing support for TLS⁄SSL in their client application. Afilias will provide free guidance for registrars unfamiliar with this requirement.

REGISTRAR DATA SYNCHRONIZATION

There are two methods available for registrars to synchronize their data with the registry:
* Automated synchronization: Registrars can, at any time, use the EPP 〈info〉 command to obtain definitive data from the registry for a known object, including domains, hosts (nameservers) and contacts.
* Personalized synchronization: A registrar may contact technical support and request a data file containing all domains (and associated host (nameserver) and contact information) registered by that registrar, within a specified time interval. The data will be formatted as a comma separated values (CSV) file and made available for download using a secure server.

EPP MODIFICATIONS

There are no unique EPP modifications planned for the .ECO Community TLD.

All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. These extensions are:
* An 〈ipr:name〉 element that indicates the name of Registered Mark.
* An 〈ipr:number〉 element that indicates the registration number of the IPR.
* An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
* An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
* An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for.
* An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered.
* An 〈ipr:class〉 element that indicates the class of the registered mark.
* An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for.

Note that some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse.

EPP RESOURCING PLANS

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

108 Afilias team members directly contribute to the management and development of the EPP based registry systems. As previously noted, Afilias is an active member of IETF and has a long documented history developing and enhancing EPP. These contributors include 11 developers and 14 QA engineers focused on maintaining and enhancing EPP server side software. These engineers work directly with business staff to timely address existing needs and forecast registry⁄registrar needs to ensure the Afilias EPP software is effective today and into the future. A team of eight data analysts work with the EPP software system to ensure that the data flowing through EPP is securely and reliably stored in replicated database systems. In addition to the EPP developers, QA engineers, and data analysts, other EPP contributors at Afilias include: Technical Analysts, the Network Operations Center and Data Services team members.

26. Whois

Answers for this question (#26) are provided by Afilias, the back-end provider of registry services for the .ECO Community TLD.

Afilias operates the WHOIS (registration data directory service) infrastructure in accordance with RFCs and global best practices, as it does for the 16 TLDs it currently supports. Designed to be robust and scalable, Afilias’ WHOIS service has exceeded all contractual requirements for over a decade. It has extended search capabilities, and methods of limiting abuse.

The WHOIS service operated by Afilias meets and exceeds ICANN’s requirements. Specifically, Afilias will:
* Offer a WHOIS service made available on port 43 that is flexible and standards-compliant;
* Comply with all ICANN policies, and meeting or exceeding WHOIS performance requirements in Specification 10 of the new gTLD Registry Agreement;
* Enable a Searchable WHOIS with extensive search capabilities that offers ease of use while enforcing measures to mitigate access abuse, and;
* Employ a team with significant experience managing a compliant WHOIS service.

Such extensive knowledge and experience managing a WHOIS service enables Afilias to offer a comprehensive plan for the .ECO Community TLD that meets the needs of constituents of the domain name industry and Internet users. The service has been tested by our QA team for RFC compliance, and has been used by registrars and many other parties for an extended period of time. Afilias’ WHOIS service currently serves almost 500 million WHOIS queries per month, with the capacity already built in to handle an order of magnitude increase in WHOIS queries, and the ability to smoothly scale should greater growth be needed.

Big Room, as the .ECO registry operator, commits to abiding by all local privacy laws and requirements with respect to the WHOIS service for the .ECO Community TLD.

WHOIS SYSTEM DESCRIPTION AND DIAGRAM

The Afilias WHOIS system, depicted in figure 26-a, is designed with robustness, availability, compliance, and performance in mind. Additionally, the system has provisions for detecting abusive usage (e.g., excessive numbers of queries from one source). The WHOIS system is generally intended as a publicly available single object lookup system. Afilias uses an advanced, persistent caching system to ensure extremely fast query response times.

Afilias will develop restricted WHOIS functions based on specific domain policy and regulatory requirements as needed for operating the business (as long as they are standards compliant). It will also be possible for contact and registrant information to be returned according to regulatory requirements. The WHOIS database supports multiple string and field searching through a reliable, free, secure web-based interface.

Data objects, interfaces, access and lookups

Registrars can provide an input form on their public websites through which a visitor is able to perform WHOIS queries. The registry operator can also provide a Web-based search on its site. The input form must accept the string to query, along with the necessary input elements to select the object type and interpretation controls. This input form sends its data to the Afilias port 43 WHOIS server. The results from the WHOIS query are returned by the server and displayed in the visitor’s Web browser. The sole purpose of the Web interface is to provide a user-friendly interface for WHOIS queries.

Afilias will provide WHOIS output as per Specification 4 of the new gTLD Registry Agreement. The output for domain records generally consists of the following elements:
* The name of the domain registered and the sponsoring registrar;
* The names of the primary and secondary nameserver(s) for the registered domain name;
* The creation date, registration status and expiration date of the registration;
* The name, postal address, e-mail address, and telephone and fax numbers of the domain name holder;
* The name, postal address, e-mail address, and telephone and fax numbers of the technical contact for the domain name holder;
* The name, postal address, e-mail address, and telephone and fax numbers of the administrative contact for the domain name holder, and;
* The name, postal address, e-mail address, and telephone and fax numbers of the billing contact for the domain name holder.
The following additional features are also present in Afilias’ WHOIS service:
* Support for IDNs, including the language tag and the Punycode representation of the IDN in addition to Unicode Hex and Unicode HTML formats;
* Enhanced support for privacy protection relative to the display of confidential information.

Afilias will also provide sophisticated WHOIS search functionality that includes the ability to conduct multiple string and field searches.

Query controls

For all WHOIS queries, a user is required to enter the character string representing the information for which they want to search. The object type and interpretation control parameters to limit the search may also be specified. If object type or interpretation control parameter is not specified, WHOIS will search for the character string in the Name field of the Domain object.

WHOIS queries are required to be either an ʺexact searchʺ or a ʺpartial search,ʺ both of which are insensitive to the case of the input string.

An exact search specifies the full string to search for in the database field. An exact match between the input string and the field value is required.

A partial search specifies the start of the string to search for in the database field. Every record with a search field that starts with the input string is considered a match. By default, if multiple matches are found for a query, then a summary containing up to 50 matching results is presented. A second query is required to retrieve the specific details of one of the matching records.

If only a single match is found, then full details will be provided. Full detail consists of the data in the matching object as well as the data in any associated objects. For example: a query that results in a domain object includes the data from the associated host and contact objects.

WHOIS query controls fall into two categories: those that specify the type of field, and those that modify the interpretation of the input or determine the level of output to provide. Each is described below.

The following keywords restrict a search to a specific object type:
* Domain: Searches only domain objects. The input string is searched in the Name field.
* Host: Searches only nameserver objects. The input string is searched in the Name field and the IP Address field.
* Contact: Searches only contact objects. The input string is searched in the ID field.
* Registrar: Searches only registrar objects. The input string is searched in the Name field.
By default, if no object type control is specified, then the Name field of the Domain object is searched.

In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names. Deployment of these features is provided as an option to the registry operator, based upon registry policy and business decision making.

Figure 26-b presents the keywords that modify the interpretation of the input or determine the level of output to provide.

By default, if no interpretation control keywords are used, the output will include full details if a single match is found and a summary if multiple matches are found.

Unique TLD requirements

There are no unique WHOIS requirements for the .ECO Community TLD.

Sunrise WHOIS processes

All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. The following corresponding data will be displayed in WHOIS for relevant domains:
* Trademark Name: element that indicates the name of the Registered Mark.
* Trademark Number: element that indicates the registration number of the IPR.
* Trademark Locality: element that indicates the origin for which the IPR is established (a national or international trademark registry).
* Trademark Entitlement: element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
* Trademark Application Date: element that indicates the date the Registered Mark was applied for.
* Trademark Registration Date: element that indicates the date the Registered Mark was issued and registered.
* Trademark Class: element that indicates the class of the Registered Mark.
* IPR Type: element that indicates the Sunrise phase the application applies for.

IT AND INFRASTRUCTURE RESOURCES

All the applications and databases for the .ECO Community TLD will run in a virtual environment hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors (or a more advanced, stable technology available at the time of deployment). The registry data will be stored on storage arrays of solid-state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources thus reducing energy consumption and carbon footprint.

The applications and servers are supported by network firewalls, routers and switches.
The WHOIS system accommodates both IPv4 and IPv6 addresses.

Each of the servers and network devices are equipped with redundant hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with our hardware vendor with a 4-hour response time at all our data centers guarantees replacement of failed parts in the shortest time possible.

Models of system and network devices used are:
* Servers: Cisco UCS B230 blade servers
* SAN storage arrays: IBM Storwize V7000 with Solid State Drives
* Firewalls: Cisco ASA 5585-X
* Load balancers: F5 Big-IP 6900
* Traffic shapers: Procera PacketLogic PL8720
* Routers: Juniper MX40 3D
* Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

There will be at least four virtual machines (VMs) offering WHOIS service. Each VM will run at least two WHOIS server instances - one for registrars and one for the public. All instances of the WHOIS service is made available to registrars and the public are rate limited to mitigate abusive behavior.

FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS

Registration data records from the EPP publisher database will be replicated to the WHOIS system database on a near-real-time basis whenever an update occurs.

SPECIFICATIONS 4 AND 10 COMPLIANCE

The WHOIS service for this TLD will meet or exceed the performance requirements in the new gTLD Registry Agreement, Specification 10. Figure 26-c provides the exact measurements and commitments. Afilias has a 10 year track record of exceeding WHOIS performance and a skilled team to ensure this continues for all TLDs under management.

The WHOIS service for the .ECO Community TLD will meet or exceed the requirements in the new gTLD Registry Agreement, Specification 4.

RFC 3912 COMPLIANCE

Afilias will operate the WHOIS infrastructure in compliance with RFCs and global best practices, as it does with the 16 TLDs Afilias currently supports.

Afilias maintains a registry-level centralized WHOIS database that contains information for every registered domain and for all host and contact objects. The WHOIS service will be available on the Internet standard WHOIS port (port 43) in compliance with RFC 3912. The WHOIS service contains data submitted by registrars during the registration process. Changes made to the data by a registrant are submitted to Afilias by the registrar and are reflected in the WHOIS database and service in near-real-time, by the instance running at the primary data center, and in under ten seconds by the instance running at the secondary data center, thus providing all interested parties with up-to-date information for every domain. This service is compliant with the new gTLD Registry Agreement, Specification 4.

The WHOIS service maintained by Afilias will be authoritative and complete, as this will be a “thick” registry (detailed domain contact WHOIS is all held at the registry); users do not have to query different registrars for WHOIS information, as there is one central WHOIS system. Additionally, visibility of different types of data is configurable to meet the registry operator’s needs.

SEARCHABLE WHOIS

Afilias offers a searchable WHOIS on a web-based Directory Service. Partial match capabilities are offered on the following fields: domain name, registrar ID, and IP address. In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names.

Providing the ability to search important and high-value fields such as registrant name, address and contact names increases the probability of abusive behavior. An abusive user could script a set of queries to the WHOIS service and access contact data in order to create or sell a list of names and addresses of registrants in this TLD. Making the WHOIS machine readable, while preventing harvesting and mining of WHOIS data, is a key requirement integrated into the Afilias WHOIS systems. For instance, Afilias limits search returns to 50 records at a time. If bulk queries were ever necessary (e.g., to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process), Afilias makes such query responses available to carefully screened and limited staff members at the registry operator (and customer support staff) via an internal data warehouse. The Afilias WHOIS system accommodates anonymous access as well as pre-identified and profile-defined uses, with full audit and log capabilities.

The WHOIS service has the ability to tag query responses with labels such as “Do not redistribute” or “Special access granted”. This may allow for tiered response and reply scenarios. Further, the WHOIS service is configurable in parameters and fields returned, which allow for flexibility in compliance with various jurisdictions, regulations or laws.

Afilias offers exact-match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). Search capabilities are fully available, and results include domain names matching the search criteria (including IDN variants). Afilias manages abuse prevention through rate limiting and CAPTCHA (described below). Queries do not require specialized transformations of internationalized domain names or internationalized data fields

Please see “Query Controls” above for details about search options and capabilities.

DETERRING WHOIS ABUSE

Afilias has adopted two best practices to prevent abuse of the WHOIS service: rate limiting and CAPTCHA.

Abuse of WHOIS services on port 43 and via the Web is subject to an automated rate-limiting system. This ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system.

Abuse of web-based public WHOIS services is subject to the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) technology. The use of CAPTCHA ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system. The registry operator will adopt a CAPTCHA on its Web-based WHOIS.

Data mining of any sort on the WHOIS system is strictly prohibited, and this prohibition is published in WHOIS output and in terms of service.

For rate limiting on IPv4, there are configurable limits per IP and subnet. For IPv6, the traditional limitations do not apply. Whenever a unique IPv6 IP address exceeds the limit of WHOIS queries per minute, the same rate-limit for the given 64 bits of network prefix that the offending IPv6 IP address falls into will be applied. At the same time, a timer will start and rate-limit validation logic will identify if there are any other IPv6 address within the original 80-bit(⁄48) prefix. If another offending IPv6 address does fall into the ⁄48 prefix then rate-limit validation logic will penalize any other IPv6 addresses that fall into that given 80-bit (⁄48) network. As a security precaution, Afilias will not disclose these limits.

Pre-identified and profile-driven role access allows greater granularity and configurability in both access to the WHOIS service, and in volume⁄frequency of responses returned for queries.

Afilias staff are key participants in the ICANN Security & Stability Advisory Committee’s deliberations and outputs on WHOIS, including SAC003, SAC027, SAC033, SAC037, SAC040, and SAC051. Afilias staff are active participants in both technical and policy decision making in ICANN, aimed at restricting abusive behavior.

WHOIS STAFF RESOURCING PLANS

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of the .ECO Community TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Within Afilias, there are 11 staff members who develop and maintain the compliant WHOIS systems. They keep pace with access requirements, thwart abuse, and continually develop software. Of these resources, approximately two staffers are typically required for WHOIS-related code customization. Other resources provide quality assurance, and operations personnel maintain the WHOIS system itself. This team will be responsible for the implementation and on-going maintenance of the new TLD WHOIS service.

27. Registration Life Cycle

NOTE: THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (LESS THAN ⁄ GREATER THAN CHARACTERS) (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE (27-Registration-Lifecycle-response.pdf), ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.
====

Answers for this question (#27) are provided by Afilias, the back-end provider of registry services for the .ECO Community TLD.

Afilias has been managing registrations for over a decade. Afilias has had experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, all standard grace periods, and can address any modifications required with the introduction of any new ICANN policies.

This TLD will follow the ICANN standard domain lifecycle, as is currently implemented in TLDs such as .ORG and .INFO. The below response includes: a diagram and description of the lifecycle of a domain name in this TLD, including domain creation, transfer protocols, grace period implementation and the respective time frames for each; and the existing resources to support the complete lifecycle of a domain.

As depicted in Figure 27-a, prior to the beginning of the Trademark Claims Service or Sunrise IP protection program[s], Afilias will support the reservation of names in accordance with the new gTLD Registry Agreement, Specification 5.

REGISTRATION PERIOD

After the IP protection programs and the general launch, eligible registrants may choose an accredited registrar to register a domain name. The registrar will check availability on the requested domain name and if available, will collect specific objects such as, the required contact and host information from the registrant. The registrar will then provision the information into the registry system using standard Extensible Provisioning Protocol (“EPP”) commands through a secure connection to the registry backend service provider.

When the domain is created, the standard five day Add Grace Period begins, the domain and contact information are available in WHOIS, and normal operating EPP domain statuses will apply. Other specifics regarding registration rules for an active domain include:
* The domain must be unique;
* Restricted or reserved domains cannot be registered;
* The domain can be registered from 1-10 years;
* The domain can be renewed at any time for 1-10 years, but cannot exceed 10 years;
* The domain can be explicitly deleted at any time;
* The domain can be transferred from one registrar to another except during the first 60 days following a successful registration or within 60 days following a transfer; and,
Contacts and hosts can be modified at any time.

The following describe the domain status values recognized in WHOIS when using the EPP protocol following RFC 5731.
* OK or Active: This is the normal status for a domain that has no pending operations or restrictions.
* Inactive: The domain has no delegated name servers.
* Locked: No action can be taken on the domain. The domain cannot be renewed, transferred, updated, or deleted. No objects such as contacts or hosts can be associated to, or disassociated from the domain. This status includes: Delete Prohibited ⁄ Server Delete Prohibited, Update Prohibited ⁄ Server Update Prohibited, Transfer Prohibited, Server Transfer Prohibited, Renew Prohibited, Server Renew Prohibited.
* Hold: The domain will not be included in the zone. This status includes: Client Hold, Server Hold.
* Transfer Prohibited: The domain cannot be transferred away from the sponsoring registrar. This status includes: Client Transfer Prohibited, Server Transfer Prohibited.

The following describe the registration operations that apply to the domain name during the registration period.
a. Domain modifications: This operation allows for modifications or updates to the domain attributes to include:
i. Registrant Contact
ii. Admin Contact
iii. Technical Contact
iv. Billing Contact
v. Host or nameservers
vi. Authorization information
vii. Associated status values
A domain with the EPP status of Client Update Prohibited or Server Update Prohibited may not be modified until the status is removed.
b. Domain renewals: This operation extends the registration period of a domain by changing the expiration date. The following rules apply:
i. A domain can be renewed at any time during its registration term,
ii. The registration term cannot exceed a total of 10 years.
A domain with the EPP status of Client Renew Prohibited or Server Renew Prohibited cannot be renewed.
c. Domain deletions: This operation deletes the domain from the Shared Registry Services (SRS). The following rules apply:
i. A domain can be deleted at any time during its registration term, f the domain is deleted during the Add Grace Period or the Renew⁄Extend Grace Period, the sponsoring registrar will receive a credit,
ii. A domain cannot be deleted if it has “child” nameservers that are associated to other domains.
A domain with the EPP status of Client Delete Prohibited or Server Delete Prohibited cannot be deleted.
d. Domain transfers: A transfer of the domain from one registrar to another is conducted by following the steps below.
i. The registrant must obtain the applicable 〈authInfo〉 code from the sponsoring (losing) registrar.
* Every domain name has an authInfo code as per EPP RFC 5731. The authInfo code is a six- to 16-character code assigned by the registrar at the time the name was created. Its purpose is to aid identification of the domain owner so proper authority can be established (it is the ʺpasswordʺ to the domain).
* Under the Registry-Registrar Agreement, registrars will be required to provide a copy of the authInfo code to the domain registrant upon his or her request.
ii. The registrant must provide the authInfo code to the new (gaining) registrar, who will then initiate a domain transfer request. A transfer cannot be initiated without the authInfo code.
* Every EPP 〈transfer〉 command must contain the authInfo code or the request will fail. The authInfo code represents authority to the registry to initiate a transfer.
iii. Upon receipt of a valid transfer request, the registry automatically asks the sponsoring (losing) registrar to approve the request within five calendar days.
* When a registry receives a transfer request the domain cannot be modified, renewed or deleted until the request has been processed. This status must not be combined with either Client Transfer Prohibited or Server Transfer Prohibited status.
* If the sponsoring (losing) registrar rejects the transfer within five days, the transfer request is cancelled. A new domain transfer request will be required to reinitiate the process.
* If the sponsoring (losing) registrar does not approve or reject the transfer within five days, the registry automatically approves the request.
iv. After a successful transfer, it is strongly recommended that registrars change the authInfo code, so that the prior registrar or registrant cannot use it anymore.
v. Registrars must retain all transaction identifiers and codes associated with successful domain object transfers and protect them from disclosure.
vi. Once a domain is successfully transferred the status of TRANSFERPERIOD is added to the domain for a period of five days.
vii. Successful transfers will result in a one year term extension (resulting in a maximum total of 10 years), which will be charged to the gaining registrar.
e. Bulk transfer: Afilias, supports bulk transfer functionality within the SRS for situations where ICANN may request the registry to perform a transfer of some or all registered objects (includes domain, contact and host objects) from one registrar to another registrar. Once a bulk transfer has been executed, expiry dates for all domain objects remain the same, and all relevant states of each object type are preserved. In some cases the gaining and the losing registrar as well as the registry must approved bulk transfers. A detailed log is captured for each bulk transfer process and is archived for audit purposes.
Big Room will support ICANN’s Transfer Dispute Resolution Process. Big Room will work with Afilias to respond to Requests for Enforcement (law enforcement or court orders) and will follow that process.

1. Auto-renew grace period
The Auto-Renew Grace Period displays as AUTORENEWPERIOD in WHOIS. An auto-renew must be requested by the registrant through the sponsoring registrar and occurs if a domain name registration is not explicitly renewed or deleted by the expiration date and is set to a maximum of 45 calendar days. In this circumstance the registration will be automatically renewed by the registry system the first day after the expiration date. If a Delete, Extend, or Transfer occurs within the AUTORENEWPERIOD the following rules apply:
i. Delete. If a domain is deleted the sponsoring registrar at the time of the deletion receives a credit for the auto-renew fee. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.
ii. Renew⁄Extend. A domain can be renewed as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed.
iii. Transfer (other than ICANN-approved bulk transfer). If a domain is transferred, the losing registrar is credited for the auto-renew fee, and the year added by the operation is cancelled. As a result of the transfer, the expiration date of the domain is extended by minimum of one year as long as the total term does not exceed 10 years. The gaining registrar is charged for the additional transfer year(s) even in cases where a full year is not added because of the maximum 10 year registration restriction.

2. Redemption grace period
During this period, a domain name is placed in the PENDING DELETE RESTORABLE status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A domain can remain in this state for up to 30 days and will not be included in the zone file. The only action a registrar can take on a domain is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. If the domain is restored it moves into PENDING RESTORE and then OK. After 30 days if the domain is not restored it moves into PENDING DELETE SCHEDULED FOR RELEASE before the domain is released back into the pool of available domains.

3. Pending delete
During this period, a domain name is placed in PENDING DELETE SCHEDULED FOR RELEASE status for five days, and all Internet services associated with the domain will remain disabled and domain cannot be restored. After five days the domain is released back into the pool of available domains.

OTHER GRACE PERIODS

All ICANN required grace periods will be implemented in the registry backend service provider’s system including the Add Grace Period (AGP), Renew⁄Extend Grace Period (EGP), Transfer Grace Period (TGP), Auto-Renew Grace Period (ARGP), and Redemption Grace Period (RGP). The lengths of grace periods are configurable in the registry system. At this time, the grace periods will be implemented following other gTLDs such as .ORG. More than one of these grace periods may be in effect at any one time. The following are accompanying grace periods to the registration lifecycle.

ADD GRACE PERIOD

The Add Grace Period displays as ADDPERIOD in WHOIS and is set to five calendar days following the initial registration of a domain. If the domain is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration. If a Delete, Renew⁄Extend, or Transfer operation occurs within the five calendar days, the following rules apply.
i. Delete. If a domain is deleted within this period the sponsoring registrar at the time of the deletion is credited for the amount of the registration. The domain is deleted from the registry backend service provider’s database and is released back into the pool of available domains.
ii. Renew⁄Extend. If the domain is renewed within this period and then deleted, the sponsoring registrar will receive a credit for both the registration and the extended amounts. The account of the sponsoring registrar at the time of the renewal will be charged for the initial registration plus the number of years the registration is extended. The expiration date of the domain registration is extended by that number of years as long as the total term does not exceed 10 years.
iii. Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the ADDPERIOD or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the registrar sponsoring the domain name registration and is enforced by the SRS.

RENEW ⁄ EXTEND GRACE PERIOD

The Renew ⁄ Extend Grace Period displays as RENEWPERIOD in WHOIS and is set to five calendar days following an explicit renewal on the domain by the registrar. If a Delete, Extend, or Transfer occurs within the five calendar days, the following rules apply:
i. Delete. If a domain is deleted within this period the sponsoring registrar at the time of the deletion receives a credit for the renewal fee. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.
ii. Renew⁄Extend. A domain registration can be renewed within this period as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed.
iii. Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew⁄Extend Grace Period, there is no credit to the losing registrar for the renewal fee. As a result of the transfer, the expiration date of the domain registration is extended by a minimum of one year as long as the total term for the domain does not exceed 10 years.
If a domain is auto-renewed, then extended, and then deleted within the Renew⁄Extend Grace Period, the registrar will be credited for any auto-renew fee charged and the number of years for the extension. The years that were added to the domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.

TRANSFER GRACE PERIOD

The Transfer Grace period displays as TRANSFERPERIOD in WHOIS and is set to five calendar days after the successful transfer of domain name registration from one registrar to another registrar. Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the TRANSFERPERIOD or within the first 60 days after the transfer. If a Delete or Renew⁄Extend occurs within that five calendar days, the following rules apply:
i. Delete. If the domain is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.
ii. Renew⁄Extend. If a domain registration is renewed within the Transfer Grace Period, there is no credit for the transfer. The registrarʹs account will be charged for the number of years the registration is renewed. The expiration date of the domain registration is extended by the renewal years as long as the total term does not exceed 10 years.

SPECIAL CONSIDERATIONS

NONE. COMMUNITY ELIGIBILITY IMPLEMENTATION DOES NOT AFFECT REGISTRATION LIFECYCLE.

Consistent with the requirements of the community-based designation for the .ECO domain, the registry will maintain community eligibility requirements as described in responses #18, #20.

The registry will employ standard registration lifecycle mechanisms, statuses, and states such as HOLD or LOCK functions, or other existing Extensible Provisioning Protocol (EPP) commands, in order to disallow a domain to be active when a registrant is not in compliance with the community eligibility requirements or under related community dispute resolution procedures.

The community-designated .ECO TLD will maintain a domain challenge process, as outlined in response #18(b) and #20(e). The Registry will support a Community Eligibility Dispute Resolution Process (CEDRP) aligned with the Accountability Policy described in the .ECO Policy Consensus. This process will use standard registration lifecycle elements and not require any new capabilities.

The .ECO Community TLD will conduct an auction for certain domain names. Afilias will manage the domain name auction using existing technology. Upon the completion of the auction, any domain name acquired will then follow the standard lifecycle of a domain.


REGISTRATION LIFECYCLE RESOURCES

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way. Virtually all Afilias resource are involved in the registration lifecycle of domains.

There are a few areas where registry staff devote resources to registration lifecycle issues:
a. Supporting Registrar Transfer Disputes. The registry operator will have a compliance staffer handle these disputes as they arise; they are very rare in the existing gTLDs.
b. Afilias has its development and quality assurance departments on hand to modify the grace period functionality as needed, if ICANN issues new Consensus Policies or the RFCs change.

Afilias has more than 30 staff members in these departments.

28. Abuse Prevention and Mitigation

Big Room, the .ECO Registry Operator, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the .ECO Community TLD. The specific measures include, but are not limited to:
* Posting a .ECO Community TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
* Committing to rapid identification and resolution of abuse, including suspensions;
* Ensuring completeness of WHOIS information at the time of registration;
* Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;
* Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.

ABUSE POLICY

The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the .ECO Community TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

Repeat violations of the abuse policy will result in a case-by-case review of the abuser(s), and the registry operator reserves the right to escalate the issue, with the intent of levying sanctions that are allowed under the TLD anti-abuse policy.

The below policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool.

.ECO Anti-Abuse Policy

The following Anti-Abuse Policy is effective upon launch of the .ECO Community TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:
* Illegal or fraudulent actions;
* Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums;
* Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
* Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
* Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses.
* Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.
* Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
* Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to the registry operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).

ABUSE POINT OF CONTACT AND PROCEDURES FOR HANDLING ABUSE COMPLAINTS

The registry operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.ECO”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. For tracking purposes, the registry operator will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. Afilias will integrate its existing ticketing system with the registry operator’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

The .ECO registry operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate.

In general, the registry operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

The security function includes a communication and outreach function, with information sharing with industry partners regarding malicious or abusive behavior, in order to ensure coordinated abuse mitigation across multiple TLDs.

Assessing abuse reports requires great care, and the registry operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, the registry operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:
a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.
b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.

The standard procedure is that the registry operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that the registry operator will not, such as:
* Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
* The identity of a proxy-protected registrant;
* The purchaser’s IP address;
* Whether there is a reseller involved, and;
* The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).

Registrars do not share the above information with registry operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by the registry operator (usually 24 hours), the registry operator might then decide to take action itself. At all times, the registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

The registry operator will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where the registry operator will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which the registry operator, although the operator in all cases will adhere to applicable laws and regulations.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:
* Registration information
* History of a domain, including recent updates made
* Other domains associated with a registrant’s account
* Patterns of registrant portfolio

Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. Afilias sets a goal to respond to such requests within 24 hours.

The registry operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The registry operator could take advantage of a combination of the following resources, among others:
* Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus.
* Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.
* Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.]

The registry operator will keep records and track metrics regarding abuse and abuse reports. These will include:
* Number of abuse reports received by the registry’s abuse point of contact described above;
* Number of cases and domains referred to registrars for resolution;
* Number of cases and domains where the registry took direct action;
* Resolution times;
* Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;
* Phishing site uptimes in the TLD.

REMOVAL OF ORPHAN GLUE RECORDS

By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. These procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The registry operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.

METHODS TO PROMOTE WHOIS ACCURACY

The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in our response to question #26, WHOIS, the registry operator will manage a secure, robust and searchable WHOIS service for the .ECO TLD.

WHOIS data accuracy

The registry operator will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. The registry operator will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list. The Afilias WHOIS system is extensible, and is capable of using the VAULT system, described further below.

Similar to the centralized abuse point of contact described above, the registry operator can institute a contact email address which could be utilized by third parties to submit complaints for inaccurate or false WHOIS data detected. This information will be processed by Afilias’ support department and forwarded to the registrars. The registrars can work with the registrants of those domains to address these complaints. Afilias will audit registrars on a yearly basis to verify whether the complaints being forwarded are being addressed or not. This functionality, available to all registry operators, is activated based on the registry operator’s business policy.

Afilias also incorporates a spot-check verification system where a randomly selected set of domain names are checked periodically for accuracy of WHOIS data. Afilias’ .PRO registry system incorporates such a verification system whereby 1% of total registrations or 100 domains, whichever number is larger, are spot-checked every month to verify the domain name registrant’s critical information provided with the domain registration data. With both a highly qualified corps of engineers and a 24x7 staffed support function, Afilias has the capacity to integrate such spot-check functionality into the .ECO TLD, based on the registry operator’s business policy. Note: This functionality will not work for proxy protected WHOIS information, where registrars or their resellers have the actual registrant data. The solution to that problem lies with either registry or registrar policy, or a change in the general marketplace practices with respect to proxy registrations. The .ECO registry does not intend to support proxy registrations.

Finally, Afilias’ registry systems have a sophisticated set of billing and pricing functionality which aids registry operators who decide to provide a set of financial incentives to registrars for maintaining or improving WHOIS accuracy. For instance, it is conceivable that the registry operator may decide to provide a discount for the domain registration or renewal fees for validated registrants, or levy a larger cost for the domain registration or renewal of proxy domain names. The .ECO registry does not intend to support proxy registrations. The Afilias system has the capability to support such incentives on a configurable basis, towards the goal of promoting better WHOIS accuracy.

Role of registrars

As part of the RRA (Registry Registrar Agreement), the registry operator will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄ ).

CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS

Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to question #30b.

.ECO COMMUNITY ELIGIBILITY AND ABUSE PREVENTION AND MITIGATION

Before DNS resolution is permitted for their domain, .ECO registrants must demonstrate a commitment to the .ECO purpose, principles and policies by agreeing to the registrant agreement, which includes a commitment to the .ECO mission and purpose, affirmation of membership in the environmental community, and answering the mandatory .ECO-profile questions.

Registrants must complete a .ECO-profile that includes a series of mandatory and voluntary questions about commitments, memberships, certification, reporting and other activities undertaken in support of the Community’s goals. Responses will form a .ECO-profile web page that will be added to a public online database called the .ECO System. Registrant .ECO-profiles will be linked to the Registrant’s .ECO domain via a .ECO logo trust mark, like those in common use (eg, TRUSTe online privacy seal and VeriSign Trust Seal).

The registry will employ standard registration lifecycle mechanisms, statuses, and states such as HOLD or LOCK functions, or other existing Extensible Provisioning Protocol (EPP) commands, in order to disallow a domain to be active when a registrant is not in compliance with the community eligibility requirements or under related community dispute resolution procedures.

Accountability and abuse prevention: The Registry will layer community forums, online complaint and abuse reporting, dispute resolution, mediation, and arbitration as required to ensure policies are enforced in a transparent and accountable way. The Registry will engage the Dot ECO Global Community Organization on matters requiring broader policy decisions.

Beyond the baseline eligibility requirements, abuse prevention and mitigation measures will include:

* Spot checks: reviewing a percent of .ECO-profiles to ensure compliance.
* Risk based audits: reviewing .ECO-profile disclosures (eligibility disclosures) for industries, sectors, or registrant types which are identified as having higher risk of abuse
* Verified .ECO-profiles: verified .ECO-profiles will be offered for a fee (via an internal or outsourced service), akin to the ‘Twitter Verified’ program, to increase accuracy and further reduce abuse. (See Twitter: FAQ about Verified Accounts: http:⁄⁄goo.gl⁄WHA7y).
* Community member flagging ⁄ comment: If the user believes that a domain is inconsistent with the mission and purpose of the .ECO Community TLD, s⁄he may ‘flag’ the domain for review, using the ‘flag for review’ functionality on the .ECO-profile page. Such ‘flagged’ domains will be queued for review and assessed as appropriate.

These layers are explained in an Accountability Policy of the .ECO Policy Consensus.

Dispute Resolution Mechanisms: Registrants and rights holders will have access to fair and transparent processes to adjudicate claims to domains that also protect registrants against reverse domain hijacking. Names registered in the Sunrise Period will be subject to a Sunrise Dispute Policy. This policy and procedure will be in effect for a finite time period, to provide special protection of qualified trademark rights. See response to #29 (“Rights Protection Mechanisms”).

.ECO domains will be subject to the Uniform Dispute Resolution Policy (UDRP). See response to #29 (“Rights Protection Mechanisms”).

.ECO domains will also be subject to the Universal Rapid Suspension (URS) policy. See the URS specifications in Applicant Guidebook Module and response #29 (“Rights Protection Mechanisms”) for full details. The Registry will provide systems to take in and administrate cases as per ICANN’s Registrar Transfer Dispute Resolutions Policy, allowing registrars to protect registrants by filing disputes about inter-registrar transfers that they believe were unauthorized or improperly executed.

The Registry will support a Community Eligibility Dispute Resolution Process (CEDRP) aligned with the Accountability Policy described in the .ECO Policy Consensus. This dispute process can be initiated by either a member of the .ECO community or a member of the general public to address an alleged violation of the .ECO member policies or operating requirements by a registrant or registrar.

Please see responses #18(b), #20(e) for a description of community eligibility and registration requirements for the .ECO Community TLD.

VALIDATION AND ABUSE MITIGATION MECHANISMS

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation. Once analyzed and confirmed by the domain anti-abuse team members, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable the registry operator to only allow registrations by pre-authorized and verified contacts. These verified contacts are given a unique code that can be used for registration of new domains.

REGISTRANT PRE-VERIFICATION AND AUTHENTICATION

One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

* Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.
* Based on required WHOIS Data; registrant contact details (name, address, phone)
* If address⁄ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)
* If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions.
* If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant.
* If WHOIS data is validated a token would be generated and could be given back to the registrar which registered the domain.
* WHOIS data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.
* A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers.
* Validation would be annually renewed, and validation date displayed in the WHOIS.

ABUSE PREVENTION RESOURCING PLANS

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way. Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. While all of Afilias’ 200+ employees are charged with responsibility to report any detected abuse, the engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

The .ECO TLD’s anticipated volume of registrations in the first three years of operations is listed in response #46. Afilias and the registry operator’s anti-abuse function anticipates the expected volume and type of registrations, and together will adequately cover the staffing needs for this TLD. The registry operator will maintain an abuse response team, which may be a combination of internal staff and outside specialty contractors, adjusting to the needs of the size and type of TLD. The team structure planned for this TLD is based on several years of experience responding to, mitigating, and managing abuse for TLDs of various sizes. The team will generally consist of abuse handlers (probably internal), a junior analyst, (either internal or external), and a senior security consultant (likely an external resource providing the registry operator with extra expertise as needed). These responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

The exact resources required to maintain an abuse response team must change with the size and registration procedures of the TLD. An initial abuse handler is necessary as a point of contact for reports, even if a part-time responsibility. The abuse handlers monitor the abuse email address for complaints and evaluate incoming reports from a variety of sources. A large percentage of abuse reports to the registry operator may be unsolicited commercial email. The designated abuse handlers can identify legitimate reports and then decide what action is appropriate, either to act upon them, escalate to a security analyst for closer investigation, or refer them to registrars as per the above-described procedures. A TLD with rare cases of abuse would conform to this structure.

If multiple cases of abuse within the same week occur regularly, the registry operator will consider staffing internally a security analyst to investigate the complaints as they become more frequent. Training an abuse analyst requires 3-6 months and likely requires the active guidance of an experienced senior security analyst for guidance and verification of assessments and recommendations being made.

If this TLD were to regularly experience multiple cases of abuse within the same day, a full-time senior security analyst would likely be necessary. A senior security analyst capable of fulfilling this role should have several years of experience and able to manage and train the internal abuse response team.

The abuse response team will also maintain subscriptions for several security information services, including the blocklists from organizations like SURBL and Spamhaus and anti-phishing and other domain related abuse (malware, fast-flux etc.) feeds. The pricing structure of these services may depend on the size of the domain and some services will include a number of rapid suspension requests for use as needed.

For a large TLD, regular audits of the registry data are required to maintain control over abusive registrations. When a registrar with a significant number of registrations has been compromised or acted maliciously, the registry operator may need to analyze a set of registration or DNS query data. A scan of all the domains of a registrar is conducted only as needed. Scanning and analysis for a large registrar may require as much as a week of full-time effort for a dedicated machine and team.

Big Room will maintain sufficient staff resources to implement identified abuse mitigation and prevention measures, respond to issues as they arise, and coordinate tier 1 and escalated abuse issues with Afilias. As necessary additional support will be outsourced or contracted in line with registry growth. Please see response #47 for a description of the Community and Policy Director, Customer Service Coordinator, Verification Coordinator, and Customer Support Assistant who are planned for years 1-3 of startup in support of these functions.

29. Rights Protection Mechanisms

Rights protection is a core responsibility of the TLD operator, and is supported by a fully-developed plan for rights protection that includes:
* Establishing mechanisms to prevent unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies);
* Implementing a robust Sunrise program, utilizing the Trademark Clearinghouse, the services of one of ICANN’s approved dispute resolution providers, a trademark validation agent, and drawing upon sunrise policies and rules used successfully in previous gTLD launches;
* Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
* Complying with the URS requirements;
* Complying with the UDRP;
* Complying with the PDDRP, and;
* Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.

The response below details the rights protection mechanisms at the launch of the TLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, PDDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans.

Safeguards for rights protection at the launch of the TLD

The launch of this TLD will include the operation of a trademark claims service according to the defined ICANN processes for checking a registration request and alerting trademark holders of potential rights infringement.

Sunrise period

The Registry will provide a fair opportunity for environmental community members to register for .ECO while also minimizing related costs to rights holders.

The Sunrise Period will last a minimum period of 1 month, prior to the opening of public registration, when trademark and service mark holders will be able to reserve marks that are an identical match in the .ECO domain. Following the Sunrise Period, Big Room will open registration to qualified applicants.

The first phase will run for a limited time period prior to the Land-rush and General Availability phases. In the past, Sunrise periods have been used in the launch of numerous TLDs including .INFO, .BIZ, .MOBI, .TEL, .ME, .XXX and others. These efforts have proven the need for a balanced approach that provides intellectual property (IP) holders, as well as an opportunity to register names they feel apply to their IP.

Big Room will hold a Sunrise period where holders of internationally recognized filed trademarks or possibly holders of existing (legacy) gTLD strings that are a perfect match to the .ECO string that they are applying for, will have the opportunity to apply for registration. A qualified third party must verify each trademark and⁄or legacy gTLD. In addition, the applicant must have a completed .ECO-profile and meet all criteria in order to be accepted as a community member. No application will be accepted without these verifications.

Big Room plans to use the Trademark Clearinghouse to asynchronously check Sunrise applications against registered trademarks. If the trademark is verified and valid, we expect to be able to inform the IP holder that a Sunrise application for their string has been submitted. IP holders are only involved if an application is submitted that is an exact match to their registered trademark.

An auction process will determine the awarding party in the event that there is more than one valid Sunrise application for a given string.

Community-priority & Platform names

Related to the sunrise phase is handling of specific types of names aimed at serving the community, including:

1. Premium Names, including those that could have added community value, in two categories:

A) Community-priority: Prior to launch, the Organization will approve a list of community-priority names. The Registry will, with Organization input, develop rules for a best-use plan competition. Names allocated in the competition will be donated to the winners. All community-priority names will be reviewed biennially by the Registry against their use-plans.

B) Auction-able: The Registry will also publish a list of names available for auction during sunrise. Funds generated from these names will be used to support the Registry.

2. Platform Names: The Registry will reserve a list of names that may be useful to the .ECO System, such as: industry sectors (eg, transportation); environmental issues (e.g. biodiversity); nouns with environmental significance (eg, water); and, other names deemed technically useful to the Registry’s implementation of .ECO as a community TLD (eg, Council).

Sunrise Period Requirements & Restrictions

Those wishing to reserve their marks in the .ECO domain during the Sunrise Period must own a current trademark or service mark listed in the Trademark Clearinghouse or submit evidence of a Trademark of national effect during the application process. Acceptable criteria for submitted Trademarks are modeled directly from the Trademark Clearinghouse guidelines:

“Nationally or regionally registered word marks from all jurisdictions.

- Any word mark that has been validated through a court of law or other judicial proceeding.
- Any word mark protected by a statute or treaty in effect at the time the mark is submitted to the Clearinghouse for inclusion.
- Other marks that constitute intellectual property.
- Protections afforded to trademark registrations do not extend to applications for registrations, marks within any opposition period or registered marks that were the subject of successful invalidation, cancellation or rectification proceedings.”

Notice will be provided to all trademark holders in the Clearinghouse if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an Identical Match (as defined in the Trademark Clearing House) to the name to be registered during Sunrise.

Each Sunrise registration will require a minimum term of five years.

Big Room will establish the following Sunrise eligibility requirements (SERs) as minimum requirements, verified by Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP). The SERs include: (i) ownership of a mark that satisfies the criteria set forth in section 7.2 of the Trademark Clearing House specifications, (ii) description of international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

The SDRP will allow challenges based on the following four grounds: (i) at time the challenged domain name was registered, the registrants did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

Ongoing rights protection mechanisms

Several mechanisms will be in place to protect rights in this TLD. As described in our responses to questions #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and an experienced team is available to respond to legal actions by law enforcement or court orders.

This TLD will conform to all ICANN RPMs including URS (defined below), UDRP, PDDRP, and all measures defined in Specification 7 of the new TLD agreement.

Uniform Rapid Suspension (URS)

The registry operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site as of this writing, the registry operator will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the registry operator’s support staff, which is on duty 24x7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.

As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the registry operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
* ServerUpdateProhibited, with an EPP reason code of “URS”
* ServerDeleteProhibited, with an EPP reason code of “URS”
* ServerTransferProhibited, with an EPP reason code of “URS”
* The registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email.

The registry operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.

The registry operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.

As per the URS guidelines, if the complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”

Community TLD considerations

Unqualified registrations (registrations in violation of the registry’s eligibility restrictions or policies)

Before DNS resolution is permitted for their domain, .ECO registrants must demonstrate a commitment to the .ECO purpose, principles and policies by agreeing to the registrant agreement, which includes a commitment to the .ECO mission and purpose, affirmation of membership in the environmental community, and answering the mandatory .ECO-profile questions.

Registrants must complete a .ECO-profile that includes a series of mandatory and voluntary questions about commitments, memberships, certification, reporting and other activities undertaken in support of the Community’s goals. Responses will form a .ECO-profile web page that will be added to a public online database called the .ECO System. Registrant .ECO-profiles will be linked to the Registrant’s .ECO domain via a .ECO logo trust mark, like those in common use (eg, TRUSTe online privacy seal and VeriSign Trust Seal).

The registry will employ standard registration lifecycle mechanisms, statuses, and states such as HOLD or LOCK functions, or other existing Extensible Provisioning Protocol (EPP) commands, in order to disallow a domain to be active when a registrant is not in compliance with the community eligibility requirements or under related community dispute resolution procedures.

Accountability and abuse prevention: The Registry will layer community forums, online complaint and abuse reporting, dispute resolution, mediation, and arbitration as required to ensure policies are enforced in a transparent and accountable way. The Registry will engage the Dot Eco Global Community Organization on matters requiring broader policy decisions.

Beyond the baseline eligibility requirements, abuse prevention and mitigation measures will include:

* Spot checks: reviewing a percent of .ECO-profiles to ensure compliance.
* Risk based audits: reviewing .ECO-profile disclosures (eligibility disclosures) for industries, sectors, or registrant types which are identified as having higher risk of abuse
* Verified .ECO-profiles: verified .ECO-profiles will be offered for a fee (via an internal or outsourced service), akin to the ‘Twitter Verified’ program, to increase accuracy and further reduce abuse. (See Twitter: FAQ about Verified Accounts: http:⁄⁄goo.gl⁄WHA7y).
* Community member flagging ⁄ comment: If the user believes that a domain is inconsistent with the mission and purpose of the .ECO Community TLD, s⁄he may ‘flag’ the domain for review, using the ‘flag for review’ functionality on the .ECO-profile page. Such ‘flagged’ domains will be queued for review and assessed as appropriate.

Rights protection or other disputes

Dispute Resolution Mechanisms: Registrants and rights holders will have access to fair and transparent processes to adjudicate claims to domains that also protect registrants against reverse domain hijacking. Names registered in the Sunrise Period will be subject to a Sunrise Dispute Policy. This policy and procedure will be in effect for a finite time period, to provide special protection of qualified trademark rights. See response to #29 (“Rights Protection Mechanisms”).

.ECO domains will be subject to the Uniform Dispute Resolution Policy (UDRP).

.ECO domains will also be subject to the Universal Rapid Suspension (URS) policy. See the URS specifications in Applicant Guidebook Module and response #29 (“Rights Protection Mechanisms”) for full details. The Registry will provide systems to take in and administrate cases as per ICANN’s Registrar Transfer Dispute Resolutions Policy, allowing registrars to protect registrants by filing disputes about inter-registrar transfers that they believe were unauthorized or improperly executed.

The Registry will support a Community Eligibility Dispute Resolution Process (CEDRP) aligned with the Accountability Policy described in the .ECO Policy Consensus. This dispute process can be initiated by either a member of the .ECO community or a member of the general public to address an alleged violation of the .ECO member policies or operating requirements by a registrant or registrar.

Please see responses #18(b), #20(e) for a description of community eligibility and registration requirements for the .ECO Community TLD, and response #28 for a review of abuse prevention and mitigation.

Rights protection via the RRA

The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant Agreements:

* The registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:
a. to enforce registry policies and ICANN requirements; each as amended from time to time;
b. that is not accompanied by complete and accurate information as required by ICANN requirements and⁄or registry policies or where required information is not updated and⁄or corrected as required by ICANN requirements and⁄or registry policies;
c. to protect the integrity and stability of the registry, its operations, and the TLD system;
d. to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
e. to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
f. to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
g. as otherwise provided in the Registry-Registrar Agreement and⁄or the Registrar-Registrant Agreement.

Reducing opportunities for behaviors such as phishing or pharming

In our response to question #28, the registry operator has described its anti-abuse program. Rather than repeating the policies and procedures here, please see our response to question #28 for full details.

In the case of this TLD, Big Room will apply an approach that addresses registered domain names (rather than potentially registered domains). This approach will not infringe upon the rights of eligible registrants to register domains, and allows Big Room internal controls, as well as community-developed UDRP and URS policies and procedures if needed, to deal with complaints, should there be any.

Afilias is a member of various security fora which provide access to lists of names in each TLD which may be used for malicious purposes. Such identified names will be subject to the TLD anti-abuse policy, including rapid suspensions after due process.

Rights protection resourcing plans

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Supporting RPMs requires several departments within the registry operator as well as within Afilias. The implementation of Sunrise and the Trademark Claims service and on-going RPM activities will pull from the 102 Afilias staff members of the engineering, product management, development, security and policy teams at Afilias and the support staff of the registry operator, which is on duty 24x7. A trademark validator will also be assigned within the registry operator, whose responsibilities may require as much as 50% of full-time employment if the domains under management were to exceed several million. No additional hardware or software resources are required to support this as Afilias has fully-operational capabilities to manage abuse today.

Big Room will maintain sufficient staff resources to implement identified abuse mitigation and prevention measures, rights protection mechanisms, and respond to issues as they arise. As necessary additional support will be outsourced or contracted in line with registry growth. Please see response #47 for a description of the Community and Policy Director, Customer Service Coordinator, Verification Coordinator, and Customer Support Assistant who are planned for years 1-3 of startup in support of these functions.

30(a). Security Policy: Summary of the security policy for the proposed registry

The answer to question #30a is provided by Afilias, the back-end provider of registry services for the .ECO Community TLD.

Afilias aggressively and actively protects the registry system from known threats and vulnerabilities, and has deployed an extensive set of security protocols, policies and procedures to thwart compromise. Afilias’ robust and detailed plans are continually updated and tested to ensure new threats are mitigated prior to becoming issues. Afilias will continue these rigorous security measures, which include:
* Multiple layers of security and access controls throughout registry and support systems;
* 24x7 monitoring of all registry and DNS systems, support systems and facilities;
* Unique, proven registry design that ensures data integrity by granting only authorized access to the registry system, all while meeting performance requirements;
* Detailed incident and problem management processes for rapid review, communications, and problem resolution, and;
* Yearly external audits by independent, industry-leading firms, as well as twice-yearly internal audits.

SECURITY POLICIES AND PROTOCOLS

Afilias has included security in every element of its service, including facilities, hardware, equipment, connectivity⁄Internet services, systems, computer systems, organizational security, outage prevention, monitoring, disaster mitigation, and escrow⁄insurance, from the original design, through development, and finally as part of production deployment. Examples of threats and the confidential and proprietary mitigation procedures are detailed in our response to question #30(b).

There are several important aspects of the security policies and procedures to note:
* Afilias hosts domains in data centers around the world that meet or exceed global best practices.
* Afilias’ DNS infrastructure is massively provisioned as part of its DDoS mitigation strategy, thus ensuring sufficient capacity and redundancy to support new gTLDs.
* Diversity is an integral part of all of our software and hardware stability and robustness plan, thus avoiding any single points of failure in our infrastructure.
* Access to any element of our service (applications, infrastructure and data) is only provided on an as-needed basis to employees and a limited set of others to fulfill their job functions. The principle of least privilege is applied.
* All registry components – critical and non-critical – are monitored 24x7 by staff at our NOCs, and the technical staff has detailed plans and procedures that have stood the test of time for addressing even the smallest anomaly. Well-documented incident management procedures are in place to quickly involve the on-call technical and management staff members to address any issues.

Afilias follows the guidelines from the ISO 27001 Information Security Standard (Reference: http:⁄⁄www.iso.org⁄iso⁄iso_catalogue⁄catalogue_tc⁄catalogue_detail.htm?csnumber=42103 ) for the management and implementation of its Information Security Management System. Afilias also utilizes the COBIT IT governance framework to facilitate policy development and enable controls for appropriate management of risk (Reference: http:⁄⁄www.isaca.org⁄cobit). Best practices defined in ISO 27002 are followed for defining the security controls within the organization. Afilias continually looks to improve the efficiency and effectiveness of our processes, and follows industry best practices as defined by the IT Infrastructure Library, or ITIL (Reference: http:⁄⁄www.itil-officialsite.com⁄).

The Afilias registry system is located within secure data centers that implement a multitude of security measures both to minimize any potential points of vulnerability and to limit any damage should there be a breach. The characteristics of these data centers are described fully in our response to question #30(b).

The Afilias registry system employs a number of multi-layered measures to prevent unauthorized access to its network and internal systems. Before reaching the registry network, all traffic is required to pass through a firewall system. Packets passing to and from the Internet are inspected, and unauthorized or unexpected attempts to connect to the registry servers are both logged and denied. Management processes are in place to ensure each request is tracked and documented, and regular firewall audits are performed to ensure proper operation. 24x7 monitoring is in place and, if potential malicious activity is detected, appropriate personnel are notified immediately.

Afilias employs a set of security procedures to ensure maximum security on each of its servers, including disabling all unnecessary services and processes and regular application of security-related patches to the operating system and critical system applications. Regular external vulnerability scans are performed to verify that only services intended to be available are accessible.

Regular detailed audits of the server configuration are performed to verify that the configurations comply with current best security practices. Passwords and other access means are changed on a regular schedule and are revoked whenever a staff member’s employment is terminated.

Access to registry system

Access to all production systems and software is strictly limited to authorized operations staff members. Access to technical support and network operations teams where necessary are read only and limited only to components required to help troubleshoot customer issues and perform routine checks. Strict change control procedures are in place and are followed each time a change is required to the production hardware⁄application. User rights are kept to a minimum at all times. In the event of a staff member’s employment termination, all access is removed immediately.

Afilias applications use encrypted network communications. Access to the registry server is controlled. Afilias allows access to an authorized registrar only if each of the authentication factors matches the specific requirements of the requested authorization. These mechanisms are also used to secure any web-based tools that allow authorized registrars to access the registry. Additionally, all write transactions in the registry (whether conducted by authorized registrars or the registryʹs own personnel) are logged.

EPP connections are encrypted using TLS⁄SSL, and mutually authenticated using both certificate checks and login⁄password combinations. Web connections are encrypted using TLS⁄SSL for an encrypted tunnel to the browser, and authenticated to the EPP server using login⁄password combinations.

All systems are monitored for security breaches from within the data center and without, using both system-based and network-based testing tools. Operations staff also monitor systems for security-related performance anomalies. Triple-redundant continual monitoring ensures multiple detection paths for any potential incident or problem. Details are provided in our response to questions #30(b) and #42. Network Operations and Security Operations teams perform regular audits in search of any potential vulnerability.

To ensure that registrar hosts configured erroneously or maliciously cannot deny service to other registrars, Afilias uses traffic shaping technologies to prevent attacks from any single registrar account, IP address, or subnet. This additional layer of security reduces the likelihood of performance degradation for all registrars, even in the case of a security compromise at a subset of registrars.

There is a clear accountability policy that defines what behaviors are acceptable and unacceptable on the part of non-staff users, staff users, and management. Periodic audits of policies and procedures are performed to ensure that any weaknesses are discovered and addressed. Aggressive escalation procedures and well-defined Incident Response management procedures ensure that decision makers are involved at early stages of any event.

In short, security is a consideration in every aspect of business at Afilias, and this is evidenced in a track record of a decade of secure, stable and reliable service.

INDEPENDENT ASSESSMENT

Supporting operational excellence as an example of security practices, Afilias performs a number of internal and external security audits each year of the existing policies, procedures and practices for:
* Access control;
* Security policies;
* Production change control;
* Backups and restores;
* Batch monitoring;
* Intrusion detection, and
* Physical security.

Afilias has an annual Type 2 SSAE 16 audit performed by PricewaterhouseCoopers (PwC). Further, PwC performs testing of the general information technology controls in support of the financial statement audit. A Type 2 report opinion under SSAE 16 covers whether the controls were properly designed, were in place, and operating effectively during the audit period (calendar year). This SSAE 16 audit includes testing of internal controls relevant to Afiliasʹ domain registry system and processes. The report includes testing of key controls related to the following control objectives:
* Controls provide reasonable assurance that registrar account balances and changes to the registrar account balances are authorized, complete, accurate and timely.
* Controls provide reasonable assurance that billable transactions are recorded in the Shared Registry System (SRS) in a complete, accurate and timely manner.
* Controls provide reasonable assurance that revenue is systemically calculated by the Deferred Revenue System (DRS) in a complete, accurate and timely manner.
* Controls provide reasonable assurance that the summary and detail reports, invoices, statements, registrar and registry billing data files, and ICANN transactional reports provided to registry operator(s) are complete, accurate and timely.
* Controls provide reasonable assurance that new applications and changes to existing applications are authorized, tested, approved, properly implemented and documented.
* Controls provide reasonable assurance that changes to existing system software and implementation of new system software are authorized, tested, approved, properly implemented and documented.
* Controls provide reasonable assurance that physical access to data centers is restricted to properly authorized individuals.
* Controls provide reasonable assurance that logical access to system resources is restricted to properly authorized individuals.
* Controls provide reasonable assurance that processing and backups are appropriately authorized and scheduled and that deviations from scheduled processing and backups are identified and resolved.

The last Type 2 report issued was for the year 2010, and it was unqualified, i.e., all systems were evaluated with no material problems found.

During each year, Afilias monitors the key controls related to the SSAE controls. Changes or additions to the control objectives or activities can result due to deployment of new services, software enhancements, infrastructure changes or process enhancements. These are noted and after internal review and approval, adjustments are made for the next review.

In addition to the PricewaterhouseCoopers engagement, Afilias performs internal security audits twice a year. These assessments are constantly being expanded based on risk assessments and changes in business or technology.

Additionally, Afilias engages an independent third-party security organization, PivotPoint Security, to perform external vulnerability assessments and penetration tests on the sites hosting and managing the Registry infrastructure. These assessments are performed with major infrastructure changes, release of new services or major software enhancements. These independent assessments are performed at least annually. A report from a recent assessment is attached with our response to question #30(b).

Afilias has engaged with security companies specializing in application and web security testing to ensure the security of web-based applications offered by Afilias, such as the Web Admin Tool (WAT) for registrars and registry operators.

Finally, Afilias has engaged IBM’s Security services division to perform ISO 27002 gap assessment studies so as to review alignment of Afilias’ procedures and policies with the ISO 27002 standard. Afilias has since made adjustments to its security procedures and policies based on the recommendations by IBM.

SPECIAL TLD CONSIDERATIONS

Afilias’ rigorous security practices are regularly reviewed; if there is a need to alter or augment procedures for the .ECO Community TLD, they will be done so in a planned and deliberate manner. No new procedures are currently anticipated.

COMMITMENTS TO REGISTRANT PROTECTION

With over a decade of experience protecting domain registration data, Afilias understands registrant security concerns. Afilias supports a “thick” registry system in which data for all objects are stored in the registry database that is the centralized authoritative source of information. As an active member of IETF (Internet Engineering Task Force), ICANN’s SSAC (Security & Stability Advisory Committee), APWG (Anti-Phishing Working Group), MAAWG (Messaging Anti-Abuse Working Group), USENIX, and ISACA (Information Systems Audits and Controls Association), the Afilias team is highly attuned to the potential threats and leading tools and procedures for mitigating threats. As such, registrants should be confident that:
* Any confidential information stored within the registry will remain confidential;
* The interaction between their registrar and Afilias is secure;
* The Afilias DNS system will be reliable and accessible from any location;
* The registry system will abide by all polices, including those that address registrant data;
* Afilias will not introduce any features or implement technologies that compromise access to the registry system or that compromise registrant security.

Afilias has directly contributed to the development of the documents listed below and we have implemented them where appropriate. All of these have helped improve registrants’ ability to protect their domains name(s) during the domain name lifecycle.
* [SAC049]: SSAC Report on DNS Zone Risk Assessment and Management (03 June 2011)
* [SAC044]: A Registrantʹs Guide to Protecting Domain Name Registration Accounts (05 November 2010)
* [SAC040]: Measures to Protect Domain Registration Services Against Exploitation or Misuse (19 August 2009)
* [SAC028]: SSAC Advisory on Registrar Impersonation Phishing Attacks (26 May 2008)
* [SAC024]: Report on Domain Name Front Running (February 2008)
* [SAC022]: Domain Name Front Running (SAC022, SAC024) (20 October 2007)
* [SAC011]: Problems caused by the non-renewal of a domain name associated with a DNS Name Server (7 July 2006)
* [SAC010]: Renewal Considerations for Domain Name Registrants (29 June 2006)
* [SAC007]: Domain Name Hijacking Report (SAC007) (12 July 2005)

To protect any unauthorized modification of registrant data, Afilias mandates TLS⁄SSL transport (per RFC 5246) and authentication methodologies for access to the registry applications. Authorized registrars are required to supply a list of specific individuals (five to ten people) who are authorized to contact the registry. Each such individual is assigned a pass phrase. Any support requests made by an authorized registrar to registry customer service are authenticated by registry customer service. All failed authentications are logged and reviewed regularly for potential malicious activity. This prevents unauthorized changes or access to registrant data by individuals posing to be registrars or their authorized contacts.

These items reflect an understanding of the importance of balancing data privacy and access for registrants, both individually and as a collective, worldwide user base.

The Afilias 24⁄7 Customer Service Center consists of highly trained staff who collectively are proficient in 15 languages, and who are capable of responding to queries from registrants whose domain name security has been compromised – for example, a victim of domain name hijacking. Afilias provides specialized registrant assistance guides, including specific hand-holding and follow-through in these kinds of commonly occurring circumstances, which can be highly distressing to registrants

SECURITY RESOURCING PLANS

Please refer to our response to question #30b for security resourcing plans.

BIG ROOM (.ECO REGISTRY OPERATOR) SECURITY POLICY

Big Room maintains a security policy which is commensurate to the nature of the .ECO Community TLD, and which complements the Afilias security policy. In the event that Big Room becomes the .ECO registry operator, we will develop, implement, and appropriately resource the necessary security policy, processes, and infrastructure required to complement those of our registry service provider.

Key elements of Big Room’s existing security plan as they relate to vital business functions are outlined in 30(b).



© 2012 Internet Corporation For Assigned Names and Numbers.