My Cart
Toll Free
888.398.4703
International
++1.760.736.3700

Application Preview

Application number: 1-910-64447 for Public Interest Registry

Generated on 11 06 2012


Applicant Information


1. Full legal name

Public Interest Registry

2. Address of the principal place of business

1775 Wiehle Avenue
Suite 200
Reston Virginia 20190
US

3. Phone number

+17038895778

4. Fax number

+17038895779

5. If applicable, website or URL

http:⁄⁄www.pir.org

Primary Contact


6(a). Name

Mr. Brian Andrew Cute

6(b). Title

CEO

6(c). Address


6(d). Phone Number

+17035916320

6(e). Fax Number


6(f). Email Address

bcute@pir.org

Secondary Contact


7(a). Name

Mr. David Maher

7(b). Title

General Counsel

7(c). Address


7(d). Phone Number

+13126489356

7(e). Fax Number


7(f). Email Address

dmaher@pir.org

Proof of Legal Establishment


8(a). Legal form of the Applicant

A Pennsylvania nonprofit corporation

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

A Pennsylvania nonprofit corporation, tax exempt pursuant to the provisions of the Internal Revenue Code of the United States of America, section 501(c)(3).

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.

Not applicable. PIR is the sole applicant. The Internet Society is the sole incorporator and sole member of the Public Interest Registry (PIR).

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

Not applicable. PIR is the sole applicant.

Applicant Background


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

Amitabh SinghalAssistant Secretary
Arthur ReillyDirector
Erik HuizerVice Chair
Maarten BottermanChair
Raimundo BecaDirector

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

Brian CuteCEO
David MaherGeneral Counsel
Lance WolakVice President
Larry MartinVice President

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


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.

ONG

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.

Public Interest Registry (PIR) and Afilias Limited, the registry backend service provider, anticipates the introduction of the .ONG gTLD without operational or rendering problems. Based on a decade of experience launching and operating new TLDs, Afilias is confident the launch and operation of the .ONG gTLD 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 the .ONG gTLD;
- 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 the .ONG gTLD.

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.

This application accompanies PIR’s application for .NGO, with .ONG serving as a linguistic expression of “Non-Governmental Organization”. Linguistic expressions include French: “Organisation Non Gouvernementale”, Spanish: “Organización No Gubernamental”, and Portuguese: “Organizacao Nao Governamental.

The mission⁄purpose of the .ONG gTLD is to serve the global NGO Community by supplying it with an exclusive gTLD that will offer NGOs and NGO Associations differentiated and verified online identities, and thereby building confidence for their respective clients, partners, and benefactors.

Members of the NGO Community include Non-Governmental Organizations (NGOs) and NGO associations. NGOs are defined as organizations whose mission and activities are broadly centered on improving the human condition, and are non-governmental, non-profit and non-criminal. NGOs have created NGO associations that are global, regional, and national in scope to face their common challenges and promote their common themes in a coherent fashion despite their diverse missions. For example, many NGO associations promote codes of conduct and self-regulation frameworks designed to reinforce their cohesion.

The NGO Community establishment is found in Evaluation Question #20 of this application.

The exclusivity of the .ONG domain will be provided through domain name registration restrictions and enforcement mechanisms. Domain name registrations under .ONG will solely be open to Non-Governmental Organizations who pass all established eligibility requirements. These registration restrictions will give users’ and benefactors’ confidence in the credibility of the .ONG websites they are visiting. This will afford individuals and groups greater assurance that the .ONG they are researching is a valid, Non-Governmental Organization.

PIR has conducted numerous outreach and research activities within the NGO Community to identify needs for additional services beyond a .ONG domain. This has revealed that the NGO Community has a need for an online source of information about NGOs, combining regional and local organization information, ideally a directory to provide a global platform for raising online awareness. To address this need, PIR is considering an online, global directory for .ONG registrants. Within this directory the .ONG registrants could promote their organization, and share their contact information with the Internet community within a single, unique and trusted repository.

Today, the global NGO Community is estimated conservatively at 6.7 million NGOs and NGO associations. NGOs face many challenges in describing and differentiating their unique characteristics on the Internet. They need to be able to distinguish themselves online from the commercial, for-profit, government entities and casual, unstructured groups. This distinction on the Internet is critical for NGOs to raise awareness and manage fundraising within their fields of service online and thereby reaching the global online market. As such, while the term “NGO” is already well recognized around the world, when coupled with a new gTLD, it will give NGOs the opportunity to bring their distinct characteristics to global Internet users by clearly differentiating themselves with their own online domain. .ONG will be launched as a restricted gTLD, which in turn will provide Internet users worldwide the confidence that they are interacting with a valid NGO. In this way, the .ONG gTLD domain provides to the NGO Community a tool to enhance accountability and transparency which is critical to donors, foundations and others who wish to contribute to NGO activities.

As a NGO itself, the Public Interest Registry (PIR) is acutely aware of the needs and challenges for NGOs managing online activities. PIR manages .ORG, an unrestricted gTLD – the domain which has served the international NGO Community (among other communities) for more than 25 years. Part of .ORG management has always involved direct discussions with non-commercial, NGOs, and nonprofit organizations. PIR has discussed the unmet requirements of the international NGO Community starting with outreach prior to the assignment of .ORG in 2003; and has carried this forward, specifically regarding the ability to distinguish verified organizations from those domain holders without a specific non-governmental function. It is through this history of interaction with the nonprofit and NGO sector that PIR has identified and is responding to stakeholder interest in a restricted, community gTLD.

To remain connected with the needs and challenges of NGOs, PIR will create a special NGO Community Advisory Council composed of members from the NGO Community to advise on issues including broad .ONG policies and the introduction of new services. Their perspective, representing voices from the global NGO Community, will play a vital role in the long-term success of .ONG. PIR has already established a “pre-NGO Community Advisory Council” that will assist in the creation of the NGO Community Advisory Council and will advise on the verification process for .ONG registrations.

The .ONG gTLD will be a valuable part of ICANN’s expansion consistent with guidance defined in Section 9.3 of the Affirmation of Commitments (AoC). Specifically, the .ONG gTLD will promote the goals of the new TLD round and the AoC reflected in the following ways:
• A stable launch of a new gTLD that provides registrants a clear choice with a relevant domain;
• Internet users trusting in the authenticity of the .ONG gTLD; and,
• An active NGO Community involvement in the .ONG gTLD, such as through PIR’s NGO Community Advisory Council.

In short, the .ONG domain will be the choice for NGOs in need of an exclusive online space to raise visibility, to drive awareness for a cause, and to make a positive impact. The exclusive .ONG domain, administered in a trusted and responsible manner by PIR, will give NGOs a unique, relevant, respected place on the Internet.

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

NGO will benefit registrants, Internet users, and others as described below in response sections 18b(i-v).

18b(i) The goal of .ONG is to provide an exclusive domain to be used only by NGOs. Since NGOs rely on the contributions of foundations, individuals and public institutions to advance their respective missions, their reputation as trustworthy stewards of such funds and transparency with respect to their operations is critical to their long-term viability. Through its ongoing interaction with the NGO Community, PIR is aware of the reputational challenges presented by “briefcase NGOs.” Briefcase NGOs hold themselves out as bona fide NGOs but are in fact fraudsters who abscond with donated funds thereby damaging the reputation of NGOs. .ONG will provide a platform through which NGOs can demonstrate accountability and transparency to their potential donors with a unique online domain.

Specific value to potential registrants includes:
• .ONG will provide a unique and exclusive, verified domain on the Internet where NGOs can assert their identities and can easily be found by end-users.
• .ONG will provide a credible venue for grassroots, local, regional and global NGOs to communicate with their key donors, influencers and followers.
• Although many NGOs already use the .ORG domain, .ORG is an “open” domain that is used by a variety of non-commercial and commercial organizations. NGOs also use domain names of other gTLDs and ccTLDs. The .ONG domain provides an opportunity for clearer identification.
• .ONG will provide a set of services that allow NGOs multiple mechanisms for identification and discovery in an exclusive, trusted environment.

PIR has conducted numerous outreach and research activities within the NGO Community to identify needs for additional services beyond a .ONG domain. This has revealed that the NGO Community has a need for an online source of information about NGOs, combining regional and local organization information, ideally a directory to provide a global platform for raising online awareness. To address this need, PIR is considering an online, global directory for .ONG registrants. Within this directory the .ONG registrants could promote their organization, and share their contact information with the Internet community within a single, unique repository.

18b(ii) .ONG will advance the goals of competition, differentiation and innovation in a number a ways. Creating a unique gTLD for NGOs will advance competition among TLDs that currently offer domain service to NGOs. A restricted .ONG gTLD provides differentiated competition to TLDs and ccTLDs that NGOs might otherwise choose as a home for their second level domain registrations, and offers greater ease of getting their preferred domain name. Among the wide selection of TLDs, ccTLDs, sTLDs and IDN TLDs, an exclusive and uniquely identifiable .ONG gTLD will provide NGOs differentiation that also benefits users who are searching for NGOs on the Internet.

18b(iii) For the global Internet user community, the .ONG gTLD provides immediate identification and a level of confidence not available today. Individuals and corporate donors looking to partner with or fund qualified NGOs can turn to the .ONG domain to discover potential matches for their desired philanthropic or corporate social responsibility endeavors. Further, the enhanced level of accountability and transparency inherent in the restricted NGO Community domain will be a benefit to global Internet users.

18b(iv) To achieve the above goals and assure that .ONG domain names are allocated in a manner that serves the NGO Community, PIR has developed a set of .ONG Registration Policies and corresponding compliance and enforcement mechanisms.

The policies are built to match the needs of the NGO Community based on feedback from NGO Community members; experience from the .ORG gTLD management since 2003; and the need for a higher security level for .ONG domain names than what currently is considered as the standard global requirements for gTLDs today.

.ONG Registration Policies
The registration policies in support of the NGO Community goals are described in the following summary and are detailed later in this section.
• Registrant Eligibility Requirements – all registrants must demonstrate affiliation through NGO membership organizations or through evidence of NGO status. PIR will work with membership organization, the NGO Community Advisory Council, and other members of the NGO Community to validate their eligibility.
• Content and Use Restriction Policy – ensures that usage of the .ONG domain name corresponds with NGO Community activities.
• Compliance Functions – ensures ongoing compliance of the Registrant Eligibility Requirements, and the Content and Use Restriction Policy listed below.
• Name Selection Policy – ensures that only NGO Community relevant domain names are registered.
• Reserved Name Policy – names⁄types of domain names will initially be reserved from registration under .ONG.
• Registry Name Policy – names⁄types of domain names will be held from general availability, these will be used in support of the registry.

