ICANN New gTLD Application

The DotKids Foundation proposes the .kids gTLD as a domain dedicated to serving the global kids community. DotKids’ nature is community-based. As defined by Article 1 of United Nations Convention on the Rights of Child (http:⁄⁄www2.ohchr.org⁄english⁄law⁄crc.htm), there is a clear definition of children: they are every human under 18 years old. The DotKids Foundation will adopt the UNCRC as our guiding principle, therefore to run the domain name where we encourage children participation on Internet Governance discussion, and to promote a kids-friendly Internet space, as well as to provide support to the children community, especially to Kids-led initiatives and projects supporting kids’ best interests.

a) Adopt UNCRC as our guiding principle for operations

According to UNCRC Article 13, “the child shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or in print, in the form of art, or through any other media of the childʹs choice.”

Adopting the UNCRC, DotKids Foundation believes that children are entitled to the freedom to express opinions and to have a say in matters affecting their social, economic, religious, cultural and political life online. Based on the UNCRC, DotKids Foundation have the best interests of kids in mind in the promotion of the well being of children online and uphold children’s rights

b) Encourage children’s participation online

A core principle of the Internet governance discussion is in its multi-stakeholder model, where everyone can participate. Kids is one of the important stakeholders of the Internet world as Internet is becoming widely available to many people at their early stages of development. The inclusion of children in the building process is important, and that their participation indeed also makes the multi-stakeholder model of the Internet stronger. However, there is still not enough Internet Governance discussion that involves children as they require extra guidance, facilitation and also financial support. DotKids Foundation aim to contribute to addressing these needs.

As a not-for-profit organization, DotKids Foundation is dedicated to developing and operating the .kids TLD as an economically viable registry that not only provides a kids-friendly namespace for the Internet, but also have the capability to contribute funds to projects that support the training of children to participate in global Internet governance. Furthermore, as the Foundation and the .kids TLD grows, we hope to contribute more widely to projects enhancing the wellbeing of children, especially as related to their wellbeing online, but also their general welfare.

Beyond supporting kids’ participation in global Internet governance, DotKids Foundation itself will also act as a breeding ground for kids to be involved with the Internet Governance discussion process. We will incorporate children-led groups (such as Kids Dream in Hong Kong, Kid’s Link from Fiji, and the Children’s Committee from Cambodia) as part of its organizational structure and governance, as children advisory councillors. The DotKids Foundation believes that this process not only ensures that the voices of children are heard in all policy development processes, but will also contribute to nurturing children participation in Internet governance and other global policies in general.

c) Create a kids friendly internet space

Provide an Internet space with best interests of kids in mind

Create a movement where content providers would create websites for kids from kids’ perspective -
We have published books specially designed for kids. However, there are no websites that are specifically designed for kids’ from their angles. The DotKids foundation will develop guideline for content providers for reference.

Development of relevant guideline

Kids-friendly is not primarily about safety, but also the complexity of information, effectiveness and attractiveness of its presentation to kids. In order to be truly kids-friendly, the platform should be built from a child’s point of view but not merely an illustration from the adults. For example, today there is a lot of information online, but many articles, such as on Wikipedia, even though may be kids “safe”, may not be kids “friendly”. The language, presentation and flow are all important parts of making content kids-friendly.

“.kids”, as the specific domain dedicated to the kids community, will have a core mandate to advocate the production and publishing of more kids friendly content online. One of the goals of the .kids TLD would be to develop it as a domain of choice for kids friendly content, which in turn engages the interest of kids and hence the participation of kids globally to take part in contributing to the Internet world.

UNCRC encourages the development of appropriate guidelines

According to Article 17 of the UNCRC, it encourages the development of appropriate guidelines for the protection of the child from information and material injurious to his or her well-being, bearing in mind the provisions of articles 13 and 18. The DotKids Foundations develops a set of appropriate guidelines for the takedown mechanism and the protection system to protect the children from materials on the content of the internet that may harm and disturb kids.

All .kids registrants must adopt the guideline and the failure to adhere to the guidelines will be grounds for suspension of the domain. The mechanisms for suspension is further discussed in #20e. Registrants are also encouraged to produce content and services that are kids friendly and would enhance the browsing and user experience of kids.

Protection Scheme designed and maintained by children rights experts

Beyond the standard gTLD dispute resolution (UDRP) and suspension policies (URS) the “.kids” registry will develop and implement special dispute and rapid suspension policies as mechanisms to curb inappropriate content and services. Further details are included in #20e.

d) Support and Contribute to the Children Community

As a not-for-profit organisation, DotKids is committed to contribute to the children community including the support to children’s rights, children welfare and other children oriented initiatives. The .kids TLD aims to drive not only the social value but also to leverage the economic value that could be developed from this domain to contribute back to the children community and fund projects with kids’ best interest at heart.

The Foundation hopes to serve as a sustainable source of support to various children-related initiatives and organizations. This enables the community to have sufficient resources in advocating the rights of child, especially those from developing countries and the minority groups who are always in lack of support and resources.

The utmost mission of DotKids is to make the domain name self-sustainable, while able to serve our community and meet our goals.

A. Competition

.kids helps in promoting constructive competition in the use of TLDs by promoting of kids friendly content, which in turn advances constructive competition among content providers, including education and infotainment publishers to increase kids friendly content.

B. Consumer Trust

At the heart of the .kids TLD vision is the enhancement of consumer trust: to develop a trusted, secure and stable platform with kids’ best interests in mind. While DotKids does not believe in censorship, a core policy of the .kids TLD is a rapid suspension policy to mitigate against harmful materials for kids.

C. Consumer Choice

.kids provides a choice for registrants to associate with and lend their support to kids friendly content and services. Internet users, especially kids, can choose to browse to .kids websites for kids friendly content.

.kids with its community-based nature is believed to offer the below distinguished benefits to the registrant, Internet users and the Internet world as a whole:
• An enhanced consumer choice for registrants or other Internet users with a highly identifiable and measurable segment for differentiated or concentrated marketing at a heightened accessibility
• A better-tailored user experience for the targeted end-users through developing Content Guidelines for content providers as reference
• A specialized Internet space of higher trust and confidence level for both the end-users and the various related stakeholders

Area of Specialty
The kids community of children includes the segments as below:

1) Kids: Defined by the UNCRC convention, a child means every human being below the age of eighteen years unless under the law applicable to the child, majority is attained earlier

2) Charities, non-government organizations and government institutions that work on the well-being of children. This also includes the alliances that promotes causes that promote the well-being of children

3) Parents and educators: As a matter of fact, they constitute a large part of and have a huge impact on a child’s growth.

4) Educational institutions, organizations and operations that are primarily serving children

The resources at DotKids will be channeled towards meeting the demands and needs of these specific groups. We will also devote to create a movement where content providers would create websites for kids from kids’ perspective. DotKids will also devote resources to createrelevant guidelines for registrants and content providers to design kids-friendly content websites.

Service level
DotKids is committed to establish a trusted and extended kids-friendly space for children which enables them to acquire information online at ease. We will come from the perspective of children, each registrant will get access to the Guideline which we developed to facilitate
registrants in maintaining their website. This also helps registrants to effectively communicate to their target group. On top of that, resources generated from the domain registration will contribute back to the kids community so as to further support their development and participation.

To ensure the content is not harmful to children, we have the Protection Scheme in place designed and maintained by children right experts. In adhering to Article 13 where it states children have the freedom to acquire knowledge; we do not intend to censor any information. In view of the special needs of kids, the Protection Mechanism will be in place. We have designed an online portal where it allows children experts from around the globe to vote on whether the content is harmful to kids when any Internet user reports any cases. Moreover, they are handled immediately with serious offences of the content guideline. Any Internet users can report a violation of the Content Guidelines. Details of the Protection Mechanism will be outlined in 20e.

Reputation as Kids’ Best Interest Domain
We aim to be recognized as a domain that is the ultimate destination for kids browsing online, in terms of relevance of content and user-friendliness. DotKids will become the primary choice of gTLD for kids-related businesses or content; and the cornerstone in supporting children-centric initiatives and Internet development.

ANTICIPATED BENEFITS TO THE CURRENT SPACE

Improved Competition

As the first TLD specifically serving the children community, the establishment of .kids domain will provide an alternative consumer choice and thereby allowing registrants to choose a name that best fits their need and to best reach their target group online. To be a gTLD available globally, it must promote a constructive competition in the domain industry.

Differentiation and Innovation

DotKids is designated as an online space for kids, whereby it would set apart other domain name spaces regarding the relevance of the content for kids, and how the content are produced with kids’ best interest in mind. Moreover, with the Protection Scheme in place maintained by other children right experts, we can ensure the information within the DotKids domain is not harmful to children. This provides a significant differentiation to other TLDs.

Moreover, DotKids is set up as a not-for-profit organization, and revenue from selling the domain names will channel back to community projects for children, especially those related to Internet governance discussion. DotKids would also be a ground for training children on Internet Governance discussion, by including them into our Advisory Board whereby we include their voices in the operations of our domain. This sets us apart from other profit making community based gTLD, which does not channel resources on the betterment of this underprivileged sector.

Improving User Experience

We have primarily divided our intended users into 2 segments, the primary user being the registrant, and secondary user are the Internet users accessing the domain.

The primary reason of registering a domain name is to establish an online presence, whereby it would help the registrants on various aspects, including enhanced visibility, promotion of their brand and eventually to improve their business operations. In clearly defining our community, it is much easier to reach to the target group (our community) for using DotKids domain, instead of using other TLD. Better search results, together with easier reach to their target group provide registrants clear benefits as to why register a DotKids domain instead of other gTLDs.

Regarding the Internet users who would access the domain, our published Guidelines would help registrants to create more relevant content to our community, whereby our community has the trust in our Protection Scheme that children right experts are looking after their needs in not reaching to harmful content for the community.

These policies and design in place help differentiate our positioning, and also to create a better experience both for the primary and secondary users of the TLD.

INTENDED REGISTRATION POLICIES

Our gTLD will operate as a community TLD, whereby we would put the needs of our community as our priority. Although much of the policies are not operated till after the user registered, including the Board governance structure of including kids in the discussion picture (please refer to 20b), Protection Scheme (please refer to 20e) and development of the Guidelines (please refer to 20e), the registration policy also reflect the design of the best interest domain for kids.

Eligibility for a .kids domain name in the initial stage is limited to children centric organizations, initiatives around the world, i.e., Non-governmental organization (NGO), children’s product manufacturers, suppliers, importers and crafters. It must own a registered trademark and authenticated as a legitimate service in the industry.

The second stage is for trademark protection. Applicants should provide a proof of ownership in a trademark. The third stage is an online auction which offers the general public the opportunity to bid electronically. The details of Sunrise Process please refer to 20e.

Privacy and Confidentiality Protection

As a socially responsible operator, the Registry is dedicated to ensuring that the privacy users and confidentiality of information is protected. The Registry, leveraging the infrastructure supported by its Registry Back-End Services provider, Afilias, maintains a highly secure environment physically and technically to ensure that confidential information are not leaked. The Registry is also committed to developing and implementing policies that complies with privacy laws in the locality it operates out of and can be compatible with privacy laws of registrars and registrants of the registry. The Registry understands that there is no guarantee of compatibility of such laws especially given the global nature of the DNS and of the Internet at large, and is committed to dedicate itself, especially through its partner DotAsia (through Namesphere, as the Registry Front-End Services Provider for the Registry), to participate in the global Internet Governance discourse on the subject.

The Registry is committed to introducing the .Kids TLD in an orderly manner to minimize the social costs and maximize the social value of the TLD. Following the successful launch of the .ASIA TLD, and leveraging the experience and knowledge from the DotAsia (through Namesphere), the Registry is committed to developing and implementing a comprehensive startup process that would include, besides Sunrise and Landrush processes, a Multi-Category Pioneer Domains Program.

The Pioneer Domains Program will be designed to curb abusive registrations, whereby reducing social costs, as well as to promote the adoption of the TLD, to maximize the social value of the TLD. An important goal of the program is to allow for the introduction of showcase domains under the TLD in a well structured manner, while ensuring that the protection of the rights of others are maintained. The implementation of showcase domains support the development of positive foundation of usage of the TLD. More detailed explanation of the overall startup process is included in #29.

In response to the question specifically:
1. Mechanisms for Resolving Multiple Applications to a Domain

A comprehensive Sunrise and Landrush program will be put in place at the launch of the TLD. As an important stakeholder of the Registry, DotAsia (through Namesphere) will be lending its experience and knowledge in the development of an appropriate Sunrise and Landrush program that includes mechanisms for resolving multiple applications to a domain when the TLD is first launched. More detailed explanation of the approach is included in #29. In short, during the Sunrise and Landrush processes, a first come first served model will not be used as previous launches has demonstrated that such mechanism creates undue tension, chaos and frustration in the process. Applications for domains will be received within a designated time period and all applications received within such period will be considered to be received at the same time. All applicants will be verified first for their eligibility against the Sunrise and Landrush policies respectively. If there is only one successfully verified application for a particular domain, then it will be allocated directly. If there is more than one successfully verified application an auction will be held to resolve the contention.

During regular operations of the registry (upon GoLive and after Sunrise and Landrush), domain registrations will be accepted on a first-come-first-served basis. In cases of contention, the Registry will not prohibit the use of secondary market mechanisms for interested registrants to resolve the contention. Registrant transfers will be administered by accredited registrars without intervention by the Registry. In the cases of contention against abusive registrations, the Registry will adhere to the UDRP and URS procedures.

When a domain name registration is deleted and after completing the lifecycle according to ICANN requirements, the domain name will be re-released to the available pool and registrations will be accepted on a first-come-first-served basis. If activities to snatch names from this “dropzone” becomes contentious, the Registry is prepared to work closely with the community to provide better mechanisms to resolve contentions where appropriate.

2. Cost Benefits for Registrants

The registry intends to implement periodic cost reduction programs to encourage the adoption of the TLD by registrants. Such cost reduction programs can also be targeted towards key segments of the market in relation to the mission and vision of the Registry explained above. Based on the experience of DotAsia (through Namesphere), rebate programs that essentially lower the costs for registrants are one of the most effective ways to drive the adoption of a new TLD. Cost reduction oriented programs are included in the financial projections provided for #45-50.

Introductory programs will be important to drive awareness and interest in the TLD as well. These should include not only broad price discounts but also targeted programs. Based on DotAsia’s past experience, targeted programs, such as Home Market Growth programs are effective in raising the awareness for targeted segments. Such programs can also come in the form of special price reduction promos or rebate type programs.

Besides price reduction programs, other cost benefits can also be introduced to registrants. For example, DotAsia also pioneered the offering of free gift redemption programs to spark interest from registrants as well as to drive the cost benefits for adoption of the TLD.

3. Contractual Commitments to Registrants

The Registry will abide by the ICANN Registry Agreement requirements as well as ICANN Consensus Policies, including to offer domain registrations for periods of one to ten years at the discretion of the registrar upon GoLive (when normal first-come-first-served registrations begin). During Sunrise and Landrush the Registry will request multi-year initial registrations. The Registry does not plan to implement contractual commitments to registrars regarding the magnitude of price escalation, but is committed to providing a stable environment for registrations, including a stable pricing for registrars.