The following policies support of the NGO Community goals and are detailed in subsequent Evaluation Questions of the application dedicated to such policies, as noted below.

• Abuse Prevention and Mitigation – includes the Anti-Abuse Policy which addresses the identification and prompt action taken on malicious use of domain names, and the Restriction Dispute Resolution Policy (RDRP) which ensures that disputes concerning any of the .ONG Registration Policies can be solved in an appropriate manner. Detailed descriptions of both policies can be found in response to Evaluation Question #28.
• Rights Protection Mechanisms – protects intellectual property holders under the Trademark Clearinghouse, Uniform Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS), Registry Restrictions Dispute Resolution Procedures (RRDRP), Post-Delegation Dispute Resolution Policy (PDDRP), in addition to the Sunrise services and policies that can be found in response to Evaluation Question #29.

PIR will review all policies and processes on an annual basis with involvement from the PIR’s NGO Community Advisory Council and present the results to the NGO Community, allowing them to provide feedback.

Specific Policy Details

Registrant Eligibility Requirements: The .ONG domain registrations are open to NGO Community members. All registrants must demonstrate affiliation through NGO membership organizations or through evidence of NGO status. PIR will work with NGO membership organizations, the NGO Community Advisory Council, and other members of the NGO Community to validate the eligibility of prospective registrants.

In consultation with PIR’s NGO Community Advisory Council, PIR is reviewing potential NGO membership organizations who can verify the NGO status of registrants. NGO membership organizations include the following, and will expand over time:
I. Global organizations: International associations and⁄or classification-based associations.
II. Regional organizations: Associations across broad geographic areas, potentially including multiple countries or jurisdictions.
III. Local organizations: Associations or groups that provide support and memberships at a country or local level.

During the registration process, the registrant will be asked to verify their eligibility and to demonstrate affiliation with a NGO member organization. Once the initial certification in step 1 of the verification process is confirmed, the domain is successfully created. If the .ONG registrant fails to provide any additional required information through step 2 of the verification process, the domain will be deleted and released back into the pool of available domains. See Evaluation Question #20e for detail on eligibility requirements.

Content and Use Restriction Policy: Abusive use of the .ONG domain names will not be tolerated by PIR. The following use and content limitations apply:
• Overall the .ONG domain name must be for a bona fide NGO use, as defined in the Restrictions Dispute Resolution in response to Evaluation Question #28.
• Websites must be developed with the intent to promote the corresponding .ONG registrant’s existing mission and activities, and not solely for commercialized or for-profit marketing usage.
• Any use of the registered domain name to engage in activities inconsistent with the definition of the corresponding NGO is not allowed.
• Any illegal or fraudulent usage of the .ONG domain name is not allowed, including but not limited to phishing and pharming attacks, distribution of malware, and distribution of adult content.
• Registration and use of a domain name in violation of Rights Protection Mechanisms is not allowed.

Violations of any of the .ONG Registration Policies may be grounds for loss of registration, pursuant to the enforcement mechanism discussed below (with an appeal procedure).

Compliance Functions: While disputes will be managed directly by the dispute resolution providers, PIR will to conduct random compliance efforts across all the .ONG Registration Policies. Periodically PIR will conduct through compliance staff a sample of .ONG registrations to verify claims to membership in a listed organization, name policy adherence, and compliance with the name and use policy.

If a registrant is found to not be in compliance, the registrant will be notified that the domain will be placed on registry lock and that if the issue is not cured, the domain will be terminated.

As part of the compliance function PIR will also utilize its existing expertise, obtained through its management of .ORG, to monitor and take action on any abusive behavior occurring on .ONG domain names.

Name Selection Policy: The .ONG domain name that a registrant wishes to register must fulfill certain name policy criteria. PIR will employ the following restrictions concerning the names that eligible .ONG registrants can register. A .ONG registered domain name may be:
1. the name of (entire or portion of) the NGO, e.g. its “doing business as” name,
2. an acronym representing the NGO,
3. a name that recognizes or generally describes the NGO, or
4. a name related to the mission or activities of the NGO.

Reserved Name Policy: The following names⁄types of domain names will initially be reserved from registration under .ONG:
I. All single- and two-character second-level domain names;
II. Domains of an inappropriate nature, e.g., adult-related terminology, pursuant to a list defined by PIR and its NGO Community Advisory Council;
III. Names provided by ICANN as required reserved names;
IV. A list of generic names defined by PIR and its NGO Community Advisory Council based on the overall criteria that the names represent the NGO Community in a general manner. Such names will be released in a specific RFP process ensuring that the names will benefit the NGO Community.

Registry Name Policy: The following names⁄types of domain names will be held from general availability, these will be used in support of the registry.
• Names to support registry operations, e.g., directory.ONG;
• Names to support PIR’s NGO Community Advisory Council.

Compliance and Enforcement Mechanisms
PIR will take both proactive and reactive measures to enforce the policies of the gTLD. Proactive measures are taken at the time of registration by requiring .ONG registrants to meet the .ONG Registration Policies and to agree to all policies and procedures of the gTLD. Reactive measures are addressed via our audit process (described below) and through our defined dispute resolution processes.

A violation of the .ONG Registration Policies will be enforced on a case-by-case, fact specific basis, under the processes set forth below:
1. Any allegation that a domain name is not used primarily for NGO purposes shall be enforced under the provisions of the Restrictions Dispute Resolution Policy (ʺRDRPʺ) as described in Evaluation Question #28. The RDRP will be included as an appendix to the Registry Agreement. An appeal procedure is included in the RDRP.
2. Any alleged violation of the Rights Protection Mechanisms shall be enforced under the provisions contained in each of them.