Besides policies and rules implemented, the Registry believes that prudent operations as an economically viable and socially responsible TLD operator in itself is an important mitigation of increased social costs as a new gTLD is being introduced. The Registry will leverage the knowledge and expertise from its technology provider and DotAsia to ensure that a substantial portion of the costs for operating the registry is managed in variable costs leveraging the economies of scale from already established operations and focus on delivering value to registrants and consumers with the introduction of the .Kids TLD and its mission and features.

Measures to curb abusive registrations will also be put in place to avoid costs from the community caused by such activities. Further details are included in the response to #28. Furthermore, security measures explained in #30 and #31 help reinforce a robust registry system to guard against DDOS and other malicious attacks which have implications to social costs. As explained above, above and beyond the compliance with the Trademark Clearing House (TMCH) requirements, startup policies will be put in place to address issues around reserved names (#22) as well as trademark, copyright and intellectual property concerns (#29).

4. Protection Scheme

To facilitate the enforcement of the Guiding Principles described in 20e A. Eligibility, an express complaint-response system will be implemented through an online portal. The online portal will accept complaint reports of any inappropriate content from the public through a structured report form (i.e. such that the complainant can indicate the type of inappropriate content they are reporting and its severity in the view of the complainant, etc.). Upon the receipt of a complaint report, a takedown decision process will be initiated depending on the type of complaint report filed:

1: Illegal Content & Activities

In the case of a complaint report filed alleging illegal content and activity, the Registry, with the support from Afilias as the registry back-end services provider, will activate the Anti-Abuse process as described in #28 (Abuse Prevention & Mitigation). If the investigation based on the Abuse Policy finds the complaint to be substantiated, the Registry, with the support from Afilias, will act according to the Abuse Policy. If the investigation finds the complaint not to be of an abusive nature in the view of the Abuse Policy, the complaint will be passed to 2.

2: Inappropriate Content

In the case of a complaint report filed alleging inappropriate content or activity (or as a result of 1 above), the complaint report will be passed to the Monitoring Committee for further process. Anyone online can access the complaint-response portal to file a complaint report. This includes the DotKids Foundation itself as well as all members of the Foundation and members of the community. In fact, the DotKids Foundation is prepared to proactively guard against inappropriate content through this mechanism. A complaint report should clearly state the rationale of why the content or activity should be considered inappropriate and how the .kids domain is inconsistent with the .kids Guiding Principles and should be suspended.

Once filed, the report will be posted on the complaint-response portal and the Monitoring Committee will be notified.

Monitoring Committee

The Monitoring Committee consists of members of the Foundation, individuals from the Professional Advisory Council and other qualified children’s rights, children services or children centric organization who volunteers to be on the notification list. Each Committee Member will be able to login to the complaint-response portal and place a “vote”: Red, Yellow or Green against a complaint report filed:

Content Violation Indicators

Red: The domain has severely violated the .Kids Guiding Principles developed by the DotKids Foundation and the domain should be taken down.

Yellow: The domain has marginally violated the .Kids Guiding Principles, a warning should be given and if changes are not made and violation rectified in 10 calendar days, the website should be taken down.

Green: The website did not violate the .Kids Guiding Principles and no action should be made.

Takedown Action

The Voting Period commences immediately upon the posting of the complaint report and notifications sent to the Monitoring Committee. The following are trigger points for takedown or warning actions:

1) If at least 5 Reds and 0 Greens are received within the first 24 hours, the domain will be suspended and a warning notification issued to the registrant.

2) Else, after a 5 day (120 hour) Voting Period completes, the votes will be tallied and form of action will be chosen based on the category with the highest vote.

3) If there is a tie, the higher severity action will be taken.

The number of votes for each category for each complaint report will be maintained on the complaint-response portal, but the organization who casted a votes will remain anonymous.

The Registry intends to remain independent to the community.  However, the Registry will work closely with community organizations and will invite community organizations in its policy development processes and governance structure. Also, we see the participation from the community crucial to our success. 

Relations of Initial Working Group to the Community
Cheney Cheng has been devoted to the advocacy of childrenʹs rights in Hong Kong and international level since 2004. In 2006, he co-founded Kidsʹ Dream, the first child-led organization promoting childrenʹs rights in Hong Kong with members more than 200 people now. He represented Kidsʹ Dream to attend various international conferences and meetings organized by United Nations (UN), Save the Children and other organizations. Cheney was leading the preparation of a report about the implementation of children’s rights in Hong Kong to the UN. He was selected by the UN to be the Asia-Pacific representative in an advisory group evaluating the reporting system of the UN Committee on the Rights of the Child in 2008. Cheney is currently working in an Investment Bank and acts as a volunteer advisor to the DotKids Foundation.

Elaine Cheng has been devoted to the advocacy of childrenʹs rights in Hong Kong and international level since 1999 when she was selected as one of the UNCRC Child Ambassadors of Hong Kong. As a founding member of the Children’s Council in Hong Kong, she has also co-founded Kidsʹ Dream. She is now currently working at the DotAsia Organisation which is a not-for-profit registry of the TLD .Asia. Devoted to promote youth participation in Internet Governance, she thereafter founded the NetMission Ambassadors Programme in 2009.

Bianca Ho has started her involvement with Internet Governance in 2008, where she was selected to be a NetMission Ambassador, a program organized by DotAsia Organisation. She received comprehensive training including seminars, workshops, site visits to gain a better understanding of the complexity of the Internet Governance discussion. Afterwards, She led a social campaign in the local community to raise public concerns towards digital divide. 

Relations to the community and its constituent groups
Community support is a key element of the success of the DotKids foundation. We have gathered support from various parts of the world, including Hong Kong, Asia, Europe etc. We will continue to outreach to and engage with the community as the .kids Registry develops. 

Some of the many endorsements Received to Date:
- Child Rights Coalition Asia (CRC Asia), Asia
- Child Rights Information Center Moldova
- The Smart Internet Foundation, Russia
- Internet Learning Support Centre (ILSC), Hong Kong
- Alliance for Children’s Commission, Hong Kong:
- Against Child Abuse
- Baby Friendly Hospital Initiative Hong Kong Association (BFHIHKA)
- Caritas Family Crisis Line & Education Centre, Children Counseling Services
- Children Rights Association
- Caritas Youth & Community Service Head Office
- Chinese YMCA of Hong Kong – Hin Keng Centre
- Evangelical Lutheran Church of Hong Kong Social Service Head Office
- The Hong Kong Childhood Injury Prevention and Research Association
- Hong Kong College of Paediatricians
- Hong Kong Committee for UNICEF
- Hong Kong Committee on Children’s Rights (HKCCR)
- Hong Kong Council of Early Childhood Education and Services
- Hong Kong Down Syndrome Association
- Hong Kong Society for the Protection of Children
- Playright Children’s Play Association
- Society for Community Organization
- Suen Mei Speech & Hearing Centre
- The Boys’ and Girls’ Clubs Association of Hong Kong
- The Hong Kong Council of Social Service
- TREATS
- Save the Children Hong Kong
- Kids’ Dream
- Ms Chan C.Y. Eliza
- Mr Ken Chan
- Dr Cheung Chiu Hung, Fernando
- Dr Kwok Ka Ki
- Mrs Priscilla Lui
  - Mrs Mak Yau Mei Siu, Teresa

While we have people from the community in our working group, plus the necessary endorsement, .kids have mechanisms in place that ensure our accountability to the community. 

About DotKids Foundation

The operating registry, DotKids Foundation, is a not-for-profit organization founded with the support of children rights organizations and a governance structure that openly invites children as well as children’s rights organizations to participate in the application and operation of the domain “.kids”.  

The initial working group will form the secretariat function of the Foundation and actively reach out to the community and invite children-right organizations to join the Foundation as members and form the Board of Councilors and Advisory Councils according to the following framework.

Special Features of the Governance Structure and Operation:
1.	A membership consortium formed by children-right organizations and children-led groups
2.	Board Members formed by children-right organizations and professional individuals
3.	Advisory Councils formed by children right professionals, IT technology specialist and children-led groups

DotKids Foundation Governance Structure:
The DotKids Foundation will conceptually be a consortium of Children Rights Group and relevant Organizations globally with the below 3 categories of membership established and the admission determined by the Board:
a) International Members 
Organizations of children rights group or relevant organizations that are beneficial to children with proof, and with legal entities incorporated in 2 or more countries 
 
b)    Local Members 
Same eligibility as international members, but only incorporated in 1 country
 
c)     Children Members
        	Organizations or that are proven to be child-led and nominated by the existing International or local members

The Board of Councilors will in total have not more than 11 seats with the below composition: including maximum of 3 Directors from the DotKids Foundation, maxiumum of 3 Directors nominated by International Members,  maxiumum of 3 Directors nominated by Local Members and a maximum of 2 Directors shall be professional individuals.

2 Advisory Councils will be formed to offer advice and opinion to the Board on the all policy matters of the DotKids Foundation, including professional advisory council and children advisory council.
We view Children Advisory Council is a good demonstration on our dedication to the community. We ensure a children-friendly discussion environment will be created where they may form different concern groups at times to freely express their opinion. The inclusion of children is a perfect exemplification of the principles of uor foundation. 

Finally, the Board of Councilors will create a Proceeds Steering Committee to oversee the 
allocation of surplus proceeds, if any, from the operations of Registry.Kids. This Committee may consist of board members, advisory councilors and or outside consultants.

In general, the principles for the conceptual structure of DotKids Foundation are:
-       Ensure broad representation from the community and the voice of children are heard
-       Ensure operations and strategic direction of the registry to be towards the benefit of the community
-       Ensure that surplus management will be directed to relevant children-centric initiatives
 
In summary, the .kids foundation’s founding team members are experts in children rights. Moreover, we have already received endorsement from many of our community members. Also, our governance structure is the best example for our dedication to the community, and clearly states our accountability towards our members.

The .kids TLD is restricted to children centric organizations, non-governmental organizations (NGOs), children’s rights initiatives and children led initiatives in the first phase of Sunrise. Throughout the Sunrise, Landrush phases and upon Go Live, the .kids TLD is restricted to registrants who expressly adhere to the following Guiding Principles in the provision of content and services with their .kids domain

Intended registrants in the TLD include members of the community, especially:
2) Charities, non-government organizations and government institutions that work on the well-being of children.
3) Parents and educators
4) Educational institutions, organizations and operations that are primarily serving children

In general, organizations and businesses whose target group is kids, meaning anyone under the age of 18.

The intended end-users would be kids, or anyone who might be interested in kids related services or products.

PURPOSE OF THE COMMUNITY BASED gTLD

a. Create a kids friendly Internet space
The primary purpose of the community based gTLD is to best serve our stakeholders. As defined in 20a. They are kids, charities, NGO, government institutions and alliances; parents and educators, and any companies, manufacturers and educational institutions. Since there are clear distinctions of our community members, we can segment and define their needs.

Needs of Kids: The ability to freely browse the Internet in acquiring information. Moreover, the information that they reach to is easy to comprehend.

Needs of charities, NGOs, government institutions and alliances: Peace in mind where the information children reach to are constructive to their upbringing, and is not harmful to children

Needs of parents and educators: Having the peace in mind where children can browse the Internet freely, while not having to worry whether they reach to harmful information that would affect their upbringing.

Needs of companies, manufacturers and educational institutions: Abilty to reach to their target group, children more effectively and easily

Our purpose is to best serve the needs of our community members.

b. Encourage children’s participation online

c. Support and contribute to the children community
In order to be able to support and contribute back to our community, we would first need to be self-sustainable and not rely on uncontrollable factors to generate our income, such as donations.

RELATED ACTIVITIES TO SERVE OUR PURPOSE
The string of the domain, as well as policies in place of DotKids will ensure that the domain namespace will be more relevant to these target groups. Concrete actions that DotKids has taken include the design of Sunrise registration policies where we prioritize non-governmental organization (NGO), children centric organizations, children’s product manufacturers, suppliers, importers and crafters.Moreover, the Guiding Principles that the registrants would need to agree ensure the registrants would design the website for kids on a best-efforts basis.

Although after the Sunrise and Landrush policies, the domain names will be sold on a first-come-first serve basis, DotKids have policies the in place even after the initial stage of registration. The Protection Scheme will ensure things would not deviate from what we intended to.

More details please refer to sections 18(a) and (b) above.

LASTING NATURE OF THE PURPOSES
Unlike adults, kids under 18 years old require more protection, care and guidance. The first ever legally binding international instrument to incorporate the full range of human rights—civil, cultural, economic, political and social rights is the UNCRC. Understanding kids under 18 years old requires more protection, care and guidance than adults, in 1989, world leaders worked together to bring attention on the human rights of kids and designed the special convention just for the kids -- UNCRC.

Moreover, provided that kids have different levels of understanding skills and language capability at different ages and maturity, they are undoubtedly a community with special social needs.

According to a publication of the Scottish Government in January 2010 about advocacy support for children and young people, “Advocacy is about ensuring that children and young people can express their views and that these views are heard and taken into account by those who are involved in decision making about children and young peopleʹs lives.”

As a matter of fact, many policies and discussions related to kids nowadays are developed without the participation of kids themselves which kids have relatively low control and influence to the decision making process. Advocacy support is therefore important to ensure kids can express freely with adequate facilitation to overcome any communication barriers. While the current advocacy support emphasized by various Acts or guidelines of government bodies is mainly about situations that are related to formal processes such as legal hearings, we believe that advocacy for kids in the Internet world is also an important agenda for the development of kids.

The .kids initiative is not about child protection, but about promoting kids-friendly content and an environment favorable to the development of children with the participation from children. Kids-friendly content is not only about safety, but about the effectiveness and attractiveness of the presentation of the same information to kids. It is often said that children are the future pillars of our society. But people often forget that children are also part of the present society. The .kids initiative embraces a world that respects the rights of the child not only in safety, but also their rights to participate in the development of relevant policies which will shape their world now and into the future.

For harmonious and full development of kids’ personality, kids have special social needs distinct from adults. Kids should grow up in the care and under the responsibility of the society. The DotKids Foundation is committed to protecting kids from unwanted materials that are likely to disturb and harm them, at the same time, entitling them basic human rights especially in the use of internet, providing them a platform for knowledge exploration, that embraces the freedom of expression and participation in global policies.

The DotKids Foundation develops and promotes the children’s best interests across areas of different human rights, including civil, cultural, economic, political and social rights. Under UNCRC, children all over the globe are entitled to have different basic human rights including the right to survival; to develop to the fullest; to protection from harmful influences, abuse and exploitation; and to participate fully in family, cultural and social life.
The DotKids Foundation aspires to develop the “.kids” domain not only as a playground and knowledge exploration space for kids, but also as a nurturing ground for children participation in global policies, especially in Internet governance. The vision of the DotKids Foundation is rooted in the UNCRC and accepts the guiding principles of the Convention, including non-discrimination; adherence to the best interests of the child; the right to survival, protection and development; and the right to participation by the child.

The selected TLD string “kids” matches perfectly with the community that the DotKids Foundation serves. Based on our research, “.kids” is the most appropriate TLD string to represent the community in the context of an identity for the Internet.