Disputes resulting from violations of the .ONG Registration Policies will be resolved through the Compliance Functions and the Rights Protection Mechanisms. The Rights Protection Mechanisms (as detailed in Evaluation Question #29) will be made applicable by the ICANN-Accredited Registrarsʹ registration agreements with registrants. Proceedings under the Rights Protection Mechanisms will be conducted in accordance with the policies and procedures that will be included in an appendix to the Registry Agreement. As set forth in the Compliance Functions, the registry operator will review on a random basis, monitor, and verify that any particular domain name is being used primarily for NGO purposes and that a domain name is being used in compliance with the Rights Protection Mechanisms processes.

18b(v) PIR will manage .ONG in accordance with best practices and specific policies around privacy and data protection, as it does for nearly 10 million .ORG registrations today. Specific protections of the WHOIS administered by the registry backend service provider can be found in Evaluation Question #26, and details on our privacy policies in Evaluation Question #28.

18b(vi) Ongoing outreach and communications with the NGO community ensures that we meet the projected benefits as described and established in response to #18b(i-v). The NGO Community is large and global in reach. As such, coordinated efforts and international outreach and communication are necessary. As described in the following, PIR has conducted and is committed to continuing important outreach and communication with the NGO Community to promote the .ONG gTLD so that it may fully provide these benefits to NGOs and their respective stakeholders.

Pursuant to its mission, PIR has been conducting outreach to the NGO Community since its management of the .ORG domain began in 2003. Over the course of 2011, PIR engaged in a global outreach and communications effort to the NGO Community to explain the intended benefits of the new .ONG gTLD, soliciting advice and feedback, and seeking their support for the application. Throughout 2011 and continuing through 2012, PIR has conducted outreach in many forms – one-on-one meetings, group meetings in cooperation with local NGO associations, a series of Information and Communication Technology (ICT) workshops dedicated to bringing internet access and usage to the NGO Community, forum discussions at NGO association meetings and conferences, and webinars for the NGO Community.

The outreach has spanned multiple countries across Asia, Europe, North America, South America⁄Latin America, and Africa. Also, the outreach has spanned across many different segments of the NGO Community to include individual NGOs and national, regional and global NGO associations. PIR has presented the .ONG gTLD proposal and received support letters from NGOs engaged in activities including but not limited to agriculture, environment, arts⁄culture, charitable services, human rights, humanitarian, and advocacy for a range of issues affecting societal development. PIR has received enthusiastic support and has been provided with specific feedback from NGOs and NGO associations concerning the management of the .ONG domain.

Specific to the projected benefits for the .ONG gTLD, the outreach is helping us and the NGOs in the following way:

Exclusivity – Through PIR’s outreach effort to gather input, NGO’s have asked for an exclusive space on the worldwide web to verify their credentials and to prevent “briefcase NGOs” (i.e., fraudsters) from registering the .ONG gTLD, so as to enhance the reputation of bona fide NGOs. The outreach has and will continue to enable PIR to sign up membership organizations to assist in the verification of the .ONG Registration Requirements. The registration eligibility requirements that we have established with the NGO Community and the associated enforcement mechanisms will create the exclusivity for proven community members and establish trust with the public.

Visibility – The outreach effort and community response described above has underscored the community need for improving their visibility in new ways. The gTLD domain ending in .ONG is seen by the community as providing a unique identifier to stand out in a crowded worldwide web – a distinctive new form of identification.

Reliability – NGO input during our outreach has underscored the importance of reliable technical administration and management of the gTLD domain. Based on PIR’s long-term successful management of .ORG and its outreach with the NGO Community, it will ensure the secure and stable operation of the .ONG gTLD, the delivery of beneficial value added services to NGOs, proper handling of data, and an ongoing relationship with the NGO Community.

The outreach program will allow PIR to achieve the projected benefits of unique identification, differentiation, competition, and an enhanced level of user confidence through the .ONG domain name.

PIR will continue its outreach to the NGO Community throughout 2012 and beyond through meetings and workshops in all global regions. PIR will conduct face-to-face meetings and calls with the NGO Community Advisory Council seeking ongoing input and advice with respect to the management of the .ONG gTLD and the certification processes necessary to ensure that only bona fide NGOs register in the .ONG gTLD.

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

PIR’s long-standing track record speaks to its core mission to serve the public interest, and thereby minimizing social costs,(e.g. as has been done through PIR’s implementation of anti-abuse policies, the rollout of DNSSEC, active participation in public interest events, and more.) PIR will launch and manage .ONG in a responsible manner befitting the integrity of the NGO Community. Our global outreach in preparation of this application provided direct guidance on the specific needs of the community, concerns on policies, and procedures for registration and pricing. This knowledge is reflected in this application.

Minimizing negative social costs and consequences on registrants and consumers:
PIR’s plan for launching the .ONG gTLD offers a robust, cost-effective means for NGOs to assert their identities online and minimize social costs and consequences. A goal of this name space is to keep impacts and burden to the community nominal, and focus on the positive benefits of having a .ONG domain. PIR is confident our .ONG gTLD domain name registration service, pricing, and related policies do not place burdens on the community, but rather, will support their goals.

NGOs and the NGO Community are particularly vulnerable to social costs issues. Through PIR’s outreach with the NGO Community, we are acutely aware that, while some NGOs are well funded many NGOs (e.g., grassroots NGOs) have limited resources be they financial or human. As such, these NGOs cannot bear unanticipated social costs without direct impact on their ability to carry out their respective missions.

In particular, the initial wholesale price per year for registration includes NGO Community verification, which offers NGOs an advantageous and affordable domain where they can build a unique and exclusive presence online. This pricing has been established both through community outreach, as well as through benchmark analysis of comparable community gTLDs and ccTLDs existing today. In such comparison the .ONG registration fee is found to be in the lower end.

PIR’s operating rules will minimize social costs through the eligibility requirements where only NGOs can register the domain name and therefore, eliminating general consumers engaging defensive registration. To address intellectual property concerns, the launch of this gTLD will include participation in a Trademark Clearinghouse Service which jointly with the .ONG Sunrise process will allow eligible NGOs a first chance at registering their organization name.

Finally, as previously discussed, PIR is uniquely positioned to minimize confusion and market misrepresentation. When the .ONG gTLD is delegated, PIR will manage it in such a manner that ensures fairness and competition in the registration of domain names, does not place a financial burden on registrants, and limits market confusion among both registrants and end-users.

Additional measures for minimizing social costs are described in the following subsections.

18c(i) In general, following the initial Sunrise registration processes, registrations will be processed on a first-come, first-served basis. For NGOs that were not able to register the name they preferred and believe such name has been awarded in error to another entity, PIR has developed the .ONG Sunrise Dispute Resolution Policy explained in Evaluation Question #29.

18c(ii) PIR will from time-to-time offer discount⁄rebate programs for .ONG registrations through its distribution channels. The initial wholesale price per year for registration includes NGO Community verification which offers NGOs an advantageous and affordable domain to build a unique and exclusive presence online.

18c(iii) PIR will offer terms of up to 10 years for domain name registrations. Depending on the needs of NGOs and only after consultation with ICANN, PIR may consider offering longer-term contracts. At this time, PIR will not offer permanent contracts.

Depending on the cost of doing business and other economic factors, PIR may from time-to-time increase the wholesale price in accordance with the provisions of Section 2.10 of the new gTLD Registry Agreement.

PIR, as a NGO and nonprofit organization, will carefully consider the needs of the NGO Community as it maintains prices on its services.

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.

Community Name and Full Description
Through this .ONG application, PIR is committed to serving the “NGO Community”.
This application accompanies PIR’s application for .NGO, with .ONG serving as a linguistic expression of “Non-Governmental Organization”. Linguistic expressions include French: “Organisation Non Gouvernementale”, Spanish: “Organización No Gubernamental”, and Portuguese: “Organizacao Nao Governamental.
Members include Non-Governmental Organizations (NGOs) and NGO associations. NGOs are defined as organizations whose mission and activities are broadly centered on improving the human condition, and are non-governmental, non-profit and non-criminal. NGOs have created NGO associations that are global, regional, and national in scope to, as a community, face their common challenges and promote their common themes in a coherent fashion, across their diverse missions. For example, many NGO associations promote codes of conduct and self-regulation frameworks designed to reinforce their cohesion.[1]
The activities of NGOs have been conducted through international NGOs dating back to the 1830s and have evolved in scope to the present day to include well-established regional and national NGOs which have become household names.
This NGO Community is firmly established and clearly satisfies the criteria of delineation, organization, and pre-existence.[2]
Delineation
The NGO Community is global and comprised of individual NGOs and NGO associations.
Pre-Existing
The NGO Community has been active since well before 2007. Indeed, the origins of NGOs can be traced back to 1839.[3] NGOs were recognized in Article 71 of the United Nations (U.N.) Charter of 1945.[4] Since then, the NGO Community has become increasingly active and firmly established in its dealings with both governments and commercial organizations.
Organized
The global NGO Community certainly meets the criteria of “at least one entity mainly dedicated to the community with documented evidence of community activities.”[5] NGOs have themselves over time created numerous associations that organize and serve their NGO Community.[6] The diverse characteristics of NGOs are routinely recognized by non-NGO entities. For example, the European Commission, when interacting with the NGO Community, requires that they “respect [the] diversity and heterogeneity of the NGO community.”[7] Additionally, members of the NGO Community recognize themselves as part of a global NGO Community, and seek ways to collaborate at the local, regional, or global level.[8][6]
Extension
The following describes the “Extension” through three dimensions of the NGO Community – Number of Members, Geographical Reach, and Foreseeable Activity Lifetime (Longevity).
Number of Members and Geographical Reach: There is no central record of the global NGO Community size and geographic reach, but PIR’s own research including direct contact with NGO associations indicate in October 2011 that the community would be conservatively estimated at an order of magnitude in excess of 6.7 million[9], distributed approximately as follows across the U.N. recognized regions:
• Africa: 108,000
• Americas: 1,414,000
• Asia: 1,658,250
• Europe: 2,988,200
• Oceana: 604,000
Foreseeable Activity Lifetime (Longevity): The pursuits of the NGO Community are of a lasting and non-transient nature. The pursuits are broadly centered on improving the human condition, which is fundamental to human activity and will therefore continue indefinitely. The recognition of the NGO Community by governments and commercial organizations[10][11] combined with the spread of communications technology and increasing global social interaction will ensure that the NGO Community will continue long into the future.
Size (Context)
As the research bears out, the estimated 6.7 million members of the NGO Community are spread across the globe. Since 1945, the number of NGOs has increased dramatically with an explosion of NGOs in the developing world since the 1970s.[12] The size and reach of NGOs is also measurable in monetary terms. For example, in 1992 international NGOs channeled over $7.6 billion of aid to developing countries. Moreover, it is estimated that over 15 percent of total overseas development aid is channeled through NGOs.[13]
[1] ʺThe [International NGO] INGO Accountability Charter was first discussed at the International Advocacy Non-Government Organisations (IANGO) Workshop hosted by Transparency International in June 2003. On the 6th of June 2006, eleven leading INGOs held a press conference in order to publicly declare their adoption of the Charter and encourage other INGOs to join them in their commitment to good governance to set the standard for international NGOs. There are currently 25 INGOs and a large number of their national affiliates that are members of the Charter.ʺ Members include Amnesty International, Article 19, Care International, CIVICUS World Alliance for Citizen Participation, Consumer International, and Oxfam. From The Commitment of INGOs to Accountability
[2] The Rise and Fall of the Transnational Civil Society: the Evolution of International Civil Society Organizations since 1839, April 2008, pp.3-4, http:⁄⁄www.staff.city.ac.uk⁄tom.davies⁄CUWPTP003.pdf
[3] ibid, page 7
[4] www.un-documents.net⁄ch-10.htm
[5] ICANN Guidebook, Module 4, Criterion 1 Definitions
[6] Examples of NGO Associations for NGO collaboration include: NTEN, CIVICUS, CONGO, (global); CONCORD (regional); Computer Association of Nepal, APB Yatri Welfare Association (local)
[7] The Commission remains therefore committed to respect the following overarching principles in the management of NGO projects and programmes:The need to respect diversity and heterogeneity of the NGO community; The Commission and Non-Governmental Organizations: building a Stronger Partnership
http:⁄⁄ec.europa.eu⁄transparency⁄civil_society⁄ngo⁄docs⁄communication_en.pdf
[8] http:⁄⁄www.ngocongo.org⁄committees⁄
CONGO and its members collaborate with the larger community of NGOs through standing NGO committees, which follow issues that are of key substantive interest relative to their mandates and objectives
[9] PIR conducted primary research through direct contact with NGO Associations in 27 countries to establish a base level NGO population
[10] In NGO Impact Initiative: An Assessment by the International Humanitarian NGO Community Report commissioned by William Jefferson Clinton, www.dochas.ie⁄Pages⁄Resources⁄documents⁄NGO_Impact_Initiative.pdf
For those businesses willing to engage with the NGO community, how can they do so? The rise and role of NGOs in sustainable development
[11] http:⁄⁄unesdoc.unesco.org⁄images⁄0021⁄002112⁄211286e.pdf (Annex page 9)
“(ii) take all necessary steps to ensure the proper functioning and efficiency of the partnership between the community of NGO partners and UNESCO; (iii) ensure the appropriate exchange of information with the non-governmental community it represents and, in this connection, promote consultation among NGOs at all levels;” New Directives Concerning UNESCO’S Partnership with Non-Governmental Organizations
“And by we, I do not only mean the 47 members of the Council, but also all the other interested UN states who are active as observers and potential future Council members as well as the crucial community of NGO and National Human Rights Institutions which have a vital stake in how the Council will function.” The Human Rights Council: The Story So Far and Future Challenges Presentation by Ambassador Paul Meyer Permanent Mission of Canada in Geneva, Winnipeg, February 23, 2007
[12] Non-Governmental Organizations (NGOs) and Politics in the Developing World, Pol Std., Vol 46
[13] World Bank website ʺNongovernmental Organizations and Civil Society⁄Overview.ʺ referenced in library.duke.edu⁄research⁄subject⁄guides⁄ngo_guide⁄igo_ngo_coop⁄ngo_wb.html and www.un.org⁄ecosocdev⁄geninfo⁄afrec⁄subjindx⁄131ngo.htm

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

PIR is a NGO, and thereby part of the NGO Community. PIR as an NGO has extensive gTLD management experience via the .ORG gTLD. PIR a supporting organization to the Internet Society (ISOC) and is committed to supporting the Internet Society’s (ISOC) mission stated below.
History of PIR’s Relationship to the NGO Community
In January 2003, PIR, assumed responsibility for operating .ORG and maintaining the authoritative database of all .ORG domains.
Created in 1984, .ORG is one of the Internetʹs original seven top-level domains (TLDs), along with .com, .net, etc. Although it is ʺopenʺ and ʺunrestrictedʺ, .ORG has been the domain of choice for organizations dedicated to serving the public interest. The high regard of these well-intentioned organizations was soon conferred to this domain, and today .ORG is considered around the world to be the domain of trust.
Public Interest Registry’s (PIR) primary activity is to maintain the .ORG domain registry as the exemplary top level domain (TLD) registry service, by advocating for higher standards of Internet security, safety and reliability. PIR’s mission is to facilitate the effective use of a global Internet among non-commercial and other Internet users worldwide. In its relationship with the ISOC, (reference Evaluation Questions #9a and #9b), PIR is committed to supporting ISOC’s goals of encouraging the evolution of the Internet as research, education and communication infrastructure equally accessible to the global non-commercial, NGO and nonprofit community. PIR’s activities also include funding educational programs focused on expanding the knowledge and ability of non-commercial, NGO and nonprofit organizations located in technologically deprived areas of the world to more efficiently and effectively use the Internet as a tool to better accomplish their important mission.
The 2003 transition of .ORG from the previous operator to PIR was the largest transfer in Internet history. More than 2.6 million domains were transferred in about a day, without negatively impacting any .ORG registrant or website.
Since 2003, PIR has been connected with NGOs through our management of .ORG, and recently in preparation for our pursuit of the .ONG gTLD domain, we have worked closely with the NGO Community to develop the requirements and specification for the proposed .ONG gTLD.
Current Relationship to the NGO Community
PIR is a strong supporter of NGOs in both a direct role as manager of the .ORG gTLD and through other efforts, including:
• A ʺStrategic and Sponsoring Partnerʺ of NTEN, the Non-Profit Technology Network of 10,000 members and over 30,000 participants in the community, covering 126 countries. NTEN aspires to a world where all nonprofit organizations use technology skillfully and confidently to meet community needs and fulfill their missions.
• Making financial contributions to various organizations, such as the NCUC (Non Commercial Constituency of ICANN) and Centr. For NCUC, annual donations have been in the $5,000 to $15,000 range every year since PIR assumed operations of the .ORG registry.
• In December 2005, PIR sponsored a symposium at the Nelson Mandela Center in Cape Town, South Africa bringing in various Internet leaders in Africa to discuss the needs of the Internet in Africa.
• In response to Hurricane Katrina, in New Orleans, Louisiana, PIR donated $1 for every new create for a limited time. The final donation was over $100,000 to the Red Cross.
• In response to Japan’s Tsunami disaster, a 3 month program was rolled out to waive renewal fees for Japanese domain name holders, in order to help those affected and unable to renew their .ORG domains.
Within the community, there is a wide appreciation of PIR’s role as an advocate of “do good” for the Internet at large, and in many countries around the world there is a general perception that .ORG domains are more trusted than other domains. At the time of application submission, PIR manages nearly 10 million .ORG domains, and is seen to do so in an exemplary way. We are very happy to be judged on this reputation.
PIR has over 100 letters of support from the NGO Community endorsing its application for .ONG. PIR will continue outreach to the community and anticipates receipt of additional support letters from NGOs throughout the ICANN application evaluation process. Specific recognition of PIR’s efforts to support the nonprofit community includes:
• “As a not-for-profit corporation, we believe that being part of the .org domain has done much to reinforce MITRE’s identity as an organization chartered to work in the public interest. [Thanks to PIR’s] continuing work to enhance the .org domain.ʺ - Al Grasso, President and CEO, The MITRE Corporation (the first .ORG registrant).
• “We recognize and applaud PIRʹs long-standing commitment to the non-profit community since taking over the management of .ORG.” - Lisa Vogt, APR, Director of Marketing & Communications, SOS Children’s Villages – USA.
PIR has conducted outreach, worked with established relationships, and developed new types of relationships which will facilitate the delivery of the .ONG domain and related services to the NGO Community. Our discussions and outreach have included NGOs in several countries across Asia, Europe, North America, South America⁄Latin America, and Africa as well as many different segments of the NGO Community to ensure wide acceptance and adoption of our proposed gTLD domain and related services. The segments include but are not limited to agriculture, environment, arts⁄culture, charitable services, human rights, humanitarian, and advocacy for a range of issues affecting societal development.
Accountability to the NGO Community
By offering .ONG as a secure and well-managed domain of trust uniquely for eligible NGOs, PIR believes that NGOs can benefit from the Internet and our specific services as a means to safely and reliably reach out to the community and sponsors. PIR will be accountable to the NGO Community by:
• A NGO Community input process soliciting input from the community through the NGO Advisory Council drawn from the community and accepting a broad range of input to stay current on the issues of importance to the community and manage the NGO verification process;
• Creating and marketing .ONG as a distinctive place on the Internet for NGOs to differentiate and promote their organization;
• Establishing community programs to support capacity building of NGOs with technical and educational platforms;
• Enforcing registration policies that elevate the integrity of the domains in the .ONG gTLD name space, soliciting input from the NGO Community;
• Easing discovery and promotion through the creation, management and promotion of the .ONG gTLD;
• Offering registration from a proven, scalable registry platform that can ensure 100% DNS availability;
• Delivering a challenge process for the NGO Community to dispute the legitimacy of a .ONG registrant or its activity on a .ONG domain; and,
• As a community priority gTLD, PIR is committing to manage the .ONG domain with participation of the community. Failing to do that would put our registry contract in jeopardy.
PIR is in an excellent position to provide such support to the NGO Community given documented experience running a stable and trusted registry. PIR holds a track record demonstrating good intent to the global community by being a leader in activities such as implementation of anti-abuse policies, DNSSEC, active participation in numerous public interest events, etc.

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

The community-based purpose of the .ONG gTLD is to provide the NGO community with a unique and exclusive TLD on the Internet. An exclusive NGO TLD and differentiated online identity services will also increase end-user confidence when they interact with a NGO and provide a platform for enhanced accountability and transparency.
The benefits of the .ONG domain are expressed in three important manners:
• Exclusivity – As discovered through our own experience and our outreach effort, NGOs have asked for an exclusive space on the worldwide web to verify their credentials and to prevent “briefcase NGOs” (i.e., fraudsters) from registering the .ONG gTLD, so as to enhance the reputation of bona fide NGOs. The outreach has and will continue to enable PIR to sign up membership organizations to assist in the verification of the .ONG Registration Policies. The registration eligibility requirements that we have established with the NGO Community and the associated enforcement mechanisms will create the exclusivity for proven community members and establish trust with the public.
• Visibility – Our outreach effort with the NGO Community has yielded the need for improving their visibility in new ways. The gTLD domain ending in .ONG is seen by the community as providing a unique identifier to stand out in a crowded worldwide web – a distinctive new form of identification. This allows a NGO to present their credentials to the rest of the world.
• Reliability – NGO input during our outreach has underscored the importance of reliable technical administration and management of the gTLD domain. Based on PIR’s long-term successful management of .ORG, it will ensure the secure and stable operation of the .ONG gTLD, During PIR’s outreach to the NGO Community, NGOs have shown confidence (in their expressions of support) that PIR will be a reliable partner in the delivery of beneficial value added services to NGOs, the proper handling of data, and the commitment to its ongoing relationship with the NGO Community.
Intended Registrants and Users
In this gTLD, NGOs will be the registrants (please see responses to Evaluation Questions #18b and #20e for more information on registration qualifications). Global Internet users, who visit .ONG websites or who conduct NGO related activities, will be confident that they are interacting with verified, Non-Governmental Organizations. Registration policies as shown in response to Evaluation Question #20e, are in line with the community-based purpose.
Methods to Carry Out Purpose
PIR understands the unique needs of the NGO Community and has developed a comprehensive plan for managing this gTLD to meet those needs. NGOs can immediately benefit from a unique gTLD to promote their respective missions, causes, and social services. PIR will use the NGO definition combined with specific eligibility polices and enforcement for the registration of domain names. This ensures integrity of the domain.
A .ONG domain name provides the global community with its own domain to be immediately recognized and to broaden opportunities for public participation, funding and contributions.
PIR has conducted numerous research activities within the NGO Community to identify needs for additional services beyond a .ONG gTLD. This has suggested that the NGO Community could benefit from an online source of information about NGOs, combining regional and local organization information in a directory that would provide a global platform for raising online awareness. To address this need, PIR is considering an online, global directory for .ONG registrants where the .ONG registrants can promote their organization, and share their contact information with the Internet community within a single, unique repository.
The .ONG gTLD is a venue for organizations to promote their mission by self-identifying as an NGO within an exclusive, trusted gTLD.

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

The relationship between the applied-for string (.ONG) and the NGO Community is described through the nexus and uniqueness of the string relative to the NGO Community. The .ONG gTLD linguistically describes Non-Governmental Organization and the NGO Community without any overreach beyond the community.
With respect to this application, the community is the NGO Community, which is comprised of NGOs and NGO associations; members of the community refer to themselves through the initials ʺNGO”. The NGO initials are commonly used and well-known and understood broadly in the global market as referring to Non-Governmental Organizations. The United Nations has a formalized, consultative relationship with NGOs and recognizes the “NGO Community” by name. The U.N. for example has addressed issues such as Globalization in its consultative work with the NGO Community.[1] The U.N. Department of Public Information Non-Governmental Organizations (DPI NGO) recognizes the NGO Community[2] and NGOs in consultative status with the U.N. and maintains an executive structure designed to facilitate interaction between the U.N. and the NGO Community.[3] Likewise, the European Commission engages in structured projects and programs with the NGO Community and NGOs. The Commission characterized its January 18, 2000 Discussion Paper titled “The Commission and Non-Governmental Organizations: Building a Stronger Partnership” as “…a first step in a process involving an extensive exchange of view with the NGO Community.”
Such usage and understanding has been built through the years, and dates back as early as 1839 (see response to Evaluation Question #20a), and is further established in the support letters provided to PIR for this .ONG application.
As the manager of .ORG, PIR has always had a close relationship with organizations of all descriptions; PIR recognizes the importance of the identification of the string .ORG to organizations in general. The string applied for, .ONG, uses these initials linguistically associate to the Non-Governmental Organization Community and its gTLD. PIR also recognizes that PIR’s .ORG domains as well as other TLDs are registered by NGOs. These NGOs would benefit from a specific identification on the Internet as bona fide NGOs through the registration of the .ONG domain.
There are no connotations beyond the NGO Community we are aware for the term NGO. PIR has conducted analysis to find additional connotations and was unsuccessful. Indeed any online and offline searches for usage of “NGO” has consistently come back to Non-Governmental Organizations.
[1] http:⁄⁄www.unglobalcompact.org⁄NewsAndEvents⁄speeches_and_statements⁄john_ruggie_ngo_community_geneva.html
[2] http:⁄⁄www.un.org⁄wcm⁄content⁄site⁄dpingorelations⁄home⁄pid⁄7316
[3] http:⁄⁄ngodpiexecom.org⁄about⁄

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

PIR’s goal is to provide the NGO Community an exclusive and immediately recognized home on the Internet. To achieve this goal and ensure that .ONG domain names are allocated in a manner that serves the NGO Community, PIR has developed a set of .ONG registration restriction policies and corresponding compliance and enforcement mechanisms.
The policies are built to match the need of the NGO Community based on feedback from NGO Community members; based on experience from the .ORG gTLD management since 2003; and generally established to ensure a higher security level for .ONG domain names than what currently is considered standard global requirements for gTLDs today.
.ONG Registration Policies
The registration policies in support of the NGO Community goals are described in the following summary and are detailed later in this section.
• Registrant Eligibility Requirements – all registrants must demonstrate affiliation through NGO membership organizations or through evidence of NGO status. PIR will work with membership organization, the NGO Community Advisory Council, and other members of the NGO Community to validate their eligibility.
• Name Selection Policy – ensures that only NGO Community relevant domain names are registered.
• Reserved Name Policy – names⁄types of domain names will initially be reserved from registration under .ONG.
• Registry Name Policy – names⁄types of domain names will be held from general availability, these will be used in support of the registry.
• Content and Use Restriction Policy – ensures that usage of the .ONG domain name corresponds with NGO Community activities.
• Compliance Functions – ensures ongoing compliance of the Registrant Eligibility Requirements, and the Content and Use Restriction Policy listed below.
The following policies support of the NGO Community goals and are detailed in subsequent Evaluation Questions of the application dedicated to such policies, as noted below.
• Abuse Prevention and Mitigation – includes the Anti-Abuse Policy which addresses the identification and prompt action taken on malicious use of domain names, and the Restriction Dispute Resolution Policy (RDRP) which ensures that disputes concerning any of the .ONG Registration Policies can be solved in an appropriate manner. Detailed descriptions of both policies can be found in response to Evaluation Question #28.
• Rights Protection Mechanisms – protects intellectual property holders under the Trademark Clearinghouse, Uniform Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS), Registry Restrictions Dispute Resolution Procedures (RRDRP), Post-Delegation Dispute Resolution Policy (PDDRP), in addition to the Sunrise services and policies that can be found in response to Evaluation Question #29.
PIR will review all policies and processes on an annual basis with involvement from the PIR’s NGO Community Advisory Council and present the results to the NGO Community, allowing them to provide feedback.
Specific Policy Details
Registrant Eligibility Requirements: The .ONG domain registrations are open to NGO Community members. All registrants must demonstrate affiliation through NGO membership organizations or through evidence of NGO status. PIR will work with NGO membership organizations, the NGO Community Advisory Council, and other members of the NGO Community to validate the eligibility of prospective registrants.
In consultation with PIR’s NGO Community Advisory Council PIR is reviewing potential NGO membership organizations who can verify the NGO status of registrants. NGO membership organizations include the following, and will expand over time:
• Global organizations: International associations and⁄or classification-based associations.
• Regional organizations: Associations across broad geographic areas, potentially including multiple countries or jurisdictions.
• Local organizations: Associations or groups that provide support and memberships at a country or local level.
During the registration process, the registrant will be asked to verify their eligibility and to demonstrate affiliation with a NGO member organization. Once the initial certification in step 1 of the verification process is confirmed, the domain is successfully created. If the .ONG registrant fails to provide any additional required information through step 2 of the verification process, the domain will be deleted and released back into the pool of available domains.
Content and Use Restriction Policy: Abusive use of the .ONG domain names will not be tolerated by PIR. The following use and content limitations apply:
• Overall the NGO domain name must be for a bona fide NGO use, as defined in the Restrictions Dispute Resolution in response to Evaluation Question #28.
• Websites must be developed with the intent to promote the corresponding .ONG registrant’s existing mission and activities, and not solely for commercialized or for-profit marketing usage.
• Use of the registered domain name to engage in activities inconsistent with the mission of a NGO is not allowed.
• Any illegal or fraudulent usage of the .ONG domain name is not allowed, including but not limited to phishing and pharming attacks, distribution of malware, and distribution of adult content.
• Registration and use of a domain name in violation of Rights Protection Mechanisms is not allowed.
Violations of any of the .ONG Registration Policies may be grounds for loss of registration, pursuant to the enforcement mechanism discussed below (with an appeal procedure).
Compliance Functions: While disputes will be managed directly by resolution providers, PIR will conduct random compliance audits across all the .ONG Registration Policies. Periodically PIR’s compliance staff will audit a sample of .ONG registrations to verify claims to membership in a listed organization, name policy adherence, and compliance with the name and use policy.
If a registrant is found to not be in compliance, the registrant will be notified that the domain will be placed on registry lock and that if the compliance issue is not cured the domain will be terminated.
As part of the compliance function PIR will also utilize its existing expertise, obtained through its management of .ORG, to monitor and take action on any abusive behavior taken place with .ONG domain names.
Name Selection Policy: The .ONG registrant must fulfill certain name policy criteria. PIR will employ the following restrictions concerning the names that eligible .ONG registrants can register. As such a .ONG registrant cannot register any name they wish but is limited by the following restrictions. A .ONG registered domain name may be:
1) the name of (entire or portion of) the NGO, e.g. its “doing business as” name,
2) an acronym representing the NGO,
3) a name that recognizes or generally describes the NGO, or
4) a name related to the mission or activities of the NGO.
Reserved Name Policy: The following names⁄types of domain names will initially be reserved from registration:
• All single- and two-character second-level domain names;
• Domains of an inappropriate nature, e.g., adult-related terminology, pursuant to a list defined by PIR and its NGO Community Advisory Council;
• Names provided by ICANN as required reserved names;
• A list of generic names defined by PIR and its NGO Community Advisory Council based on the overall criteria that the names represent the NGO Community in a general manner. Such names will be released in a specific RFP process ensuring that the names will benefit the NGO Community.
Registry Name Policy: The following names⁄types of domain names will be held from general availability; they will be used in support of the registry.
• Names to support registry operations, e.g., directory.ONG;
• Names to support PIR’s NGO Community Advisory Council.
Compliance and Enforcement Mechanisms
PIR will take both proactive and reactive measures to enforce the policies of the gTLD. Proactive measures are taken at the time of registration by requiring .ONG registrants to meet the .ONG Registration Policies and to agree to all policies and procedures of the gTLD. Reactive measures are addressed via our audit process and through our defined dispute resolution processes.
A violation of the .ONG Registration Policies will be enforced on a case-by-case, fact specific basis under the processes set forth below:
1. Any allegation that a domain name is not used primarily for NGO purposes shall be enforced under the provisions of the Restrictions Dispute Resolution Policy (ʺRDRPʺ) as described in Evaluation Question #28. The RDRP will be included as an appendix to the Registry Agreement. An appeal procedure is included in the RDRP.
2. Any alleged violation of the Rights Protection Mechanisms shall be enforced under the provisions contained in each of them.
Disputes resulting from violations of the .ONG Registration Policies will be resolved through the Compliance Functions and the Rights Protection Mechanisms. The Rights Protection Mechanisms (as detailed in Evaluation Question #29) will be made applicable by the ICANN-Accredited Registrarsʹ registration agreements with registrants. Proceedings under the Rights Protection Mechanisms will be conducted in accordance with the policies and procedures that will be included in an appendix to the Registry Agreement. As set forth in the Compliance Functions, the registry operator will review on a random basis, monitor, and verify that any particular domain name is being used primarily for NGO purposes and that a domain is being used in compliance with the Rights Protection Mechanisms processes.
Resource Plans
PIR will devote 1 compliance officer to handle compliance and disputes as they arise, although currently for .ORG this need is rare. Most compliance checks on registration eligibility are expected to be handled in an automated process. 

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.

The Public Interest Registry (PIR) 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 .ONG gTLD, as per the requirements in the new gTLD 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’s (GAC) advice on “Principles regarding new gTLDs”, these domains will be blocked, at no cost to governments, public authorities, or Intergovernmental Organizations (IGOs), before the .ONG gTLD 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 .ORG gTLD. 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 names, with an ICANN accredited 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 PIR reaches agreement with the applicable government(s). We will work with respective GAC representatives of the country’s relevant Ministry of Department to obtain their release of the names to PIR.

If Internationalized Domains Names (IDNs) are introduced in the .ONG gTLD 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 as to 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 IGO’s 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, PIR 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.

Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, any modifications required with the introduction of any new ICANN policies, and addressing any potential security or stability concerns.

The below response includes a description of the registry services to be provided for the .ONG gTLD, additional services provided to support registry operations, and an overview of the approach.

1. Operations of the Registry
To support the .ONG gTLD, PIR and Afilias will offer the following registry services, all in accordance with relevant technical standards and policies:

a. 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 Evaluation Questions #24, #25, and #27 for full details.

b. Operation of the registry DNS servers: The DNS system, run and managed by Afilias, is a massively provisioned 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 Evaluation Question #35 for full details.

c. 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 Evaluation Question #34 for full details.

d. 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 Evaluation Question #26 for full details.

e. Internationalized Domain Names (IDNs): Ability to support all protocol valid Unicode characters at every level of the gTLD, including alphabetic, ideographic and right-to-left scripts in conformance with the ICANN IDN Guidelines. Please see our response to Evaluation Question #44 for full details.

f. 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 Evaluation Question #43 for full details.

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

2. Support
Numerous supporting services and functions facilitate effective management of the .ONG gTLD. These support services include:

a. Customer support: 24x7 live phone and email 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.

b. Financial services: billing and account reconciliation for all registry services according to pricing established in respective agreements.

c. Support necessary to address the consensus policies as adopted by ICANN including:

• Uniform Domain Name Dispute Resolution
• WHOIS Data Reminder
• Inter-Registrar Transfer Policy
• WHOIS Marketing Restriction Policy
• Restored Names Accuracy Policy
• Expired Domain Deletion Policy
• Registry Services Evaluation Policy
• AGP Limits Policy

3. Other Services
Reporting is an important component of supporting registry operations. Afilias will provide reporting to the registry operator and registrars, as well as financial reporting. Afilias provides an extensive suite of reports to the registry operator, including daily, weekly and monthly reports with data at the transaction level that enables 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 PIR 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 their 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 Shared Registry System (SRS), b) daily email 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).