There are 3 major reasons that we think “kids” would be the best match for the community that we have defined:
1. Our community member’s using the same string to define themselves
2. Similarity of the same spelling in other languages
3. Prevalence of the term on the Internet

1. Community Member Organisations utilizing “Kids” as their Main Name

The string “Kids” is used by many organizations that comprise of our community. The following are just a few examples of the many kids⁄child-related organizations in the different continents, demonstrating the “Kids” is commonly known by others as the identification ⁄ name of the community:

Examples From Asia
- Kids’ dream (http:⁄⁄www.kidsdream.org.hk)
Hong Kong Child-led organization focus on children rights
- Street kids rescue (http:⁄⁄streetkidsrescue.org⁄)
The charity’s mission is to support orphaned, homeless and sick children in Southeast Asia.

Example from Europe
- Kids (http:⁄⁄www.kids.org.uk)
The national charity working with disabled children, young people and their families across England
- Kids of Africa (http:⁄⁄www.kids-of-africa.com⁄)
A charity based in Zurich, Switzerland whose mission is that the children will become a backbone of the next generation of Uganda’s society by strengthening the economic and socio-cultural development of Uganda

Examples From North America
- Queen Pen Backing New York Kidsʹ Organisation
Queen Pen, the rapper, lending her support to New York childrenʹs charity to reunite kids with their jailed parents.
- Caribbean Kids and Families Therapy Organisation (http:⁄⁄www.ckfto.org⁄)
Caribbean Kids and Families Therapy Organisation was founded in 2008 in Port of Spain, Trinidad by a mother of a child with special needs and an Occupational Therapist.

Examples from Australia
- Hug-Ur-Kids Organization (http:⁄⁄www.hugurkids.com⁄)
Australian organization, providing many supportive services, along with helping many Custodial Parents to be re-united with their ʹabducted childrenʹ
- Cure Kids (http:⁄⁄www.curekids.org.nz⁄)
Address the lack of research into life-threatening childhood illnesses in New Zealand

These are all organizations that the DotKids Foundation would invite as members of the organisation and are members of the community that we serve.

The word “kids” clearly identifies and describes the community and the community members and do not over-reach beyond the community. As described, the DotKids Foundation adopts the United Nations Convention on the Rights of Child (UNCRC) as its fundamental guiding principle. The UNCRC clearly defines the community as children under the age of 18, and the general use of the word “kids” is not normally used for persons beyond such boundaries of the community.

2. Similarity of the same spelling in other languages

In selecting and researching the appropriateness of the string to represent the community, we also looked into the similarity of the concept in different languages. Our findings indicated that many languages use similar word origins for the same meaning as “kids” in English:
1. Afrikaans: kinders
2. Basque: kids
3. Dutch: kinderen
4. German: Kinder
5. Norweigian: Kids

As for the word “kids” in English, the definition offered by the Merriam-Webster dictionary is as follows:
1. A young goat
2. The flesh, fur or skin of a kid
3. A young person, especially child

While only the last definition is the same with our intended meaning, the most common understanding of the string “kids” is the same as our intended meaning. Kid as defined as “a young goat” has no significant meaning to a broad base of the Internet users. To establish that “kids” have a much broader understanding and relation to our community in the context of a TLD, we further observe that:

Searching: kids goat
In Google returned about 65,700,000 results;

Whereas searching: kids children
In Google returned about 1,290,000,000 results.

This demonstrates a significantly greater correlation between the string “kids” and the community we serve.

3. Prevalence of the term “kids” on the Internet

In determining whether “kids” is a well known term for the community, we also looked in the thesaurus of the word “kids” and found the following relevant synonyms:

kids ⁄ kid; youngster; youth; lad; teenager; child; tot; children

To further establish the prevalence of the term “kids” on the Internet versus the other forms, we looked at the search results from 3 different search engines and compared the results returned for each keyword:

Kids
Google (in mm) 2580
Yahoo (in mm) 58.9
Bing (in mm) 1420
Total (in mm) 4058.9

Children
Google (in mm) 2560
Yahoo (in mm) 54.4
Bing (in mm) 1360
Total (in mm) 3874.4

Child
Google (in mm) 1630
Yahoo (in mm) 270
Bing (in mm) 1780
Total (in mm) 3680

Youth
Google (in mm) 796
Yahoo (in mm) 785

Bing (in mm) 354
Total (in mm) 1935

Tot
Google (in mm) 785
Yahoo (in mm) 437
Bing (in mm) 213
Total (in mm) 1435

Teenager
Google (in mm) 153
Yahoo (in mm) 166
Bing (in mm) 1110
Total (in mm) 1429

Lad
Google (in mm) 107
Yahoo (in mm) 183
Bing (in mm) 27.1
Total (in mm) 317.1

Youngster
Google (in mm) 30.4
Yahoo (in mm) 27.5
Bing (in mm) 15.6
Total (in mm) 73.5

Moreover, comparing on the Global Monthly Searches using the Google Adwords tool, kids has the most searches, with 124 mm searches while children only have 83 mm and child 83.1 mm.

The string “kids” is also short, succinct and especially appropriate for use as a TLD over the other options.

Based on the above, we believe that “kids” is the most prevalent form used on the Internet to describe our community.

To further add to this, we have also found similar initiatives or previous usage of the same string: “kids” in domain names. This serves as a strong reason for the significance of this string and why it best represents the community we look to serve.

- Kids.us
The Dot Kids Implementation and Efficiency Act of 2002 was designed to create a kid friendly domain .kids.us. This act was signed into law on December 4, 2002 (P.L. 107-317) by the US government. It authorizes the National Telecommunications and Information Administration (NTIA) to require the .us registry operator to establish, operate, and maintain a second level domain within the .us TLD that is restricted to material suitable for minors.

- Kids.net.au
The search engine for Kids, Parents and Teachers. it includes a Directory of kids safe websites, Dictionary and Thesaurus including over 100,000 words, Encyclopedia with 1 million articles and a Language Translator.

- kids.yahoo.com
Yahoo Kids! is described as “the ultimate web guide for kids”. It features fun and educational resources for kids with games, animals, music, jokes, movies, news, astrology etc.,

In summary, with the prevalence of its use in children’s rights initiatives and on the Internet, we believe “kids” is the string that best matches the identity of the community, and that given the context of a TLD, “.kids” has no other significant meaning beyond identifying the community described in our application.

The mission and vision of DotKids is exemplified by the registration policies that reflect our community purpose. (Please refer to 20c):

A) Eligibility: For registering a second-level name, and how will eligibility be determined

The .kids TLD is restricted to children centric organizations, non-governmental organizations (NGOs), children’s rights initiatives and children led initiatives in the first phase of Sunrise. A multi-phased Sunrise process will be adopted (for more information please see application form #29).

In a subsequent Sunrise phase, the standard ICANN new gTLD sunrise and Trademark Clearing House implementation will be offered for legitimate registered trademarks and service marks owners to obtain domains corresponding to their entity names.

Throughout the Sunrise, Landrush phases and upon Go Live, the .kids TLD is restricted to registrants who expressly adhere to the following Guiding Principles in the provision of content and services with their .kids domain:

1) Strictly adhere to the UNCRC principles in the provision of content and services under the .kids domain;

2) Content, including the domain name itself, and services provided through the .kids domain must be appropriate for children under the age of 18 and must not include any materials related to:
- Gambling
- Illegal drugs
- Pornography & Obscenity
- Violence
- Alcohol
- Tobacco
- Criminal Activities;

3) Illegal content is strictly prohibited (including but not limited to trafficking, substance of abuse, phishing, copyright infringement, and other illegal content as defined by the laws of the country for which the registrant and⁄or the sponsoring registrar resides); and,