There are no additional proposed registry services for the launch of the .ONG gTLD.

4. Security and Stability
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 Evaluation Question #30b; please see that response for complete information. In short, Afilias is committed to ensuring the confidentiality, integrity, and availability of all information.

PIR and Afilias will deliver a secure, stable and reliable registry service. The .ONG gTLD 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;
• 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;
• 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.

PIR with Afilias will support the .ONG gTLD in accordance with its specific policies and procedures leveraging a proven registry infrastructure that is fully operational, staffed with professionals, massively provisioned, and immediately ready to launch and maintain this gTLD.

About PIR’s Support
Public Interest Registry (PIR), the official manager of .ORG, employs a team of professionals in operations, legal, marketing, and finance who manage the planning activities and oversight of Afiliasʹ technical operations activities.

PIR’s express purpose is supporting and promoting the evolution and growth of the Internet as a global research and communications infrastructure, educating non-commercial, NGO, and the nonprofit community about how to more effectively and more efficiently utilize the Internet to accomplish their important missions. PIR’s primary activity is to maintain an exemplary gTLD registry service, including advocating for higher standards of Internet security, safety and reliability.

In its relationship with the Internet Society (reference Evaluation Questions #9a and #9b), PIR is committed to supporting the goals of encouraging the evolution of the Internet as research, education and communication infrastructure equally accessible to the global non-commercial, NGO and nonprofit community. PIR’s activities also include funding educational programs focused on expanding the knowledge and ability of non-commercial, NGO and nonprofit organizations located in technologically deprived areas of the world to more efficiently and effectively use the Internet as a tool to better accomplish their important missions.

About Afilias’ Approach to Registry Support
Afilias, the backend registry service provider for the .ONG gTLD, is dedicated to managing the technical operations and support of the .ONG gTLD in a secure, stable and reliable manner. Afilias has worked closely with the Public Interest Registry (PIR) to review specific needs and objectives of the .ONG gTLD. The resulting comprehensive plans are illustrated in technical responses to Evaluation Questions #24-44, drafted by Afilias given PIR’s requirements. Afilias and PIR also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of the .ONG gTLD.

Afilias is the registry services provider for this and several other TLD applications. Over the past 11 years of providing services for gTLDs 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 has 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 ongoing maintenance of the .ONG gTLD. 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 its staff in a focused way.

With over a decade of registry experience, Afilias has the depth and breadth of experience to 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, where Afilias worked with 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, in 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 managing 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 a linear increase in resources. Afilias carefully tracks the relationship between resources deployed and domains to be serviced, and proactively 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

THE RESPONSE FOR THIS QUESTION INCLUDES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN STATED IN 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, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.

Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, any modifications required with the introduction of any new ICANN policies, and the operation of a robust Shared Registration System (SRS).

Afilias operates a state-of-the-art EPP-based 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 .ONG gTLD; and,
• Manages the SRS with a team of experienced technical professionals who can seamlessly integrate the .ONG gTLD into the Afilias registry platform and support the gTLD 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 .ORG registry, as well as the fifteen 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.

An abbreviated list of Afilias SRS functionality includes the list below. EPP functionality is described fully in our response to Evaluation Question #25.
• Domain registration: provides registration of names in the gTLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
• Domain renewal: 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: 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: provides support for the Redemption Grace Period (RGP) as needed, enabling the restoration of deleted registrations.
• Other grace periods and conformance with ICANN guidelines: provides support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the Afilias registry backend services system supports the evolving ICANN guidelines on IDNs.

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

As required for all new gTLDs, “thick” registry system functionality is provided. 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 the gTLD’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 in 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 Evaluation Questions #31 and #32.

SRS Servers and Software
All applications and databases for the gTLD 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 that 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 Evaluation 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 Evaluation 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 Evaluation 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 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 gTLD registry with a strong performance history, Afilias, on behalf of PIR, 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 the .ONG gTLD 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 the gTLD in a secure, stable and reliable manner.

SRS Resourcing Plans
Since its founding, Afilias has 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 ongoing maintenance of the .ONG gTLD. 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 its staff in a focused way.

Over 100 Afilias team members contribute to the management of the SRS code and network that will support the .ONG gTLD. 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 the .ONG gTLD 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 .ONG gTLD.

25. Extensible Provisioning Protocol (EPP)

THE RESPONSE FOR THIS QUESTION INCLUDES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN STATED IN 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, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.


Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, any modifications required with the introduction of any new ICANN policies, and the operation of a state-of-the art Extensible Provisioning Protocol (EPP) Shared Registration System (SRS).

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 the .ONG gTLD 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 TLDs and will meet the .ONG gTLD’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 TLDs 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)