4) Registrants pledge to use best efforts basis to offer kids friendly content and services (i.e. content that are more easily comprehendible for kids) on the .kids domain.

Violation of any of the Guiding Principles is grounds for suspension or cancellation of the .kids domain name registration. The enforcement of the Guiding Principles are described in D) below.

B) Name Selection

In the earlier community Sunrise phase, name selection is restricted to names corresponding to the children centric organizations, NGOs and initiatives, and at the standard Sunrise ⁄ TMCH phase names corresponding to registered trademarks and legitimate marks and prior rights holders.

In the Landrush and Go Live phases, registrants can self-select their .kids name of choice. Yet since the domain name is the first manifesting point of kids to the Internet to ensure the kids-friendliness in all aspects, the domain string itself will also be considered as part of the content and subject to the adherence of the Guiding Principles above. In other words, domain name that contains any inappropriate content (i.e. words or phrases) as regarded in the Guiding Principles will be considered in violation of the Guiding Principles.

C) Content and Use

UNCRC encourages the development of appropriate guidelines:

The DotKids Foundation has developed a set of Guiding Principles as described above in A) and will continue to refine such Guiding Principles under the guidance of the community. It is mandatory for all .kids registrants to adhere to the Guiding Principles. Violation of the principles, whether or not intentionally by the registrant, especially if such violation results in the proliferation of materials likely to harm and disturb kids, will be grounds for cancelation, suspension and takedown of the domain name.

The DotKids Foundation, along with children information experts, will further develop guidelines for registrants in the creation of kids-friendly content. For example, the use of kids-friendly language, graphics and presentation formats.

While the protection of children against harmful information is important, the DotKids Foundation deeply understand that under UNCRC, children shall have basic human rights:

According to UNCRC Article 13, the child shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or in print, in the form of art, or through any other media of the childʹs choice.

Under the guidelines developed by The DotKids Foundation, children are entitled to the freedom to express opinions and to have a say in matters affecting their social, economic, religious, cultural and political life.

More importantly, that underlines an important principle of the .kids TLD to refrain from pre-screening or unnecessary censorship. The framework for enforcement of the Guiding Principles is further discussed below.

D) Enforcement

A Protection Scheme is developed and designed with the purpose of striking a balance between protecting kids from unwanted materials (UNCRC Article 17) and the freedom of expression online (UNCRC Article 13).

Details of the Protection Scheme is included in the response to question 18c above: 4. Protection Scheme.

Open Compliant Platform and Immediate Process

Every netizen can file a complaint via the online portal with clear indication of the point of inappropriate content. The online portal enables all Internet users to contribute on building a kids-friendly Internet space at ease.

Our initial projection of the number of domains is less than 5,000 within a 3-year period, so we do not expect an overwhelming number of abusive cases. Even with 10% of abusive rate over 3 years, our members would only receive a case approximately every 3 days. We understand the importance of prompt action against abusive materials, therefore when the content is clearly abusive, the domain would be taken down within 24 hours with over 5 Red Ratings.

Our members would need to spend time on those cases where it might be borderline, or require more in-depth discussion, we would allow a longer time of voting period to decide the actions taken on those domains.

Since the reporter of the abusive content would need to point out the exact page of the abusive content, it would only take at most a few minutes for our members, who are themselves expert in the children’s rights community, to determine whether the content is abusive.

Representative Decision of the Community

The Protection Scheme is best maintained by children’s rights experts around the world – who are members of the DotKids Foundation governance structure. We understand that there would be cultural differences as to what harmful material are in the eyes of people, however, the children right experts with a long experience of defending rights of children, would know the best.

The online portal would be the most cost efficient way as well as effective way for us to reach to our members globally within a matter of seconds. Moreover, we understand that it would be physically difficult to have our members in present to vote on websites whether they have harmful content to kids. The online portal is the best way to aggregate the information and have allow our members to have flexibility to vote any time they can within the voting period. This platform is scalable, especially because this can be used with 10 members, or 10,000 members. The DotKids foundation would only need to handle the administrative process for each organisation, but not for using the resources to host a voting meeting every time.

As the DotKids Foundation grows, we expect the Monitoring Committee to grow as well. It is reasonable to expect that as the “.kids” TLD grows, the interest and willingness of organizations and volunteers to participate in the Monitoring Committee would grow as well. We have set the preliminary takedown limit as 5 votes from our members. With the growing interest and size of the domain, we expect this number would be reviewed periodically. Eventually, we would hope that it would be around 3% of our total members that would constitute a significant action and representation from our members. The low threshold represents a conservative approach towards reasonably strong protection towards the content in our domain.

In summary, the Protection Scheme is the most time and cost effective way for collecting opinion from children rights experts around the world.

23 Registry Services