The .ONG gTLD will support all valid EPP commands. The EPP commands discussed below are in operation today and will be made available for the .ONG gTLD. See attachment #25-a 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 #25-b, 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 .ONG gTLD.

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”, “LICENSEE”, 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 has 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 ongoing maintenance of the .ONG gTLD. 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 its 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

Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has had experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, all standard grace periods, can address any modifications required with the introduction of any new ICANN policies, and the operation of the registry WHOIS service.

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 .ONG gTLD that meets the needs of constituents of the domain name industry and Internet users. The service has been tested by our Quality Assurance (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.

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, email address, and telephone and fax numbers of the domain name holder;
• The name, postal address, email address, and telephone and fax numbers of the technical contact for the domain name holder;
• The name, postal address, email address, and telephone and fax numbers of the administrative contact for the domain name holder; and,
• The name, postal address, email 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 .ONG gTLD.

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”, “LICENSEE”, 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 .ONG gTLD 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 the .ONG gTLD 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 .ONG gTLD 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 the .ONG gTLD. 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. They are also active participants in both technical and policy decision making in ICANN, aimed at restricting abusive behavior.

WHOIS Staff Resourcing Plans
Since its founding, Afilias has 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 ongoing maintenance of the .ONG gTLD. 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 its 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 ongoing maintenance of the new .ONG gTLD WHOIS service.

27. Registration Life Cycle

THE RESPONSE BELOW INCLUDES ANGLE BRACKETS (ʺ〈ʺ AND ʺ〉ʺ), AND MAY NOT PROPERLY RENDER. PER CASE ID 11027, PLEASE SEE ATTACHED FOR FULL RESPONSE.

Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has 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.

.ONG will follow the ICANN standard domain lifecycle, similar to other gTLDs, such as .ORG. There are four main phases in the lifecycle of a .ONG domain name. These include: 1) the Registration period, 2) the Auto-renew grace period, 3) the Redemption grace period, and 4) the Pending delete period. An additional two-step verification process is required within the registration period to verify that the registrant is a bona fide member of the NGO Community. The response below includes a description of a domain lifecycle, including domain creation, transfer protocols, grace period implementation, and the respective time frames for each, as well as, a summary of the resources needed to support them. All .ONG domains are subject to the policies defined in Evaluation Questions #20e and #29.

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

1. Registration Period
After the IP protection program and the general launch, eligible registrants may choose to register a .ONG domain name through an ICANN accredited registrar. The registrar will check availability on the requested domain name and if available, will collect required contact and host (nameserver) information and provision this information into the registry system using standard Extensible Provisioning Protocol (EPP) commands through a secure connection to the registry backend service provider.

During the registration process (see figure 27-b), the registrant will be asked to verify their eligibility and to demonstrate affiliation with a NGO member organization. Once the initial certification in step 1 of the verification process is confirmed, the domain is successfully created. If the NGO registrant fails to provide any additional required information through step 2 of the verification process, the domain will be deleted and released back into the pool of available domains. See Evaluation Question #20e for detail on eligibility requirements.

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.

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.
• 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.
• 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.
• 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 Shared Registration System (SRS).

Other specifics regarding registration rules for a .ONG 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 .ONG 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 SRS. The following rules apply:
i. A domain can be deleted at any time during its registration term,
ii. If the domain is deleted during the Add Grace Period or the Renew⁄Extend Grace Period, the sponsoring registrar will receive a credit,
iii. 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: PIR, through 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.
PIR will support ICANN’s Transfer Dispute Resolution Process. PIR will work with Afilias to respond to Requests for Enforcement (law enforcement or court orders) and will follow that process.

2. 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.

3. 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 Server Renew Prohibited, Server Delete Prohibited, Server Update Prohibited, Server Update Prohibited, and then OK once a restore report is received from the registrar of record. 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.

4. 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) described above, 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.

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.

Overlapping Grace Periods
If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below).

If a domain is deleted within the Add Grace Period and the Renew⁄Extend Grace Period, then the registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done. The domain is removed from the registry database and is immediately available for registration by any registrar.

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 (that is, to the status: PENDING DELETE RESTORABLE).

Overlap Exceptions
If a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring registrar is credited for the transfer amount. For example, if a domain is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first and second transfers, then only the last transfer is credited to Registrar C.

If a domain registration is extended within the Transfer Grace Period, then the current registrarʹs account is charged for the number of years the registration is extended.

Resource Plans
PIR will devote resources to support the registrar onboarding and sign-up process, marketing campaigns, the domain registration lifecycle, and any dispute resolution processes necessary, similar to its current role in maintaining the .ORG domain. The registry operator anticipates having 1 compliance officer to handle disputes as they arise, although currently for .ORG this need is rare.

Since its founding, Afilias has 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 ongoing maintenance of the .ONG gTLD. 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 project management methodology allows efficient and effective use of staff to focus on all aspects of the registration lifecycle.

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