Throughout the technical portion (#23 - #44) of this application, answers are provided directly from Afilias, the back-end provider of registry services for this TLD. The Registry chose Afilias as its back-end provider because Afilias has more experience successfully applying to ICANN and launching new TLDs than any other provider. Afilias is the ICANN-contracted registry operator of the .INFO and .MOBI TLDs, and Afilias is the back-end registry services provider for other ICANN TLDs including .ORG, .ASIA, .AERO, and .XXX. The Registry has also chosen Namesphere (a company created by DotAsia Organisation Limited, the registry operator for the .ASIA gTLD) as the Registry Front-End Services Provider.

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

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

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

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

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

Security

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

New registry services

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

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

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

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

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

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

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

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

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

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

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

Afilias approach to registry support
Afilias, the back end registry services provider for this TLD, is dedicated to managing the technical operations and support of this TLD in a secure, stable and reliable manner. Afilias has worked closely with the Registry to review specific needs and objectives of this TLD. The resulting comprehensive plans are illustrated in technical responses #24-44, drafted by Afilias given the Registry requirements. Afilias, Namesphere (with the support of DotAsia) and the Registry also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of this TLD.

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

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

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

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

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

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

24 SRS Performance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25 EPP

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

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

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

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

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

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

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

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

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

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

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

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

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

EPP modifications
There are no unique EPP modifications planned for this TLD.

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

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

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

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

26 WHOIS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unique TLD requirements
There are no unique WHOIS requirements for this TLD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27 Registration Lifecycle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This TLD may conduct auctions for certain domain names. Afilias will manage the domain name auction using existing technology. Upon the completion of the auction, any domain name acquired will then follow the standard lifecycle of a domain.

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

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

Afilias has more than 30 staff members in these departments.

28 Abuse Prevention and Mitigation

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

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

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

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

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

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

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

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

Furthermore, adopting the process included in the .ASIA Registry-Registrar agreement (http:⁄⁄dot.asia⁄accreditationdocs⁄DotAsia-RRA-2010-02-01.pdf), the Registry will also include in its Registry-Registrar agreement a clause to specify that all registrations are to submit to proceedings for expedited suspension processes of domain names:

(3.9.11) Submit to proceedings commenced under other dispute policies as set forth by [DotAsia] from time to time in the Registry Policies, including but not limited to expedited processes for suspension of a domain name by claims sought by intellectual property right holders, Internet engineering and security experts or other competent claimants in the purpose of upholding the stability, security and integrity of the [.ASIA Registry].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29 Rights Protection Mechanisms

The Registry is committed to a comprehensive strategy on Rights Protection Mechanisms (RPM). The Registry works closely with DotAsia Organisation (through Namesphere) and draws from the successful experience and knowledge of the RPM measures implemented for the .ASIA, especially in its acclaimed Sunrise process and its contributions to rapid suspension policies.

29.1 Sunrise and Startup Processes

A comprehensive Sunrise and startup process is the key to successful RPMs. A successful Sunrise program not only provides priority to rights holders, but also sends a clear message to the market that the TLD is serious about RPMs, thereby further deterring abusive registrations.

The Sunrise process provides for the introduction of the TLD in an orderly and equitable manner. Its purpose is to give reasonable protection and priority to stakeholders and certain prior rights holders, as well as to deter abusive and bad faith registrations. The Sunrise policies are also designed to facilitate reliability for ICANN Accredited Registrars and fair competition amongst registrants. It is intended to create a stable and effective launch and registration process for the benefit of various stakeholders and the Internet community at large.

Learning from the successful experience of the .ASIA sunrise, which achieved 0 disputes and also 100% satisfaction (satisfied or very satisfied) in an online poll of Intellectual Property Rights (IPR) practitioners, the Registry will implement a thorough and multi-phased Sunrise and startup process similar to that of the .ASIA registry.

A comprehensive set of Sunrise policies will be put in place in addition to the standard Sunrise and Trademark Claims services as specified in SPECIFICATION 7: MINIMUM REQUIREMENTS FOR RIGHTS PROTECTION MECHANISMS, of the New gTLD Registry Agreement. The Sunrise policies will follow a similar framework of the .ASIA Sunrise Policies (http:⁄⁄dot.asia⁄policies⁄DotAsia-Sunrise-Policies--COMPLETE-2007-08-10.pdf), in so far as it does not conflict with the specification 7.

29.1.1 Standard Sunrise and Trademark Claims Services

As a basic commitment, the Registry will implement the requirements from Specification 7 of the New gTLD Registry Agreement, and in accordance to the relevant Trademark Clearing House (TMCH) Sunrise and Trademark Claims services.

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

The Registry believes that these form only the very basic layer of RPM and will therefore add significant measures on top of the standard process to ensure that prior rights of others are not abused.

In terms of Sunrise, Specification 7 and the TMCH descriptions only provide a basic framework for Trademark holders to protect names that are identical to their trademark. The Registry believes that additional protection is important and can be efficiently and effectively put in place with a multi-phased Sunrise program. Further discussion about this is included in 29.1.4 below.

29.1.2 Auction Process

An important part of the success of the .ASIA Sunrise program is the use of auction in the resolution of contention. It is known that many Trademarks are similar or identical because of the different jurisdictions and different classes. Therefore, it is inevitable that there would be some competition among rights holders to certain names. A complete Sunrise program requires a contention resolution mechanism that works to reduce the tension of competition and resolve the issue in a stable and orderly manner.

When the .ASIA Sunrise Auction process was first introduced, the community was worried about possible high prices in the auctions making it costly for trademark holders. The results of the process demonstrate however the original intent prevailed. If a pure first-come-first-served model is used, the tension at the opening of the registry at the Sunrise period would be extremely high. Also, because of the competition, the so-called FCFS approach essentially becomes a lottery and one that favours registrars with systems in closer proximity to the registry servers. The tension and the inherent unjust of the process caused thousands of disputes and litigation in previous launches of TLDs utilizing such an approach.

In the .ASIA Sunrise process, a total of about 30,000 applications were received. Out of which less than 2% ended up in an auction. Furthermore, only about 40% ended up in a contested auction (i.e. that there was more than 1 bid in the auction). What that means is that, while it demonstrated clearly that there is certainly competition among trademark holders, it only represents a very small portion. Also, when there was more than one verified applicant for a Sunrise domain and an auction is setup, many trademark holders elect not to bid for the name. Based on the understanding from DotAsia, it is found that many trademark holders do know that their mark is “shared” by other companies, perhaps in different jurisdiction or in different categories. Their motivation to participate in the Sunrise is to avoid abuse of their mark by other parties. Because in the Sunrise process, before an auction is held, each of the verified applicants will be given the information of the other verified applicants in the auction ahead of time. They therefore know who else is bidding for the name and can evaluate whether the other party may in fact abuse their mark. Knowing that the other party is another legitimate trademark holder who may not be abusing their mark, many of the trademark holders elected not to bid and let the other party win the auction with a nominal bid at $10.

What this illustrates is that the auction process is a very successful tool in reducing the stress of the people and the systems in the launch of a registry. Overall, the average winning price of the auctions in the .ASIA startup process was less than US$200. That represents a significant cost benefit for rights holders in comparison to possible litigation or alternative dispute resolution proceedings.

29.1.3 Sunrise Challenge (Dispute Resolution) Process

Besides a contention resolution process, an important part of any Sunrise process is a well developed Sunrise Challenge Process to ensure the integrity of the Sunrise program. The Sunrise Challenge Process is important such that after the allocation of a Sunrise name, there is a period of time where legitimate rights owners can challenge the legitimacy and eligibility of a registrant based on the Sunrise policies to a domain name.

Following again the .ASIA experience, a comprehensive Sunrise Challenge (Dispute Resolution) Process will be put in place and a dispute resolution provider will be selected to arbitrate disputes. A sample of the .ASIA Sunrise Challenge Process is included in the Attached. As part of the requirement of Specification 7 of the new gTLD Registry Agreement, An SDRP will be adopted to allow any party to raise a challenge on at least the four grounds identified in the Applicant Guidebook at TMCH s6.2.4. The remedy will be cancellation or deletion of a successfully challenged domain name. All registrants will be required to submit to proceedings under the SDRP, which will specify that SDRP claims may be raised after registration of a sunrise domain and will require that complaints clearly identify the challenger, the challenged domain, and the ground⁄s on which the complaint is based.

29.1.4 Additional Protection Mechanisms for Sunrise

In addition to the basic “identical” match of a Trademark to a domain name applied for during the Sunrise period, the Registry intends to follow the successful example of .ASIA to include additional types of matches, for example:
- Exceptions for registered mark (tm, sm, etc.) type or entity type (ltd, inc, etc.) identifiers
- Exceptions for the TLD string (i.e. allowing marks containing the TLD string to omit that substring)
- Considerations for commonly used short forms and omission of locality indications
- Acceptance of standard Romanization and Transliterations for Company Names
- Extended protection for trademarks + the class of the trademark (e.g. “BRAND Shoes” or “BRAND Computers”, etc.)

These considerations allow trademark holders priority registration opportunity to protect names that are important and related to them.

The Registry will also develop specialized phases targeted to provide priority registration periods for the community that the Registry will be primarily serving. For example, in the .ASIA Sunrise, Asian businesses and registered companies are allowed to participate in one of the phases of the Sunrise program ahead of the general availability of the domain. This allowed many Asian businesses who may not have a registered trademark to make use of the Sunrise process to protect their name.

Besides the multitude of provisions for rights holders to participate in the Sunrise process, another important feature of the success of the .ASIA Sunrise program is the inclusion of a built-in reconsideration process. Because of the many applications a trademark holder may need to be filing, especially considering in the future the many new gTLD launches, it is possible that clerical mistakes and errors could be made in the Sunrise application. The .ASIA Sunrise process included a built-in reconsideration and amendment process that was critical to the overall success of the program. The success rate of the .ASIA Sunrise applications was over 90% as compared to other previous Sunrise launches where the success rate may be closer to 50-60%.

This explains the high approval rating of the .ASIA Sunrise program and also the rationale for the Registry to learn from and follow the good example set by .ASIA in the development of its comprehensive Sunrise policies.

29.1.5 Proactive Outreach and Specialized Programs

Furthermore, on top of the Sunrise program, a Pioneer Domains Program will be put in place to provide even further protection for prior rights holders while maintaining a strong balance against users’ rights.

Two features of the Pioneer programs for rights holders include: 1) the ability to apply for typo or other variant forms of their trademark to improve protection; 2) the use of the Pioneer Domains Challenge process to protect against abuse.

Again, following from the success of the .ASIA startup processes, the Registry intends to put in place a Pioneer Domains Program similar to the .ASIA Pioneer Domains Program (http:⁄⁄pioneer.domains.asia⁄ascii⁄policies.html). Together with the Pioneer Domains Program, a Pioneer Domains Challenge Process will be put in place (http:⁄⁄pioneer.domains.asia⁄ascii⁄challenge.html).

In short, the Pioneer Domains Program invites potential registrants to submit proposals, explaining how they would use and promote the domain name. Each proposal will require an application fee and prior acknowledgment and acceptance of relevant terms and conditions. Evaluation criteria will take into account the applicantʹs business plan, marketing expertise, and the manner and purposes for which the proposed site would be operated. For Trademark applicants, the evaluation criteria is based on the trademarks filed and the rights holder can also apply for variations relevant to their mark.

29.2 UDRP, URS and other Suspension Processes

While the Startup process, including the multi-phased Sunrise program provides a proactive process for prior rights holders to protect their names under the TLD in a priority registration process, RPMs after the allocation and delegation of a second level domain under the TLD is equally important.

29.2.1 UDRP Implementation

The Registry will comply with and put in place mechanisms to ensure the enforcement of UDRP decisions. These include provisions within the Registry-Registrar Agreements (RRA) with Accredited Registrars to ensure that they have adequate provisions in their Registration agreement with registrants to submit to UDRP proceedings, as well as to work closely with Accredited registrars in the implementation of UDRP decisions and required actions through the URS process.

29.2.2 URS Implementation

The Registry will comply with and put in place mechanisms to ensure the enforcement of URS decisions. These include provisions within the Registry-Registrar Agreements (RRA) with Accredited Registrars to ensure that they have adequate provisions in their Registration agreement with registrants to submit to URS proceedings, as well as to work closely with Accredited registrars in the implementation of URS decisions and required actions through the URS process.

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

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

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

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

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

29.2.3 Other Suspension Programs

As described in response to Questions 18c (4. Protection Scheme) and 20e (D. Enforcement), an express complaint-response system will also be implemented. To facilitate the enforcement of the Guiding Principles described in 20e (A. Eligibility).

In addition to the basic dispute and suspension programs, the Abuse Prevention Mechanisms as described in #28 as well as the geographical names reservation processes described in #22, the Registry, following the footsteps of the .ASIA Registry as well, will explore appropriate suspension mechanisms and challenge processes to further improve the protection to prior rights holders.

For example, .ASIA has completed an MoU with the International Federation Against Copyrights Theft Greater China (IFACT-GC), and has explored extensively and works closely with the Anti-Phishing Working Group on possible alternative rapid suspension processes against gross copyright infringement and phishing sites. These discussions also helped inform some of the discussions that lead to the development of the URS.

Given the focus of the TLD, the Registry will also consider and explore adopting other relevant forums for domain dispute resolution. For example, the Registry may explore the adoption of relevant ccTLD dispute resolution processes or any other industry arbitration processes relevant to the use to broaden the protection of the legitimate prior rights of others in the registration of domain names in the TLD. These measures will be put in place in addition to and definitely not in replacement of the basic requirements of submitting to UDRP, URS and other ICANN policies.

29.2.4 Post-Delegation Dispute Resolution Process (PDDRP)

While the Registry is confident that its processes and policies will be effective in curbing abusive registrations, and that it has the knowledge and capabilities to implement and enforce such measures, the Registry is fully prepared to work with ICANN should a PDDRP be initiated.

The Registry fully submits to the process and, along with its Backend Registry Services Provider as well as Front End Registry Services Provider, will comply with all ICANN requirements through a PDDRP.

29.2.5 Rights protection resourcing plans

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

29.3 Meeting & Exceeding Requirements

29.3.1 Capabilities and Knowledge

The Registry is supported by Namesphere as the Front-End Services provider, and works closely with DotAsia Organisation (through Namesphere) to develop the Sunrise and Startup processes as well as agreements and other administrative proceedings to ensure effective, efficient and implementable enforcement of such policies and processes.

DotAsia has significant knowledge and expertise in the development and successful implementation of Sunrise and RPM policies, as demonstrated by the successful launch of the .ASIA TLD. A dedicated team comprised of DotAsia, the Registry and our Registry Back-End Services Provider Afilias will be convened to ensure that policy as well as technical capabilities are in place to support the RPMs.

29.3.2 Compliance with Specification 7

The Registry is committed to comply with Specification 7 of the New gTLD Registry Agreement, and plans to implement additional RPM on top of the basic requirements of Specification 7.

29.3.3 Plans for Meeting Compliance with Contractual Requirements

The Registry, along with its Front-End Services Provider and Back-End Services Provider will work to ensure that contractual compliance is met. Besides the basic requirements in Specification 7, the Registry intends to consult with ICANN through the process as additional RPMs are put in place to ensure that they also comply with contractual requirements. With the strong experience from our partners, especially from DotAsia, the Registry can be assured that it will meet and comply with all the ICANN contractual requirements.

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

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

29.3.4 Consistency with Technical, Operational and Financial Approach

The use of pendingCreate along with other registry system features ensure that Sunrise and other startup processes could be processed in a standards based manner. In addition, DotAsia has helped to work out an open EPP extension for the implementation of Sunrise applications:

These EPP Extensions include:
• An 〈ipr:name〉 element that indicates the name of Registered Mark.
• An 〈ipr:number〉 element that indicates the registration number of the IPR.
• An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
• An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
• An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for.
• An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered.
• An 〈ipr:class〉 element that indicates the class of the registered mark.
• An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for.

Note that some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse and also specific implementation of the Sunrise process at the Registry.

29.3.5 Committed Resource to Carry out plans

Both Afilias and Namesphere as the Registry Back-End and Registry Front-End Services provider respectively have teams prepared and dedicated with capacity and capability to implement a comprehensive Sunrise and Startup process as well as the additional RPM measures that the Registry intends to put in place.

29.3.6 Rights Protection as A Core Objective

Based on the in depth discussion and commitment to the multitude of RPM features as well as a multi-phased startup process to ensure the stable and orderly introduction of the TLD, the Registry believes that it has demonstrated its commitment to rights protection as a core objective.

Beyond RPMs, the comprehensive geographical names protection program as explained in #22 further demonstrates the dedication of the Registry towards the protection of the prior rights of others.

29.3.7 Effective Mechanisms in Addition to Requirements in Registry Agreement

The policies and processes proposed by the Registry are proven and time tested to be effective in curbing abusive registrations. The .ASIA sunrise processes were highly regarded by the industry and yielded 100% satisfaction rating from an online poll of Intellectual Property Rights practitioners.

Much of the approach has been tested and proven successful through the launch of the .ASIA TLD. The success of the process can be observed by the imitation or following of the processes, including the multi-phased startup, the auction based contention resolution, as well as the Pioneer Domains Program (i.e. an Request for proposal -- RFP -- type process) are now commonly used processes when a TLD is launched or certain section of names are released by a TLD (e.g. 1 and 2 character names in existing gTLDs).

30a Security Policy (Public)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Special TLD considerations
Afilias’ rigorous security practices are regularly reviewed; if there is a need to alter or augment procedures for this TLD, 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 24⁄7 Customer Service Center consists of highly trained staff who collectively are proficient in 15 languages, and who are capable of responding to queries from registrants whose domain name security has been compromised – for example, a victim of domain name hijacking. Afilias provides specialized registrant assistance guides, including specific hand-holding and follow-through in these kinds of commonly occurring circumstances, which can be highly distressing to registrants

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

New gTLD Application Submitted to ICANN by: DotKids Foundation Limited

String: kids

Originally Posted: 13 June 2012

Application ID: 1-1309-46695

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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.

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.

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.

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.

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

18(c). What operating rules will you adopt to eliminate or minimize social costs?

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.