The Public Interest Registry (PIR), working with Afilias Limited, the registry backend service provider, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit abusive registrations, remove outdated and inaccurate data, and other security measures to ensure the integrity of the gTLD. The specific measures include, but are not limited to:
• Posting a gTLD Anti-Abuse Policy that clearly defines abuse, and provides 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;
• Introducing community related policies to ensure eligibility requirements, name selection, and content and use policies; 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 PIR through the Registry-Registrar Agreement, and the obligations will be passed onto and made binding with registrants. This policy will be posted on the gTLD website along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. PIR 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 Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension procedure (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity, not to burden law-abiding or innocent registrants and domain users.

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

The Anti-Abuse Policy described below is a recent version of the policy that has been used by the .ORG registry since 2009 and will be effective upon launch of the .ONG gTLD. It has proven to be an effective and flexible tool.

Anti-Abuse Policy:
Abusive use(s) of .ONG 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’s 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 websites 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 websites 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, PIR 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 a domain a registry lock, hold, or similar status 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
PIR will establish an abuse point of contact. This contact will be a role-based email address from the registry operator. This email 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, there will be 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, email service providers, and registrars for many years, and is considered a global best practice.

PIR’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, PIR may find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, ordinary 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. PIR will review all evidence before taking any action on complaints.

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. 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 registration, such as the payment method used (credit card, PayPal, etc.);
• The identity of a proxy-protected registrant;
• The registrant’s IP address;
• Whether there is a reseller involved; and,
• The registrant’s past sales history and registrations 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 PIR’s Anti-Abuse Policy.

If a registrar does not take action within an established time period indicated by the registry operator – usually 24 hours, PIR may then decide to take action itself. At all times, PIR 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.

PIR is 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 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, PIR will review them and 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. A goal is set to respond to such requests within 24 hours.

PIR and Afilias may also engage in proactive screening of its zone for malicious use of the domains in the gTLD, and report problems to the sponsoring registrars. Combinations of the following additional resources are available, 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.
• Analyses of registration or DNS query data (DNS query data received by the gTLD nameservers.)

PIR will keep records and track metrics regarding abuse and abuse reports. These may 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 gTLD that have been blacklisted by major anti-spam blocklist providers; and,
• Phishing site uptimes in the gTLD.

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 Server Hold or Client Hold 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.

PIR and Afilias observe 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 Evaluation Question #26, (WHOIS), the registry operator will manage a secure, robust and searchable WHOIS service for this gTLD.

WHOIS Data Accuracy:
PIR 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 gTLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy that are mandatory, are documented as such, and must be submitted by registrars. The registry backend service provider’s system verifies formats for relevant individual data fields (e.g. email, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166-1 code list. The 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 .ONG gTLD, 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.

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 PIR 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 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 Registry Registrar Agreement (RRA), PIR 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 registry backend service provider’s system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of authorization 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 authorization code. The authorization code is a six- 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 authorization 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 Evaluation Question #30b.

Registry Actions
PIR reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion, to protect the integrity and stability of the registry, to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process, or to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors and employees. PIR reserves the right to freeze a domain name during resolution of a dispute. PIR reserves the right to terminate a domain at any time for failure by the registrant to demonstrate it meets eligibility criteria and⁄or failure to comply with the .ONG Registration Restrictions Policies.

Restrictions Dispute Resolution Policy:
As an additional means to cure malicious and abusive behavior, PIR will have a Restrictions Dispute Resolution Policy and process as first described in response to Evaluation Question 18b. All .ONG Registrants will be bound by the Restrictions Dispute Resolution Policy. This policy may be invoked by any third party NGO or governmental organization (including law enforcement authorities) in order to resolve a dispute with a registrant over the registration or use of the registrantʹs domain name in violation of the .ONG Registration Restrictions. Such a dispute filing must specify how the domain name is in violation of the purposes contemplated by the definition and qualifications of an NGO.

The following are the terms of the Restrictions Dispute Resolution Policy that will be available at launch.
1. Purpose. This Restrictions Dispute Resolution Policy (the ʺRDRPʺ) is incorporated by reference into your .ONG Registration Agreement. It sets out the terms and conditions that will apply in the event of a dispute between you (as the registrant) and a third party other than us (as the Registrar) or the Registry administrator for the .ONG top-level domain over the registration or use of your domain name in violation of the .ONG Registration Restrictions. Proceedings under Paragraph 4 of the RDRP will be conducted according to the Supplemental Rules for Restrictions Dispute Resolution Policy (the ʺSupplemental RDRP Rulesʺ), which are available below, and the selected administrative dispute resolution service providerʹs supplemental rules.
2. Your Representations. By applying to register a domain name, or by asking us to maintain or renew a domain name registration, you hereby represent and warrant to us that (a) the statements that you made in your Registration Agreement are complete and accurate; (b) to your knowledge, the registration of the domain name will not infringe upon or otherwise violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; (d) you will not knowingly use the domain name in violation of any applicable laws or regulations; (e) your domain name registration does not and will not violate the terms and conditions of the .ONG Registration Restrictions. It is your responsibility to determine whether your domain name registration infringes or violates someone elseʹs rights. It is also your responsibility to determine whether your domain name registration violates the .ONG Registration Restrictions.
3. Cancellations, Transfers and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following circumstances:
• subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action;
• our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and⁄or
• our receipt of a decision of an Administrative Panel(or of an Appeal Panel, if there is an appeal) requiring such action in any administrative proceeding to which you were a party and which was conducted under the RDRP or a later version of the RDRP adopted by ICANN.
We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your .ONG Registration Agreement, ICANN policy, or other legal requirements.
4. Mandatory Administrative Proceeding.
This Paragraph sets forth the type of disputes for which you are required to submit to a mandatory administrative proceeding. These proceedings will be conducted before one of the administrative dispute resolution service providers listed at www.icann.org⁄udrp⁄approved-providers.htm (each, a ʺProviderʺ).
a. Applicable Disputes. In addition to the grounds set out in Paragraph 4(a) of the Uniform Domain Name Dispute Resolution Policy (“UDRP”), you will also be required to submit to a mandatory administrative proceeding in the event that a complainant asserts to a Provider that your domain is not being or will not be used primarily for a bona fide NGO purpose. In the administrative proceeding, the complainant will bear the burden of proving that each of the above elements is present. A complaint under the RDRP will not be considered valid if based exclusively on the alleged non-use of your domain name.
b. Bona Fide NGO Use. ʺBona fide NGO useʺ shall mean the bona fide use or bona fide intent to use the domain name or any content software, materials, graphics or other information thereon, in accordance with the purposes contemplated by the definition and qualifications of an NGO.
c. Selection of Provider. The complainant shall select the Provider from among those approved by ICANN by submitting the complaint to that Provider. The selected Provider will administer the proceeding, except in cases of consolidation as described in Paragraph 5.
d. Initiation of Proceeding and Process and Appointment of Administrative Panel. The Supplemental RDRP Rules state the process for initiating and conducting a proceeding and for appointing the panel that will decide the dispute (the ʺAdministrative Panelʺ).
e. Consolidation. In the event of multiple disputes between you and a complainant, either you or the complainant may petition to consolidate the disputes before a single Administrative Panel. This petition shall be made to the first Administrative Panel appointed to hear a pending dispute between the parties. This Administrative Panel may consolidate before it any or all such disputes in its sole discretion, provided that the disputes being consolidated are governed by the RDRP or another dispute resolution policy adopted by ICANN.
f. Fees. All fees charged by a Provider in connection with any dispute before an Administrative Panel pursuant to the RDRP shall be paid by the complainant, except in cases where you elect to expand the Administrative Panel from one to three panelists as provided in the Supplemental RDRP Rules, in which case all fees will be split evenly by you and the complainant.
g. Our Involvement in Administrative Proceedings. We do not, and will not, participate in the administration or conduct of any proceeding before an Administrative Panel. In addition, we will not be liable as a result of any decisions rendered by the Administrative Panel.
h. Remedies. The remedies available to a complainant pursuant to any proceeding before an Administrative Panel shall be limited to requiring the cancellation of your domain name or the transfer of your domain name registration to the complainant.
i. Notification and Publication. The Provider shall notify us of any decision made by an Administrative Panel with respect to a domain name you have registered with us. All decisions under the RDRP will be published in full over the Internet, except when an Administrative Panel determines in an exceptional case to redact portions of its decision.
j. Availability of Court Proceedings. The mandatory administrative proceeding requirements set forth in Paragraph 4 shall not prevent either you or the complainant from submitting the dispute to a court of competent jurisdiction for independent resolution before such mandatory administrative proceeding is commenced or after such proceeding is concluded. If an Administrative Panel decides that your domain name registration should be canceled or transferred, we will wait ten (10) business days (as observed in the location of our principal office) after we are informed by the applicable Provider of the Administrative Panelʹs decision before implementing that decision. We will then implement the decision unless we have received from you during that ten (10) business day period official documentation (such as a copy of a complaint, file-stamped by the clerk of the court) that you have commenced a lawsuit against the complainant in a jurisdiction to which the complainant has submitted under the Supplemental RDRP Rules. (In general, that jurisdiction is either the location of our principal office or of your address as shown in our WHOIS database.) If we receive such documentation within the ten (10) business day period, we will not implement the Administrative Panelʹs decision, and we will take no further action, until we receive (i) evidence satisfactory to us of a resolution between the parties; (ii) evidence satisfactory to us that your lawsuit has been dismissed or withdrawn; or (iii) a copy of an order from such court dismissing your lawsuit or ordering that you do not have the right to continue to use your domain name.
k. Appeal.
(i) Either party shall have a right to seek a de novo appeal of the Administrative Panel’s decision based on the existing record within the RDRP proceeding for a reasonable fee to cover the costs of the appeal.
(ii) An appeal must be filed with the Provider and served on all parties within 20 days after an Administrative Panel’s decision is issued, and a response to the appeal must be filed within 20 days after the appeal. Manner and calculation of service deadlines shall be those specified by the Supplemental Rules of the RDRP.
(iii) A three-member Appeal Panel is to be selected by the Provider, but no member of the Appeal Panel shall also have been an Administrative Panel member.
(iv) The fees for an appeal in the first instance shall be borne by the appellant.
(v) A limited right to introduce new admissible evidence that is material to the decision will be allowed upon payment of an additional fee, provided the evidence clearly pre-dates the filing of the RDRP complaint.
(vi) The Appeal Panel may request, at its sole discretion, further statements or evidence from any party regardless of whether the evidence pre-dates the filing of the RDRP complaint if the Appeal Panel determines such evidence is relevant.
(vii) The prevailing party shall be entitled to an award of costs of appeal.
(viii) The Provider’s rules and procedures for appeals, other than those stated above, shall apply.
5. All Other Disputes and Litigation. All other disputes between you and any party other than us regarding your domain name registration that are not brought pursuant to the mandatory administrative proceeding provisions of Paragraph 4 shall be resolved between you and such other party through any court, arbitration or other proceeding that may be available.
6. Our Involvement in Disputes. We will not participate in any way in any dispute between you and any party other than us regarding the registration and use of your domain name. You shall not name us as a party or otherwise include us in any such proceeding. In the event that we are named as a party in any such proceeding, we reserve the right to raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves.
7. Maintaining the Status Quo. We will not cancel, transfer, activate, deactivate, or otherwise change the status of any domain name registration under the RDRP except as provided in Paragraph 3 above.
8. Transfers During a Dispute.
(a) Transfers of a Domain Name to a New Holder. You may not transfer your domain name registration to another holder (i) during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded; or (ii) during a pending court proceeding or arbitration commenced regarding your domain name unless the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision of the court or arbitrator. We reserve the right to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph.
(b) Changing Registrars. You may not transfer your domain name registration to another Registrar during a pending administrative proceeding brought pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded. You may transfer administration of your domain name registration to another Registrar during a pending court action or arbitration, provided that the domain name you have registered with us shall continue to be subject to the proceedings commenced against you in accordance with the terms of the RDRP. In the event that you transfer a domain name registration to us during the pendency of a court action or arbitration, such dispute shall remain subject to the domain name dispute policy of the Registrar from which the domain name registration was transferred.
9. Policy Modifications. We reserve the right to modify the RDRP at any time with the permission of ICANN. We will post the revised RDRP on the gTLD website at least thirty (30) calendar days before it becomes effective. Unless this version of the RDRP has already been invoked by the submission of a complaint to a Provider, in which event the version of the RDRP in effect at the time it was invoked will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name registration dispute, whether the dispute arose before, on or after the effective date of our change. In the event that you object to a change in this version of the RDRP, your sole remedy is to cancel your domain name registration with us, provided that you will not be entitled to a refund of any fees you paid to us. The revised RDRP will apply to you until you cancel your domain name registration.

Supplemental Rules for Restrictions Dispute Resolution Policy
The following represent supplemental rules for dispute resolution:
1. Purpose. Administrative proceedings for the resolution of disputes under the Restrictions Dispute Resolution Policy (ʺRDRPʺ); shall be governed by the Rules for Uniform Domain Name Dispute Resolution Policy (ʺUDRP Rulesʺ; www.icann.org⁄udrp⁄udrp-rules-24oct99.htm) as supplemented or modified by these Supplemental Rules for Restrictions Dispute Resolution Policy (the ʺSupplemental RDRP Rulesʺ) and any supplemental rules of the dispute resolution service provider administering the proceedings.
2. Definitions. Defined terms in the UDRP Rules shall have the same meaning in these Supplemental RDRP Rules, subject to the following:
i. Complaint based on UDRP and RDRP. If a complaint is based on the UDRP and the RDRP, the term ʺPolicyʺ shall refer to the Uniform Domain Name Dispute Resolution Policy (ʺUDRPʺ) and the RDRP, and the term ʺRulesʺ shall refer to the UDRP Rules as supplemented or modified by these Supplemental RDRP Rules.
ii. Complaint based on the RDRP alone. If a complaint is based on the RDRP alone, the term ʺPolicyʺ shall refer to the RDRP, and the term ʺRulesʺ shall refer to the UDRP Rules as supplemented or modified by these Supplemental RDRP Rules.

RDRP Grounds. A complaint pursuant to the RDRP (whether or not also based on the UDRP) shall describe, in accordance with Paragraph 4(a)-(c), the grounds on which the complaint is made including, in particular, the extent to which the domain name is not being or will not be used primarily for a bona fide NGO purpose.

Afilias Limited, the registry backend service provider, 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.

Validation and Abuse Mitigation Mechanisms:
The registry backend service provider 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 by the domain anti-abuse team members. Once analyzed and confirmed, 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 contacts. These verified contacts are given a unique code which can be used for registration of new domains.

Registrant 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: U.S. 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; as an example: 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 the requirements or specific criteria developed by PIR.
• Based on required WHOIS Data; registrant contact details (name, address, phone).
• If address⁄ZIP can be validated by VAULT, the validation process can continue (N. 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 has 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 ongoing 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 its 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.

PIR and Afilias will maintain resources to:
1. Evaluate incoming reports to the abuse point of contact, and either act upon them or refer them to registrars as per the above-described procedures.
2. Evaluate incoming reports from other sources and either act upon them or refer them to registrars as per the above-described procedures.
3. If these validation and abuse mitigation mechanisms are used, then Afilias will maintain resources to analyze the registry and gTLD DNS zone activity for malicious and suspicious activity and either act upon them or refer them to registrars as per the above-described procedures.

The .ONG gTLD’s anticipated volume of registrations in the first three years of operations is listed in response to Evaluation Question #46. PIR’s and Afilias’ anti-abuse function anticipates the expected volume and type of registrations, and together will adequately cover the staffing needs for the .ONG gTLD. PIR 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 gTLD. The team structure planned for the .ONG gTLD is based on several years of experience responding to, mitigating, and managing abuse for gTLDs 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 gTLD. 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, PIR 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 the .ONG gTLD 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.

29. Rights Protection Mechanisms

Rights protection is a core responsibility of the gTLD registry operator, and is supported by a well-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 RRDRP;
• 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 gTLD.

The response below details the Rights Protection Mechanisms at the launch of the gTLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, RRDRP, 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 gTLD
The launch of this gTLD 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. The registry operator will recognize and honor all word marks that have been or are: (i) nationally or regionally registered; (ii) court validated; or (iii) specifically protected by a statute or treaty in effect at the time the mark is submitted to the Clearinghouse for inclusion. No demonstration of use will be required.

Sunrise Intellectual Property Protection
PIR has employed the following concerning protection of intellectual property.

The Sunrise policy will be in effect during the Sunrise pre-registration period where NGO eligible intellectual property holders will get a first chance to register their .ONG domain name. In order to complete an .ONG domain name registration during the Sunrise pre-registration period, a registrant must fulfill the .ONG Registration Policies defined in Evaluation Question #20e, and Sunrise requirements set forth below.

PIR will implement the Trademark Clearinghouse (TMCH) guidelines and rules when available. Names provided to PIR via the TMCH that also are names that eligible NGO Community members are requesting, will proceed to be registered to the eligible NGO.

Following the end of the Sunrise Period, names that are not otherwise reserved will be available. Disputes concerning results from the Sunrise can be raised in the Sunrise Dispute Resolution Policy (SDRP) defined below.

The Sunrise Period will be an exclusive period of time prior to the opening of general registration, when trademark and service mark holders will be able to reserve marks that are an identical match to the .ONG domain. Following the Sunrise Period, Quiet Period, and Landrush Period, PIR will open registration to qualified applicants.

The anticipated rollout schedule for the .ONG gTLD will be approximately as follows:
- Sunrise Period of 60 days begins for trademark holders and service mark holders to submit registrations for their exact marks in the .ONG domain. Following this, PIR expects the balance of Sunrise registrations to be awarded in real-time.
- Quiet Period of 30 days begins at the close of Sunrise.
- Landrush Period of 30 days opens after the Quiet Period.
- Quiet Period of 30 days begins at the close of Landrush.
- General Registration (for qualified applicants) begins after the Quiet Period.

Sunrise Period Requirements & Restrictions:
- Those wishing to reserve their marks in the .ONG domain during the Sunrise Period must be the current trademark or service mark owner that meets the criteria set forth in Section 7.2 of the Trademark Clearinghouse specifications, whether or not actually listed in the Clearinghouse. With respect to trademark holders in the Clearinghouse, notice must be provided to all trademark holders if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the TMCH that are an identical match (as defined in the Trademark Clearinghouse) to the name to be registered during Sunrise.
- Each Sunrise registration will require a minimum term of five years.
- PIR will establish the following Sunrise Eligibility Requirements (SERs) as minimum requirements, verified by TMCH 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 Clearinghouse 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 the time that 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 new gTLD 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 the .ONG gTLD. As described in our responses to Evaluation Questions #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and the registry operator will have staff available to respond to legal actions such as court orders.

The .ONG gTLD will conform to all ICANN RPMs including Uniform Rapid Suspension (URS, discussed below), UDRP, and all measures defined in Specification 7 of the new gTLD Registry Agreement.

Uniform Rapid Suspension (URS): The registry operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy included the Applicant Guidebook, 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 can remain in the TLD DNS zone file and can thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
- Server Update Prohibited, with an EPP reason code of “URS”
- Server Delete Prohibited, with an EPP reason code of “URS”
- Server Transfer Prohibited, 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 a 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 website. 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 Considerations:
As described in response to Evaluation Question #20e, PIR has developed Registrant Eligibility Requirements to ensure .ONG registrants are eligible members of the NGO Community. These eligibility requirements must be fulfilled in both the pre-launch Sunrise registration period where trademark holders are provided a first opportunity to register a .ONG domain name, and when .ONG is opened for the entire NGO Community through general registrations at which time the Abuse Prevention and Mitigation policies will apply.

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 gTLD 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 Evaluation Question #28, the registry operator has described its anti-abuse program designed to address phishing, pharming, malware, and other forms of abuse that may harm Internet users. This program is designed to actively discover, verify, and mitigate problems without infringing upon the rights of legitimate registrants. This program is designed for use in the general registration period and includes an optional system for monitoring the gTLD for phishing attacks and policies and procedures for verifying and mitigating phishing attacks. These procedures include the reporting of compromised websites⁄domains to registrars for cleanup by the registrants and their hosting providers, and rapid takedown procedures for maliciously registered phishing domains. Rather than repeating the policies and procedures here, please see our response in Section #28 for full details.

These procedures will sometimes allow the registry operator to identify the domain name portfolios of phishers, and suspend those portfolios before all of the domains in them are used. This will reduce damage to Internet users and the brands that such phishers target.

Every six months, the Anti-Phishing Working Group (APWG) publishes its latest Global Phishing Survey. (See http:⁄⁄www.apwg.org⁄resources.html#apwg.) Each edition of this study contains an analysis of how phishers construct phishing URLs and register domain names. The registry operator and the registry backend service provider will continue to track that report and ongoing trends. APWG studies show that in the first half of 2011, just two percent (2%) of the domain names used for phishing (or 12% of malicious phishing registrations) contained a targeted brand name or misspelling thereof. According to the APWG, in the year July 2010 through June 2011, there were only about 5,700 known brand-or-misspelling phishing domains registered in all TLDs worldwide.

The demonstrated phishing problem is therefore a tiny percentage of domain registrations overall, and should be balanced against the impact that filtering or denying incoming domain registrations in the open registration period may have upon other parties. The number of potential variations and misspellings of target brand names is very large, and attempts to deny registrations containing them might infringe upon the rights of other trademark holders. This variant or misspelling problem is one reason why ICANN specified that only exact domain name string matches will be addressed by the Trademark Clearinghouse. In addition, most generic words are trademarked, and trademarked terms may be found within larger words that would be legitimate for registrants to register.

For these reasons, the registry operator does not plan on heuristics based filtering or denying registrations as they come to the registry during the Landrush and general registration periods based on misspelling detection algorithms. Instead, PIR prefers an approach that addresses registered domain names (rather than potentially registered domains). Our planned approach will not infringe upon the rights of legitimate registrants to register domains, and allows the community-developed UDRP and URS policies and procedures to deal with complaints.

Afilias Limited, the registry backend service provider, is a member of various security fora which provide access to lists of name in each TLD which may be used for malicious purposes. Such identified names will be subject to the .ONG gTLD Anti-Abuse Policy including rapid suspensions after due process.

Rights Protection Resourcing Plans
Supporting Rights Protection Mechanisms (RPM) requires several departments within the registry operator as well as within Afilias, the registry backend service provider. The implementation of Sunrise and the Trademark Claims service and ongoing RPM activities will pull from the 102 Afilias staff members of the engineering, product management, development, security and policy teams as well as resources at the registry operator. No additional hardware or software resources are required to support this, as Afilias has fully-operational capabilities to manage abuse today.

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

Public Interest Registry (PIR) has been successfully managing .ORG, one of the internet’s original gTLDs, for over nine years. PIR uses Afilias Limited as the registry backend service provider who will also support .ONG. Afilias has experience managing registrations for over a decade and supports comprehensive registration lifecycle services including the registration states, any modifications required with the introduction of any new ICANN policies, as well as adherence to strict security policies.

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 Evaluation Question #30b.

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 Network Operations Centers (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 Evaluation Question #30b.

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. Twenty-four by seven (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 within the data center and outside the data center using both system-based and network-based testing tools. Operations staff also monitors 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 Evaluation Questions #30b 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
• 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 Evaluation Question #30b.

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 .ONG gTLD, they will be done so in a planned and deliberate manner.

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 24x7 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.

Security Resourcing Plans
Please refer to our response to Evaluation Question #30b for security resourcing plans.



© 2012 Internet Corporation For Assigned Names and Numbers.