ICANN New gTLD Application

DotAfrica is a ‘Standard’ gTLD:

DotAfrica gTLD will be a standard, open, generic Top-Level Domain (gTLD) that serves the diverse needs and purposes of the global Internet community, but with special focus on promoting Internet use in Africa. It will have no community restrictions in its registration policies.

DCA believes that DotAfrica does not qualify as a community-based application for two main reasons:

a) There is no clearly delineated, organized and pre-existing community that is targeted by the DotAfrica gTLD.
b) It is difficult to clearly identify who are the ‘members’ of the community, since a ‘community-definition’ of DotAfrica will restrict its use and functionality. Since ‘DotAfrica’ does not necessarily mean a TLD for ‘Africans’, it is difficult to determine the persons or entities that are considered to form the community, and the number of people or entities that make up the community.

It is for these reasons that we think that any community-based application submitted for DotAfrica is merely to get a very important generic word – that refers to a geographic name – as a gTLD string for the ‘purposes’ of a community that is very difficult to define and construct.

DCA Trust intends to apply for DotAfrica as a standard gTLD and after its application is successful, to implement an open gTLD registry in line with the Mission and Purpose of DotAfrica. DotAfrica will not cite any particular community both in the application, and in the resulting new gTLD Registry agreement.

For example, it is not envisioned that community-based restrictions such as policies allowing registration of community members only or use of registered domain names in conformity with the stated purpose of the community-based TLD, as enshrined under Article 2.18 of the new gTLD Registry Agreement will apply to DotAfrica. DotAfrica is therefore not aimed at any particular community, and as such, no community has participated directly or indirectly in the development of the policies of the TLD. DCA Trust does not believe that DotAfrica gTLD should be operated and used to serve the needs of any particular community. DCA Trust has not defined a community-based purpose for DotAfrica gTLD, and no particular community has been named in this application.

Expected Objectives and Benefits of the new gTLD Programme:
ICANN as the organization overseeing the new gTLD programme is dedicated to preserving the security and stability of the Internet, promoting competition, achieving broad representation of global Internet communities, and developing policy appropriate to its mission through bottom-up, consensus-based processes. The new gTLD programme is in line with ICANN’s primary mission of ensuring the security and stability of the DNS, and, in particular the Internet’s root server system. According to the principles, recommendations and implementation guidelines for the new gTLD programme, the reasons for introducing new Top-Level domains include:
• Demand from potential applicants
• An application process that would promote competition in the provision of registry services
• New TLDs are expected to add to consumer choice, market differentiation, and geographical and service-provider diversity

According to the new gTLD Applicant’s Guidebook, the new gTLD programme is expected to open up the top-level of the Internet’s namespace to foster diversity, encourage competition, and enhance the utility of the DNS. Some of the important expected objectives of the new gTLD programme are:
i. Creating significant potential for new users and benefits to Internet users across the globe.
ii. Expansion of the Internet by opening up the domain name space, thereby creating new business opportunities based on new web sites that will be introduced
iii. Increased benefit of choice to Internet users
iv. Provide a platform for innovation and further inventiveness on the Internet
v. Foster more creativity in the use of domain names

DCA’s application for the DotAfrica gTLD is in line with the new gTLD programme objectives of ICANN. We believe that the expansion of the Internet will also lead to the expansion of Internet use in Africa. This is fundamental to DCA’s Mission and Purpose for DotAfrica: harness the prospects and opportunities presented by the new gTLD programme to introduce profound changes to the way the Internet is utilized in Africa, especially the new domain names that will be created and become available under DotAfrica gTLD.

Important Duties & Responsibilities of a ‘Registry Operator’:
DCA understands that being delegated the gTLD and appointed ‘registry operator’ is a very important responsibility that imposes certain duties and obligations to operate a part of the Internet DNS which obliges DCA to:

1) Operate the DotAfrica gTLD in a stable and secure manner.
2) Comply with consensus policies and temporary policies.
3) Implement start-up rights protection measures such as a Sunrise period and a Trademark claims service during the start-up phases for registrations in the TLD as provided in the registry agreement.
4) Implement post-launch rights protection measures.
5) Implement measures for protections of country and territory names in the new gTLD.
6) Pay recurring fees to ICANN.
7) Regularly deposit Registry Data into escrow with a ‘Data Escrow Agent’.
8) Deliver monthly reports in a timely manner to ICANN.
9) Provide a Whois service.
10) Maintain partnerships with ICANN accredited registrars.
11) Maintain an abuse point of contact.
12) Cooperate with contractual compliance audits.
13) Maintain a Continued Operations Instrument so as to minimize risk to users and registrants.
14) Maintain community-based policies and procedures (This will not be applicable for a non-community⁄standard application for DotAfrica gTLD)
15) Have continuity and transition plans in place.
16) Make TLD zone files available via a standardized process.
17) Implement DNSSEC.

Charitable Mission & Purpose
As an independent non-profit, DCA Trust intends to utilize surplus proceeds from the registry operation accruing to the Trust Fund for charitable projects. Funds will be regularly allocated to different corporate social responsibility programmes. Specific projects will be identified, and supported. As the first gTLD for Africa, it will aim at bridging the digital divide that exists between other regions of the Internet community and Africa by promoting the use of ICT for development. Therefore, DCA intends to focus on development projects that will aid the increased use and penetration of the Internet in Africa, including provision of low-cost⁄affordable computers, Internet bandwidth, and user training for disadvantaged groups, target local communities and focus groups in Africa.

Some of the programmes that DCA has already initiated :and continues to support include the Youth Demographic in Africa

Generation.Africa:
Generation.Africa is a youth focused program launched by DCA to empower a new generation of Internet users in Africa using its generation.africa theme. It is aimed at different youth audiences and encourages their involvement in discussions that define and increase their common stake-holding in the development and evolution of the Internet.

Miss.Africa:
The Miss.Africa programme is a gender-focused initiative targeted mainly at female youth audiences in Africa to increase their personal involvement in early technology use and adoption with a view to improving their digital self-awareness and empowerment, and overall self-esteem. It is aimed at attracting more young girls and women to the Internet platform to enable them form a sizable demographic of Internet users in Africa, thereby involving them in complementary gender development initiatives that improve the lives of young girls and women.

The African ccTLDs and the Yes2DotAfrica Awareness Campaign are other two initiatives that DCA will support.

i.  The ICANN new gTLD programme will make it possible to have more Internet domain names beyond the current 22 generic Top-Level Domain names, and two-code country Top Level Domains (ccTLDs), thus providing users and registrants with a wider choice in the type of domain names they can register. The introduction of the DotAfrica gTLD will increase and widen the choice of domain names available to registrants since this will also make DotAfrica domain names available to users who wish to use it for different purposes such as creative marketing, innovation and branding of businesses, products, and services, thus consolidating the ‘African Brand’ on the global Internet platform. DotAfrica is expected to promote an African identity on the Internet by boosting Africa’s online presence and visibility on the Internet.
DotAfrica gTLD will therefore have the reputation as the domain name of choice for promoting African brands (brands.africa) and identity on a global scale, as Internet domain names creatively use the DotAfrica name extension for a wide range of local and global products, services, brands, companies, etc. It will be typified by high levels of quality service to users and registrants.
The geographic name ‘Africa’ will uniquely position the DotAfrica gTLD to specialize in all things that relate to Africa, in a way that presents vast opportunities for all those who are interested in Africa for any possible number of reasons.   

ii:  It is widely anticipated that the programme to introduce new top‐level domains has the potential to promote competition in the provision of registry services, to add to consumer choice, market differentiation and geographical and service‐provider diversity. (See for example http:⁄⁄www.icann.org⁄en⁄news⁄announcements⁄announcement-09nov10-en.htm) DotAfrica is expected to increase the level of competition in the domain name industry - both globally, and within the African continent - whilst improving customer choice, creating further market differentiation and geographical diversity in the ownership and operation of registry services. For instance, it is already envisioned that a successful delegation of the DotAfrica gTLD based on DCA’s new gTLD application will result in the first African-based gTLD registry operator.

Accordingly, DCA Registry believes that diversity and competition in the provision of registry services will result from the introduction of the new DotAfrica gTLD. This would be of immense benefit to registrants, registrars and domain name resellers in Africa and globally.  The DotAfrica gTLD creates a unique opportunity for Africa to develop its own locally hosted gTLD registry, serving Africans from within Africa. DCA Registry Services intends to host the back-end registry system in a data centre in Nairobi, Kenya to support the technical functions of the DotAfrica gTLD Registry. The location of a world-class gTLD registry service in an African country would greatly contribute to technology transfer as registry operations and technical management skills are acquired by local staffs that participate in the project of establishing and running the registry. It is anticipated that adequate training shall be provided for the DCA local technical and operations staff in Kenya thereby aiding the process of technology transfer to African ICT professionals.

Apart from offering approved registry services, it is our intention to optionally provide Internationalized Domain Names (IDNs) support for Arabic and Latin at the second-level even though DotAfrica is not an IDN TLD. Therefore, DotAfrica will be considered as an ASCII TLD which offers IDNs (Arabic and Latin) optionally at the second level. 

A)	Improved Competition:
The potential users of DotAfrica domain names include commercial registrants, non-profits, governmental⁄inter-governmental organizations, and individual users. At the registry level, DCA DotAfrica Registry Services intends to adopt an open registration policy, thereby increasing the number of players competing to provide higher levels of service at affordable prices for Africans and other global users. DotAfrica gTLD will create improved competition in terms of choice, pricing, services and further opportunities for registrars and resellers.

1)	Choice:
The DotAfrica gTLD will increase the range of choices for African Internet users who can now use the DotAfrica domain alongside their own ccTLDs and other gTLD names and by supporting the development of new African TLD initiatives such as: cities.africa for African cities; communities.africa to serve the diverse and rich cultural heritage of African communities; and brands.africa for Africa’s emerging brands; and IDNs support at the second-level particularly for the Arabic-speaking countries of North Africa within the framework of ICANN’s new gTLD policy.

Competition in the Domain Marketplace will come through employing an ICANN standard registry-registrar model where domain name registrants will be able to buy DotAfrica domains from multiple ICANN-Accredited Registrars with the advantage of lower prices and more Internet products.

2)	Pricing: 
Based on our research, African ccTLD Domains cost an average of $80 per annum, and this comparatively high cost has led to the low uptake of domain names. Most users cannot afford to purchase ccTLD domain names, forcing them to host content on free services like Wordpress and BlogSpot. This prevents the development of meaningful content in Africa’s Internet space. Our proposed pricing model aims to offer domain registrations at a cost commensurate with the income levels of Africans. The proposed selling price of US$10.00 per standard domain name will be price-competitive with the price offered by global registrars for a typical gTLD domain name.

3)	Equality⁄Non-Preferential Treatment in Delivery of Service: 
In adherence to the Registry Operator Code of Conduct obligations enshrined in Specification 9 of the new gTLD Registry Agreement, DCA will aim at ensuring equality and non-preferential treatment of registrars in the delivery of registry services. Since DCA Registry Services will not be providing registrar services, we will work to develop the DotAfrica namespace amongst African Internet users without conflict of interest, preferential treatment of registrars or preferential pricing; Our registry Web front-end and support for the latest registry protocols will make it simpler and easier for all registrars to deal with DCA DotAfrica Registry Services on an equal basis (non-discriminatory access to registry services) in keeping with ICANN mandatory guidelines and Consensus policies, thereby reducing the cost of entry into the market place and enhancing competition amongst ICANN-accredited registrars.

4)	Marketing Opportunities for Domain Name Resellers in Africa: 
African domain name resellers of existing gTLDs are at a great disadvantage relative to their competitors in the more advanced Internet markets since African resellers have to expend higher marketing budgets, are faced with higher broadband costs, low user awareness on the importance of domain names and other products like SSL certificates have made the reseller business in Africa very difficult. DCA Registry Services along with its back-end registry services partner – CentralNIC - plans to utilize a sizable marketing budget to promote different sales and marketing incentives for African resellers including but not limited to marketing grants, technical support and training; approving resellers to sell premium domains, price incentives, etc.

B)	Differentiation
DCA Registry Services proposes to differentiate DotAfrica from existing TLDs and other new gTLDs through communication and marketing programs aimed at positioning DotAfrica as a vibrant domain namespace in which organizations and individuals within the continent can express their Pan African outlook and identity on the Internet.   DCA will provide a world-class registry service based on technical excellence and customer service as the means of creating a unified Internet identity for Africa through DotAfrica gTLD. 

Our approach for differentiation would entail attaching a brand value to DotAfrica both in Africa and globally as the gTLD for the African Region, by drawing on the African desire for unity and integration to express a consolidated Pan-African online identity. While there are no competing or confusingly similar domains to compel us to strictly differentiate DotAfrica we are confident that differentiating DotAfrica will help define DotAfrica in the minds of users as a TLD that offers continent-wide branding possibilities as opposed to country specific ccTLDs.   

Differentiation will be further achieved based on the Whois service and strong marketing approach to be adopted by DCA DotAfrica Registry services:
•	WHOIS Service:  The implementation of a “Thick” Whois output service as part of the DotAfrica Registry system would allow interested third parties to look up the registrant, administrative, technical, billing and DNS delegation information for registered domain name(s) in such form as set forth in Specification 4 of the New gTLD Registry Agreement; coupled with a strict privacy policy will create a technical platform to support the development of a range of new and valuable DNS services for the Global and African Internet user. 
•	Marketing: Marketing would be vital in promoting the adoption of DotAfrica domain names.    Several marketing initiatives will be undertaken by DCA based on a proper market assessment and estimation of demand, and a well-structured marketing plan that targets various language-speaking groups in different regions of Africa such as (a) Northern Africa – an Arabic-speaking region; (b) Francophone Africa which comprises of French-language speaking countries in West⁄Central Africa; Anglophone Africa aimed at the English-speaking countries in West, East and Southern Africa; and (d) Lusophone Campaign aimed at the Portuguese⁄Spanish-speaking African countries. Each region will be further segmented to reflect the various target user groups. 

Registrars and reseller will also be engaged as part of the DotAfrica gTLD marketing programme with various incentives schemes provided for registrars. We intend to allocate part of registrar’s expenditure up to a cap of gross registrations to support such planned incentives. 

DotAfrica gTLD will offer a Pan-African identity appeal and outlook, a trusted and secure namespace, and brand⁄trademark protection that would make it possible to market to brands and commercial organizations in Africa and global companies doing business in Africa. 

III:    A snap survey and analysis conducted by DCA reveals that current user experience with the ccTLDs has been largely typified by poor levels of customer satisfaction, since users have to cope with an under-developed reseller system. This is mainly attributed to the fact that the ccTLDs registries do not have the latest technologies thereby making users to show preference for the services offered by other gTLD registries. Therefore, we intend to offer an improved user experience based on better quality customer services to be achieved as follows: 

1.	Physical – DCA DotAfrica Registry will implement an all new registry system that will be user-friendly and based on world-class technologies, using an up-to-date registry services management system platform. It is anticipated that this will provide an entirely new experience for users and registrants of the DotAfrica gTLD typified by high levels of customer satisfaction.
2.	Social - Availability of DotAfrica domain names will affect the way people perceive and ascribe value to domains names in Africa.  This is expected to trigger a positive effect that will change how domains are utilized creatively and innovatively, thereby creating a new form of Internet user experience as DotAfrica gTLD names are widely and rapidly adopted.
3.	Infrastructural  - Availability of a good registry system that will ease the current user problems and provide a registry services management platform that is built according to an acceptable global standard will encourage rapid uptake, multiple registrations and lower cost of domain names.

iv.   As already explained, DotAfrica gTLD is not a community-based TLD, and as such will not be subjected to any community-based restrictions in its registration policies. Rather, as a standard geographic gTLD serving diverse needs and purposes, it will have open registration policies that would enable it attract a very large population of users and registrants from the global Internet community.
Therefore, in keeping with the spirit of global access, innovation, and competition promoted by the TLD and by the applicant, DCA DotAfrica Registry believes that the registration of domains should be open to all parties for legitimate purposes.  Due to the specific and descriptive nature of the string, it is expected that registrations will be relevant to the nature of the TLD; however, Applicant does not wish to impose validation criteria as it believes it would only increase cost and restrict innovation – which goes against ICANN’s and Applicant’s goals for the TLD.

DCA DotAfrica Registry does, however, intend to enforce an Acceptable Use Policy to ensure that the zone remains stringently protected from illegal content or activity, and the UDRP, URS, and all other ICANN-required rights protection mechanisms will form an integral part of the domain registration policy compliance process. Applicant will also provide additional rights protection mechanisms beyond ICANNʹs requirements as set forth in written answers to questions 26, 28, and 29. To minimize abusive registrations, DCA DotAfrica Registry Services will adopt an Acceptable Use Policy that will allow it to cancel the registration of a domain name if the name is in violation of the Policy. Additionally, Applicant will undertake communications efforts to encourage reporting and execute rapid takedown of domains in violation of the Acceptable Use policy.

As further detailed in the responses to questions 28 and 29, DCA DotAfrica Registry will implement all rights protection mechanisms required by ICANN (including but not limited to the URS and the UDRP) and will additionally operate a Sunrise period for Trademark holders prior to General Availability (again, in accordance with all ICANN rules). Additional rights protection mechanisms, beyond ICANN requirements, are described in response to questions 26, 28, and 29.   

Note that the Registration Policies also references the Acceptable Use Policy, ICANN Consensus Policies (in effect), and any other policies that may be adopted by DCA DotAfrica Registry or ICANN that would become applicable to DotAfrica gTLD.
A complete copy of the intended Eligibility and Acceptable Use Policy can be found in response to Question 29 (in Section 29.9).

V:  There will be various measures implemented in the TLD for protecting the privacy or confidential information of registrants and users.   In various jurisdictions, Data Protection and Privacy laws exist to keep citizen and consumer private information confidential and not publicly accessible, and protected from abuse or being stolen or illegally distributed for marketing purposes. Moreover, unauthorized disclosure of citizen’s private information exposes such victims to various social, economic and legal vulnerabilities. 

According to ICANN, the use of personal data must be limited to the purpose for which it is collected; and as per the new gTLD Registry Agreement, we shall do our utmost to ensure that this requirement is satisfied, and that the personal data of users and registrants will be protected, not publicized, and used only for the purpose for which it has been collected.

For registrations under DotAfrica, only non-sensitive information of registrants and users will be made public.  Reasonable steps will be taken to protect any personal data collected as specified under Article 2.17 of the new gTLD Registry Agreement.  

Furthermore, DCA DotAfrica Registry shall:
1.	Notify Registrar of the purposes for which registrant Personal Data submitted by Registrar is collected, the intended recipients of such Personal Data, and the mechanism for access to and correction of such Personal Data;
2.	Take reasonable steps to protect them from loss, misuse, unauthorized disclosure, alteration or destruction; shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars;
3.	May from time to time use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is compatible with the notice provided to registrars;
4.	Not use the information stored regarding the domain name holders in the DotAfrica Registry system for any spamming or marketing purposes.

VI:  DCA’s promotional campaign for sensitization and awareness creation of ICANN’s new gTLD programme has helped to mainstream DotAfrica as the principal Internet discourse within Africa in recent years. This has been aided by regular email campaigns to circulate analyses and commentaries on topical Internet DNS issues, press releases, dissemination of quarterly newsletters, published blog articles; coupled with video productions, television interviews, sponsored exhibitions and advertisement on popular Internet governance platforms and conferences such as ICANN and IGF. All these have been employed to effectively communicate the message of the DotAfrica gTLD. 

DCA has used these communication tools to explain the potential benefits of DotAfrica gTLD, and inform people on the positive impact this will have on the innovative use of domain names when the DotAfrica domains become generally available. When the gTLD is delegated, these forms of outreach will be further strengthened with a strong sales and marketing effort, and initiatives such as Yes2DotAfrica campaign (http:⁄⁄www.dotconnectafrica.org⁄yes-campaign⁄join-campaign⁄), generation.africa (http:⁄⁄www.prlog.org⁄11681274-generationafrica-on-their-high-at-the-6th-igf-held-in-nairobi-kenya.html), and miss.africa (http:⁄⁄www.dotconnectafrica.org⁄yes-campaign⁄miss-africa⁄). These initiatives shall be further powered by an active social media presence on micro-blogging sites such as Twitter and ‘friendship⁄conviviality’ sites such as Facebook which attract a younger Internet user demographic.

As a result of concerted promotional and campaign activities undertaken by DCA during the past couple of years, DotAfrica received a lot of press coverage in different local, regional and global news media.  Such press coverage has been organized into a media briefing kit, which may be found at: http:⁄⁄www.dotconnectafrica.org⁄press-room⁄press-kit⁄  and http:⁄⁄www.dotconnectafrica.org⁄press-room⁄global-media-coverage⁄

As part of its outreach and communications efforts, DCA has made over 56 press releases and Executive Briefings, and received over 79 global press coverage in print and electronic media, in addition to press coverage in over 21 foreign language news media; reaching a potential audience of nearly 100 million people globally. Such archived press releases and other media campaign iinfo are available at: 
http:⁄⁄www.dotconnectafrica.org⁄yes-campaign⁄accomplishments⁄ and http:⁄⁄archive.constantcontact.com⁄fs053⁄1102516344150⁄archive⁄1103885604203.html

DCA already employed a combination of useful communication tools and strategies to achieve significant successes in the course of promoting DotAfrica during the last few years (See http:⁄⁄www.dotconnectafrica.org⁄major-milestones⁄).   

It is envisaged that when the DotAfrica gTLD is delegated such efforts shall be re-doubled to enable DCA achieve its projected benefits.

I: . DCA as the applicant for the DotAfrica gTLD has taken great care to develop the most fair registration policy possible. It will offer a phased launch consistent with ICANN requirements to ensure the protection of Trademark holders and the satisfaction of potential registrants. According to the Applicant’s Guidebook, all new gTLD registries will be required to use the Trademark Clearing House to support its pre-launch or initial launch rights protection mechanisms. According to ICANN, these RPMs, at a minimum must consist of a Trade Marks Claims Service and a Sunrise Process.

The ICANN-mandated Sunrise period open to Trademark holders will precede a Landrush or Premium Name availability period during which applicants are able to register their interest for various domain names. The Landrush phase will be followed by General Availability, during which time domain names will become available for purchase by any entity.

Multiple applications for a particular domain name would be resolved depending on the determination of what the domain name represents.   For a standard domain name, it would be necessary to first of all ensure that the legal rights of third parties have been fully protected, for example, if there are no conflicting trademark claims, multiple applications will be resolved on a first-come⁄first-served basis if such names are not considered as premium domain names. However, if such multiple applications for a particular domain name appertain to what the DCA DotAfrica gTLD Registry considers as a ‘premium domain name’, then, after also ensuring that the legal rights of third parties have been fully protected, an auction process would naturally be used to resolve such situations. The procedures for conducting the auction will be defined and agreed with the Auction House that will be retained to provide the service of selling (auctioning) the premium domain names.

 It is expected that an auction will help raise sizable revenues accruing to the coffers of DCA Registry Services that will assist in funding the non-profit⁄charitable objectives of DCA Trust. 

It is important to stress that all post-Sunrise registrations at the time of General Availability will be subject to a first come first served basis.

II:   In our estimation, cost benefits for users and registrants starts with a standardized and competitive pricing model. The prices for standard domain names offered during the time of General Availability will be similar to the price of gTLD domain names such as dotcom, dotnet, dotorg that are readily affordable by a large majority of domain name registrants in Africa. Domain name pricing will be reviewed in accordance with the policies set by the Registry, subject of course to the mandatory ICANN-approved guidelines governing the price increases of domain names⁄renewal pricing.

To increase domain name registrations, different cost benefit and cost saving incentives will be used to attract registrants to register domain names in the TLD. This will be part of the marketing and sales strategy. There will be regular promotions for registrars, and various incentives will be offered such as special introductory discounts, bulk registration discounts, and product service packages that combine for example, domain names with certain number of web-email addresses, FTP accounts, etc. However, such promotional activities will be performed for short durations, for example over a 30-day period.

The examples of promotional opportunities that could be readily exploited are as follows:

1.	During the general availability period shortly after the Sunrise period, DotAfrica domain names will be offered at highly discounted prices in the first few days via promotional campaigns on a first come first served basis
2.	DCA Registry will enter into agreements with DotAfrica domain name registrars to offer discounts on bundles of DotAfrica domain names sold together with ccTLD domain names in line with our goal of cross marketing DotAfrica domain names with ccTLDs domain names.  For example, DCA DotAfrica Registry Services will enter into partnerships with a given country-code TLD such as Kenyan ccTLD - .ke (or Ethiopian ccTLD - .et) to sell DotAfrica domain names at a discounted price of say, $5 if a customer buys them as a bundle with a .ke ccTLD domain name. Similarly, a customer who buys a .ke domain name will also get the chance to buy a DotAfrica domain name at $5. This will happen shortly after the Sunrise period and will last for a limited duration subject to agreements reached with participating ccTLD registries, DotAfrica registrars and resellers.
3.	DCA Registry will also launch domain promotions during events such as the African Cup of Nations, and  several major continental sports meetings like athletics (e.g. All African Games), volleyball, basketball, golf, etc. that will be valid throughout the eventʹs period during which DotAfrica domain names will be acquired at discounted prices.
4.	There will be generous discounts on bulk purchases of DotAfrica domain names that meets a certain threshold, for example $60. 
5.	Other promotions of benefit to registrant’s will include offering branded DotAfrica merchandise such as T-shirts, flash disks, and other promotional gift items to winners in a draw.
6.	Special DotAfrica Football Promotions (Africans have a passion for football hence this provides a natural avenue for branding and promotional activities) e.g. offering hugely discounted DotAfrica domain names whenever an African team is playing, during major football tournaments such as the African Champions League where African teams are participating.
7.	DCA Registry will launch the DotAfrica Pioneers Program that will award 100 Premium Domain names with 2-year registrations for free to 100 Pioneers from Africa with proposals on how to develop those domain names for the benefit of Africa. The guidelines for the Pioneers Program will be published soon after the completion of the Sunrise period.

It is therefore anticipated that individual Internet users in Africa shall constitute the largest category that stands to benefit most from the introduction and general availability of the DotAfrica generic Top Level domain names for the following reasons:

a)	DotAfrica affords them an opportunity to acquire the best and most descriptive domain names to brand products and services.
b)	Competitive pricing that is commensurate with the income levels of most Africans. The intended registration cost of US$10.00 per standard domain name will no doubt improve affordability when compared to the prices offered by ccTLDs for the country level domain names.
c)	The DotAfrica generic Top-Level Domain will bring global best practice in DNS registry management to the African continent that simplifies registration via the Extensible Provisioning Protocol (EPP) registry system.

One cost benefit for users and registrants is the innovative form of payment that has been proposed for the settlement of domain name service transactions. In a continent where card banking facilities and the use of credit⁄debit cards are not widespread, electronic payments for e-commerce is often an important hurdle to overcome. With this recognition therefore, DCA DotAfrica Registry will use normal online and banking payment methods, and at the same time, in cooperation with registrars and technology service providers, DCA DotAfrica Registry will work strenuously to integrate mobile payment systems such as MPESA (developed by Safaricom and widely used in Kenya) across the entire registrar and domain reseller network within the first three years.  This will greatly expand payment options and access as well as lead to increase of registration of domain names since Africa is still mostly a mobile continent and with the aim of making domain name purchase and renewal transactions as convenient and painless as possible whilst reducing transaction costs. DCA and Safaricom have already entered into a framework Memorandum of Understanding which accepts that the MPESA mobile payment system developed by Safaricom Ltd. for payment⁄money transfers within Kenya could be utilized as a payment system for the settlement of DotAfrica domain name sales transactions, and also commits both parties to further develop this model and used in other markets within the African continent. 

In addition to the above, other anticipated benefits would accrue to different potential stakeholders based on the strategic partnerships that DCA intends to establish with ISPs, IXPs, Association of ccTLDs in Africa, etc.

Internet Service Providers (ISPs) and IXPs:  DCA intends to build strategic partnerships with over 200 ISPs and the 21 IXP’s  which exist in Africa and offer a variety of services including website hosting, domain registration services, including providing name servers to  new domain name registrants and future sales channels⁄shop fronts for DotAfrica domain names.   DCA intends to use successful venture to market its domains and also offer services to the niche currently not reached by other telephone networks.

Global and African Registrars and Registrar Associations;  DCA will work closely with the developed ICANN accredited registrars within the continent to build a cross-marketing relationships that will result in a great increase in the number of DotAfrica domain sales within the continent. Global Registrars such as United Domains among many others already understand the huge potential of the African domain name market and have been actively involved in disseminating information on DCA and undertaking pre-registration of DotAfrica domain names.

Since a core aim of DCA’s Charitable Mission and Purpose is to channel any surplus financial proceeds from the DotAfrica gTLD Registry Services operation to the DCA Trust Fund to invest in, and develop Internet social development projects in Africa, it is also envisaged that some of the funds earmarked for such purposes shall be availed from the Trust Fund and used to provide financial support to Registrars in Africa in order to assist in building their technical capacity in domain names sales and marketing.

ccTLD Managers and Associations: The African Domain Name industry is typified by country code Top-Level Domain (ccTLD) registry operators with very low domain name registration volumes. When compared to the number of Internet users, there is a huge untapped potential. The problems faced by the African Domain Name industry include:

1.	The ccTLD “crisis” in Africa: Lack of Awareness of the potential of African ccTLDs
2.	Steep Pricing - The high cost of ccTLD Domain Names:  African ccTLD Domains cost an average of $80 from our estimation, leading to the low uptake of domain names.   Thus users prefer to obtain the other generic Top Level Domain Names from North American registries which costs about US$10.00 on average. 
3.	Technical issues DNS Infrastructure: African domain registrants who resort to ccTLD domains normally face archaic or manual domain registration procedures that take 24 hours to a few weeks in some cases. 
4.	Dispute Resolution in African ccTLD Namespaces: There are no legal structures in many African countries that can handle domain name dispute resolution. Copyright laws are weak in most countries, and legal systems in most countries need to be reformed.
5.	Registry Governance. There are issues with ccTLD management and governance policies where there is still a level of government control in some instances and registration policies sometime reflect governmental interference.
6.	With the rapid depletion of most descriptive domain names that have already been registered by Internet users in regions with advanced Internet infrastructures, the African Internet users are faced with a choice of registering second rate domain names which are long and not easy to remember.

It is therefore anticipated that DCA DotAfrica Registry Services as the prospective registry operator of the DotAfrica gTLD will address all of the aforementioned short-comings, and to this end, proposes to have a close working relationship with the existing ccTLD managers and association of TLDs in Africa. (See for example,  .http:⁄⁄www.circleid.com⁄posts⁄20111217_dotconnectafrica_expresses_commitment_to_work_with_african_cctlds⁄ ).   This will be a critical entry point that would enable the faster introduction of DotAfrica gTLD domain names to the individual countries, and will also be used in a cross marketing model to avail the DotAfrica domain names to the ccTLD registries.  

DCA has already outlined a win-win outcome for African ccTLD managers who responded enthusiastically towards forging a working relationship that will not only avail DotAfrica domain names and increase the relevance of the struggling ccTLD’s that suffer from operational, financial and governance issues. The DCA Registry has proposed a cross marketing model that will see partial revenue proceeds from the DotAfrica namespace reinvested in strengthening African ccTLDs with weak administrative and technical infrastructure. DCA hopes to assist in building the capacity of African ccTLDs by utilizing any surpluses accruing to its Trust Fund for the achievement of such objectives. Finally, in our measures to protect geographic domain names at the second level, we have also proposed assigning country names in any language including the ISO3166 two letter codes to their respective ccTLD registries for their use in branding their country’s resources or developing new business around those domains under the new DotAfrica gTLD.

Without prejudice to the foregoing, it is important to clarify that, In keeping with its mission and purpose of ensuring equality⁄non-preferential treatment in customer service delivery, DCA DotAfrica gTLD registry intends to focus only on providing registry services for the delegated DotAfrica gTLD and will not be encumbered, for example, like a ccTLD registry service that is also wishing to apply for, and administer a continental gTLD. The potential conflict of interest would be rather obvious and such a ccTLD registry that, on one hand is dedicated to serving a particular country domain market, will find that its country-specific mandate would conflict with that of running the registry operation of a continental gTLD in the overall delivery of its customer services. As an independent organization, DCA believes that a ccTLD registry with governmental connections and ownership (which would make it lack any broad independence since it is on a national mission) should not be seen as also serving a continental gTLD.

III:  The new gTLD Registry Services Agreement with ICANN has a term of ten (10) years, and since all domain name registrations within the TLD will be subject to the gTLD registry services agreement with ICANN, registrars will also be offered the option of obtaining initial domain name registrations that will not exceed ten (10) years. Due to the effect of possible inflation and other cost escalations that could be imposed by macro-economic conditions outside the control of the registry operator, for example fluctuations in the global price of energy that affects transportation and freight costs, and the price of different commodities, possible escalations or adjustments in the price of domain names are inevitable over a 10-year period. However, these would be managed in such a way that any price increases are justified and gradual. If there are any planned increases in the price of domain names, registrants will be given a 6 month to 1-year prior notification, and the general prevailing rate of inflation within the economy will be used to determine the magnitude of price escalations but in no event will this exceed 5 – 10 per cent per annum.   To ensure that any revisions to agreements with registrars are in conformity with the stipulations of the new gTLD Agreement, any such revisions will be approved in advance by ICANN. Similarly, any planned price increases for registry services will be first approved in advance by ICANN before registrars are notified, and the price increases implemented. 

To ensure that proper processes are followed and nothing is done outside the oversight of ICANN, all Registry-Registrar Agreements and relations between registrars registering domain names in the TLD and the registry operator will be governed by the stipulations contained in Article 2.9 of the ICANN gTLD Registry Agreement. Similarly, the pricing for registry services and any price increases shall be subject to the stipulations contained in Article 2.10 of the ICANN gTLD Registry Agreement. For example, there will be uniform pricing for renewals of domain name registrations for all registrars, and the registry operator will ensure that there will be no abusive and⁄or discriminatory pricing practices that will be imposed on registrars. In the same vein, no arbitrary price increases or unnecessary costs will be imposed on consumers.

Without prejudice to any of the aforementioned, as per Article 6.4 of the new gTLD Agreement any fees adjusted at ICANN’s discretion will be proportionately and transparently passed on to registrars and users at the time of communicating renewal pricing to users and registrants.

DCA DotAfrica Registry Services has considered the relevant provisions of the new gTLD Registry Agreement, the GAC Advice ʺGAC Principles Regarding new TLDsʺ and the procedures adopted by other gTLD registries and intend to use the procedure described below with regards to protection of geographic names in the DotAfrica gTLD. 

Prior to the launch of DotAfrica gTLD, DCA DotAfrica Registry Services will compile a list of country and territory names that are subject to reservation at the second level. 

Pursuant to the specification provided in ICANNʹs Applicant Guidebook, the list will include country and territory names based on the following internationally recognized lists: 

•	the short form (in English) of all country and territory names contained on the ISO 3166-1 list; 
•	the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and 
•	the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; 

As the above documents get updated from time to time, the exact list of reserved names will be compiled shortly before the launch of DotAfrica gTLD to account for any updates. The list of reserved names will be published on the Registry website. 

Reservation of specific country and territory names may be released to the extent that Applicant reaches agreement with the applicable government(s). 

From ICANN new gTLD Applicant’s Guidebook, protections at the second level have been left to the individual registries. DCA DotAfrica Registry Services will institute the following specific measures in order to protect geographic names.

Country names and alpha-2 codes representing countries
All two letter (alpha-2 code listed in ISO 3166-1 standard); three letter country codes (alpha-3 code listed in the ISO 3166-1 Standard or a translation in any language); short- or  long-form name associated with a code that has been designated as ʹExceptionally reserved” by the ISO 3166 Maintenance Agency; a name that is a separable component of a country name designated on the “Separable Country Names” list or is a translation of a name appearing on the list in any language or a permutation or transposition of all the above will all be treated as blocked names. In other words, Alpha-2 codes representing countries shall not be used to register domain names directly under the DotAfrica gTLD in the second level. 

DCA DotAfrica Registry Services will publicly avail the list of blocked geographical names that cannot be registered under DotAfrica gTLD after consultations with national authorities to guide registrants on the names that have been blocked.

Countries within Africa and beyond will be required to request that their official name and the name under which they are commonly known (in all languages) will not be registered directly under the DotAfrica gTLD otherwise than by their national government. Countries that are outside the African continent will be enabled to block their official names and the names (in all languages) under which they are commonly known on request and at minimal cost, so that they can be registered by those countries or parties authorized by those countries. Notifications will be sent to all countries and territories by DCA DotAfrica Registry Services to this effect.

Countries as listed in the UNESCO regions or appearing on the “Composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings list will be authorised to designate an operator that will register as a domain name its official name and the name under which it is commonly known (in all languages). Otherwise those names will be blocked at no⁄minimal cost. Similarly, the major regional and international institutions on the continent of Africa and around the world will be authorised to select domain names (in all languages) for use by the institutions, and to designate the operator of those domain names. The same will also apply to all the names of the major cities in the world, world heritage sites, landmark features, etc.

Second level domain name for geographical and geopolitical names
Countries will be expected to identify and notify DCA DotAfrica Registry Services on a limited list of broadly-recognised names (in all languages) with regard to geographical and⁄or geopolitical concepts which affect their political or territorial jurisdiction. Such lists include names that could either not be registered or which could be registered only under the second level domain in accordance with the public policy rules. The names included in these lists are not subject to the first-come first-served principle. DCA DotAfrica Registry Services will send out notifications to all the relevant authorities in all countries and territories in the world to this effect. Such names will be blocked by DCA DotAfrica Registry Services at minimal cost. To this end, each country will be expected to send to DCA DotAfrica Registry Services, two months to the commencement of the Sunrise Period, a list of those names that should not be registered. 

Protection of International Olympic Committee and the Red Cross⁄Red Crescent Names in the Top and Second Level in the DotAfrica gTLD Namespace

In addition to the protection of geographic names, DCA DotAfrica Registry Services is aware of GAC and GNSO advice regarding the protection of Olympic and Red Cross ⁄ Red Crescent names. 

According to a recent ICANN published document, “the International Olympic Committee (IOC) and the International Red Cross⁄Red Crescent Movement (RC⁄RC) have asked that their Olympic and Red Cross names—such as Olympic and Olympiad, and Red Cross and Red Crescent—be protected against registration in the top and second levels of an expanded domain name system. The ICANN GAC endorsed these proposals and communicated its support to the ICANN Board” (See for example, QUESTIONS AND ANSWERS RE: PROTECTING THE OLYMPIC AND RED CROSS⁄RED CRESCENT NAMES IN ALL NEW GTLDS” - a policy document published by ICANN).

In light of the fact that the ICANN Policy Guideline has been published for the type of unique protections afforded the International Olympic Movement and the Red Cross, some names associated with International Olympic Committee (IOC) and the International Red Cross and Red Crescent Societies, International Federation of the Red Cross, etc. shall be protected at the top and second levels in the entire DotAfrica gTLD namespace in all languages. 

These names will be reserved and protected from registration (apart from International Red Cross and the International Olympic Movement and affiliated organizations) as the Government Advisory Committee (GAC) and the GNSO work on an agreeable policy that does not deny users legitimate uses of these names in the DotAfrica gTLD namespace while also ensuring that the rights of these organizations are fully protected regarding these Olympic and Red Cross names.

At the top level, the Olympic and Red Cross names shall also be protected against confusingly similar strings, such as: 

i.	.OLYMPICS 
ii.	.OLYMPIK 
iii.	.OLYM-PIC 
iv.	.RED-CROSS 
v.	.REDKROSS 

At the second level, the Olympic and Red Cross names shall be protected: 

•	Against registration of identical matches; and 
•	In the six UN languages with an encouragement to registry operators to extend to other languages (e.g. those providing protection either via international legal instrument or national law).

DCA DotAfrica Registry Services will reserve any names at the second level as required by GAC ⁄ GNSO policy (which, as at the time of writing, has not been finalized). If such a policy is not agreed and formalized prior to the launch of the DotAfrica gTLD, DCA Registry Services will temporarily reserve all required and recommended names as per the most recent GAC ⁄ GNSO advice so as to ensure protection of the IOC and Red Cross movement.

Finally, since DCA DotAfrica Registry Services also intends to offer IDNs support for Arabic at the second level, it would be possible to provide protection for the Olympic and Red Cross names in Arabic at the second level of DotAfrica gTLD.

DotConnectAfrica (DCA) has chosen CentralNic as the registry infrastructure provider for .africa. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed .africa TLD registry (answers to questions 23 – 44) therefore refers to the DCA DotAfrica Registry - a new registry to be installed in and operated from Nairobi, Kenya, replicating CentralNic’s registry infrastructure systems and set up and managed under CentralNic’s supervision.

DCA and CentralNic hereby explicitly confirm that all registry services stated below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described above, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the .africa TLD;(iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in .africa as required by the Registry Agreement.
There are no other products or services, except those described above that the Registry Operator will provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of DCA being designated as the Registry Operator.

Any changes to the registry services that may be required at a later time in the course of DCA operating the .africa registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.
DCA proposes to operate the following registry services, utilising CentralNicʹs registry system as the model for the new Registry, to be built and managed with the support and under the supervision of CentralNic:

23.1. Receipt of Data From Registrars
The DCA DotAfrica Registry will operate a Shared Registry System (SRS) for .africa. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web based Registrar Console. Registrars will uses these interfaces to provide registration data to the registry.
The SRS will be hosted in the primary operations centre in Nairobi, Kenya. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in Safaricom’s flagship African data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.

CentralNicʹs existing SRS system currently supports more than 250,000 domain names managed by over one 1,500 registrars, and this system will be replicated for the DCA DotAfrica Registry. The DCA DotAfrica Registry will have effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of .africa and provide additional capacity during periods of elevated activity (such as during Sunrise periods).

The SRS and EPP systems are described more fully in §24 and §25. The Registrar Console is described in §31.
EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:
1. Registry Grace Period Mapping - compliant with RFC 3915
2. DNSSEC Security Extensions - compliant with RFC 5910
3. Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https:⁄⁄github.com⁄wil⁄EPP-Launch-Phase-Extension-Specification⁄blob⁄master⁄draft-tan-epp-launchphase.txt
More information on EPP extensions is provided in §25.
The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:
 Uniform Domain Name Dispute Resolution Policy
 Inter-Registrar Transfer Policy
 Whois Marketing Restriction Policy
 Restored Names Accuracy Policy
 Expired Domain Deletion Policy
 AGP Limits Policy

23.2. Provision to Registrars of Status Information Relating to the Zone Servers
CentralNic will operate a communications channel to notify registrars of all operational issues and activity relating to the DNS servers which are authoritative for .africa. This includes notifications relating to:
1. Planned and unplanned maintenance;
2. Denial-of-service attacks;
3. unplanned network outages;
4. delays in publication of DNS zone updates;
5. security incidents such as attempted or successful breaches of access controls;
6. significant changes in DNS server behaviour or features;
7. DNSSEC key rollovers.
Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.

23.3. Dissemination of TLD Zone Files
CentralNic will make .africa zone files available via the Centralized Zone Data Access Provider according to specification 4, section 2 of the Registry Agreement.
DCA will enter into an agreement with any Internet user that will allow such user to access an Internet host server or servers designated by DCA and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). DCA will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.

DCA, through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.

DCA will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. DCA will grant the user a non-exclusive, non-transferable, limited right to access DCA’s Zone File FTP server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using FTP, or other data transport and access protocols that may be prescribed by ICANN.
DCA will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS.

DCA, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. DCA will allow users to renew their Grant of Access.

DCA will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

23.4. Operation of the Registry Zone Servers
The .africa zone will be served from CentralNicʹs authoritative DNS system. This system has operated at 100% service availability since 1996 and has been developed into a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNicʹs DNS system includes nameservers in more than forty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.

The DNS system is described further in §35.

23.5. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
The DCA DotAfrica Registry will operate a Whois service for .africa. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912. The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for .africa domain names. The Whois service will return records in a standardised format which complies with ICANN specifications.
CentralNic will provide access to the Whois service at no cost to the general public.

CentralNicʹs Whois service supports a number of features, including rate limiting to prevent abuse, privacy protections for natural persons, and a secure Searchable Whois Service. The Whois service is more fully described in §26.

Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, CentralNic will implement such alternative specifications as soon as reasonably practicable.

23.6. DNSSEC
The .africa zone will be signed by DNSSEC. CentralNic uses the award-winning signer technology from Xelerance Corporation. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in §43. The DCA DotAfrica Registry will use the same technology.

CentralNicʹs DNSSEC implementation complies with RFCs 4033, 4034, 4035, 4509 and follows the best practices described in RFC 4641. Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155. The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910). CentralNic will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. CentralNic will publish its DPS following the format described in the “DPS-framework” Internet Draft within 180 days after that draft becomes an RFC.

23.7. Rights Protection Mechanisms
DCA will provide all mandatory Rights Protection Mechanisms that are specified in the DCA Guidebook (version 11 January 2012), namely Trademark Claims Service (section 6.1) and Sunrise service (section 6.2). All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in .africa. More information is available in §29.

In addition to such RPMs, DCA may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. DCA will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in .africa. DCA shall implement these mechanisms in accordance with requirements established by ICANN each of the mandatory RPMs set forth in the Trademark Clearinghouse.

The ʺLaunchPhaseʺ EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for .africa. Depending on the final specification for the Trademark Claims Service (details of which have not yet been published), an additional EPP extension may be required in order to implement this service. If this is necessary, the extension will be designed to minimise its effect on the operation of the SRS and the requirements on registrars, and will only be in place for a limited period while the Trademark Claims Service is in effect for .africa.

23.8. Registrar Support and Account Management
The DCA DotAfrica Registry will leverage CentralNic’s 16 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for .africa registrars. CentralNicʹs experienced technical and customer support personnel will recruit and train local staff in Nairobi to assist .africa registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone and a web based support ticketing system.

23.9. Reporting to ICANN
DCA and CentralNic will compile and transmit a monthly report to ICANN relating to .africa. This report will comply with Specification 3 of the New gTLD Registry Agreement.

23.10. Personnel Resources of CentralNic
The technical, operations and support functions of the registry will be performed in-house by DCA Africa Registry’s fully trained technical personal and will be supported by CentralNicʹs personnel. These personnel perform technical, operations and support functions on a full-time basis.

23.10.1. Technical Operations
Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are co-ordinated.

The DCA DotAfrica Registry intends to maintain a Technical Operations team consisting of the following positions. These persons will be responsible for managing, developing and monitoring the registry system for .africa on a 24x7 basis:
 Senior Operations Engineer(s)
 Operations Engineer(s)
 Security Engineer

23.10.2. Technical Development
The Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone file generation, data escrow, reporting, backoffice and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team and will be provided to The DCA DotAfrica Registry together with the appropriate training to ensure the optimal operations of the registry.

CentralNic intends to maintain a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software which will support The DCA DotAfrica Registry in operating the .africa TLD:
 Senior Technical Developer x 2
 Technical Developer x 3

23.10.3. Technical Support
Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.

1st line support issues are normally dealt with by these personnel. 2bd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.

The DCA DotAfrica Registry’s Technical Support team will be trained in accordance with CentralNic Ltd standards and will consist of the following positions:
 Operations Manager
 Support Manager
 Support Agent(s)

23.10.4. Key Personnel
The DCA DotAfrica Registry will have access to the following key personnel from CentralNic Ltd.

23.10.4.1. Gavin Brown - Chief Technology Officer
Gavin has worked at CentralNic since 2001, becoming CTO in 2005. He has overall responsibility for all aspects of the SRS, Whois, DNS and DNSSEC systems. He is a respected figure in the domain industry and has been published in several professional technical journals, and co-authored a book on the Perl programming language. He also participates in a number of technical, public policy and advocacy groups and several open source projects. Gavin has a BSc (hons) in Physics from the University of Kent.

23.10.4.2. Jenny White - Operations Manager
Jenny has been with CentralNic for nine years. Throughout this time she has expertly managed customer relations with external partners, prepared new domain launch processes and documentation, managed daily support and maintenance for over 1,500 Registrars, carried out extensive troubleshooting within the registrar environment to ensure optimum usability for registrars across communication platforms, handled domain disputes (from mediation to WIPO filing), and liaised with WIPO to implement changes to the Dispute Resolution Procedure when necessary.

23.10.4.3. Adam Armstrong - Senior Operations Engineer
Adam has recently joined CentralNic as Senior Operations Engineer. In this role he is responsible for the operation and development of the system and network infrastructure for the registry system. Adam has previously worked at a number of large UK ISPs including Jersey Telecom and Packet Exchange. He is also the lead developer of Observium, a network management system used by ICANN (amongst others). Adam has brought his strong knowledge of network design, management and security to bear at CentralNic and will oversee the operation of the SRS for .africa.

23.10.4.4. Milos Negovanovic - Senior Technical Developer
Milos has worked at CentralNic since 2009. He has a background in building rich web applications and protocol servers. His main areas of responsibility are the Registrar Console, EPP and backoffice functions.

23.10.4.5. Mary OʹFlaherty - Senior Technical Developer
Mary has worked at CentralNic since 2008. She plays an integral role in the ongoing design, development and maintenance of the registry as a whole and has specific experience with the EPP system, Registrar Console and Staff Console. Mary has a 1st class Honors degree in Computer Science from University College Cork and has previously worked for Intel and QAD Ireland.

23.10.5. Job Descriptions
CentralNic will recruit a number of new employees to assist The DCA DotAfrica Registryto perform technical duties in relation to .africa. The following job descriptions will be used to define these roles and select candidates with suitable skills and experience.

23.10.5.1. Operations Engineer
Operations Engineers assist in the maintenance and development of the network and server infrastructure of the registry system. Operations Engineers have a good knowledge of the TCP⁄IP protocol stack and related technologies, and are familiar with best practice in the areas of network design and management and system administration. They should be competent system administrators with a good knowledge of Unix system administration, and some knowledge of shell scripting, software development and databases. Operations Engineers have 1-2 yearʹs relevant commercial experience. Operations Engineers report to and work with the Senior Operations Engineer, who provides advice and mentoring. Operations Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.

23.10.5.2. Security Engineer
Security Engineers enhance and assure the security of the registry system. Day-to-day responsibilities are: responding to security incidents, performing analysis and remediating vulnerabilities, conducting tests of access controls, refining system configuration to improve security, training other team members, reviewing source code, maintaining security policies and procedures, and gathering intelligence relating to threats to the registry. Security Engineers have 1-2 yearʹs relevant commercial experience. This role reports to and works with the Senior Operations Engineer and CTO. Security Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.

23.10.5.3. Technical Developer
Technical Developers are maintain the software which supports the registry. Day-to-day responsibilities are developing new systems in response to requests from management and customers, correcting bugs in existing software, and improving its performance. Technical Developers have a good knowledge of general programming practices including use of revision control and code review systems. Developers have a good awareness of security issues, such as those described in advisories published by the oWASP Project. Developers have at least one yearsʹ commercial experience in developing applications in programming languages such as PHP, Perl, and Python, although knowledge of domain technologies such as EPP and DNS is not critical. Technical Developers work as part of a team, with advice and mentoring from the Senior Technical Developers, to whom they report.

23.10.6. Resource Matrix
To provide a means to accurately and objectively predict human resource requirements for the operation of the registry system, CentralNic has developed a Resourcing Matrix, which assigns a proportion of each employeeʹs available time to each aspect of registry activities. These activities include technical work such as operations and development, as well as technical support, registrar account management, rights protection, abuse prevention, and financial activity such as payroll, cash collection, etc. This matrix then permits the calculation of the total HR resource assigned to each area.
Although DCA DotAfrica Registry will operate on a dedicated registry environment, the .africa registry will be operated identically to CentralNic’s existing registry by the same team, and will benefit from an economy of scale with regards to access to CentralNicʹs resources.
CentralNicʹs resourcing model assumes that after launch, the ʺdedicatedʺ resourcing required for .africa (ie, that required to deal with issues related specifically to .africa and not to general issues) will be equal to the proportion of the overall registry system that .africa will use. After three years of operation, the optimistic projection for .africa states that there will be 600,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore .africa will require 13% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .africa are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .africa for at least the first 18 months of operation.

24.1. Registry Type
The DCA DotAfrica Registry will operate a ʺthickʺ registry based on that of CentralNic’s infrastructure, in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See §25 for further details.

24.2. Architecture
Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in §32.

The SRS is hosted DCA DotAfrica Registry’s primary operations centre in Nairobi, Kenya. It will be connected to the public Internet via two upstream connections, one of which is provided by Safaricom. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers that connect to the firewalls which implement access controls over registry services.

Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit ethernet switches implementing Spanning Tree Protocol.

The registry system will implement two interfaces to the SRS: the standard EPP system (described in §25) and the Registrar Console (described in §31). These systems will interact with the primary registry database (described in §33). The database is the central repository of all registry data. Other registry services also interact with this database.

An internal ʺStaff Consoleʺ will be used by DCA DotAfrica Registry personnel to perform management of the registry system.

24.3. EPP System Architecture
A description of the characteristics of the EPP system is provided in §25. This response describes the infrastructure which supports the EPP system.
A network diagram for the EPP system is provided in Figure 24.2. The EPP system is hosted at the primary operations centre in Nairobi. During failover conditions, the EPP system operates from the Isle of Man Disaster Recovery site (see §34).

DCA DotAfrica Registry’s EPP system will have a three-layer logical and physical architecture, consisting of load balancers, a cluster of front-end protocol servers, and a pool of application servers. Each layer can be scaled horizontally in order to meet demand.

Registars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.

The load balancers pass sessions to the EPP protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (“hello”, “login” and “logout”) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.
Application servers receives EPP commands as plain HTTP requests, which are handled using application business logic. Application servers process commands and prepare responses which are sent back to the protocol servers, which return responses to clients over EPP sessions.

Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontalscaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.

The DCA DotAfrica Registry EPP system will comprise of the following systems:
 4x load balancers (1U rack mount servers with quad-core Intel processors, 16GB RAM, 40GB solid-state disk drives, running the CentOS operating system using the Linux Virtual Server [seehttp:⁄⁄www.linuxvirtualserver.org⁄])
 8x EPP protocol servers (1U rack mount servers with dual-core Intel processors, 16GB RAM, running the CentOS operating system using Apache and mod_epp)
 20x application servers (1U rack mount servers with dual-core Intel processors, 4GB of RAM, running the CentOS operating system using Apache and PHP)

24.3.1. mod_epp
mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found at http:⁄⁄sourceforge.net⁄projects⁄aepps. CentralNic uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into HTTP requests which can then be handled by backend application servers, which will be replicated for The DCA DotAfrica Registry.

24.3.2. mod_proxy_balancer
mod_proxy_balancer is a core Apache module. Combined with the mod_proxy module, it implements a load-balancing reverse proxy, and includes a number of load balancing algorithms and automated failover between members of a cluster. CentralNic uses mod_proxy_balancer to distribute EPP commands to backend application servers, which will be replicated for The DCA DotAfrica Registry.

24.4. Performance
The DCA DotAfrica Registry will perform continuous remote monitoring of its EPP system, and this monitoring will include measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of CentralNic’s EPP system, which will be used as a model for The DCA DotAfrica Registry, were as follows:
 connect time: 87ms
 login time: 75ms
 hello time: 21ms
 check time: 123ms
 logout time: 20ms
These figures include an approximate latency of 2.4ms due to the distant between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.

24.5. Scaling
Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.

Vertical scaling leverages Mooreʹs Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.

For further information about Capacity Management and Scaling, please see §32.

24.6. Registrar Console
The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. The DCA DotAfrica Registry Registrar Console will be hosted on a virtual platform at the primary operations centre in Nairobi. As with the rest of the registry system, during a failover condition it will be operated from the Isle of Man. The virtual platform is described in Figure 24.3.

The features of the Registrar Console are described in §31.
The virtual platform is a utility platform that supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on ʺbare metalʺ would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.

The CentralNic Registrar Console, which will be replicated for the use of The CentraNic Africa Registry, currently sustains an average of 6 page requests per minute during normal operations, with peak volumes of around 8 requests per minute. Volumes during weekends are significantly lower (fewer than 1 requests per minute). Additional load resulting from this and other new gTLDs is expected to result in a trivial increase in Registrar Console request volumes, and CentralNic does not expect additional hardware resources to be required to support it.

24.7. Quality Assurance
The DCA DotAfrica Registry will employ the following quality assurance (QA) methods:
1. 24x7x365 monitoring provides reports of incidents to NOC
2. Quarterly review of capacity, performance and reliability
3. Monthly reviews of uptime, latency and bandwidth consumption
4. Hardware depreciation schedules
5. Unit testing framework
6. Frequent reviews by QA working group
7. Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
8. Revision control software with online annotation and change logs
9. Bug Tracking system to which all employees have access
10. Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
11. Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
12. Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
13. Evidence-based project scheduling
14. Specification development and revision
15. Weekly milestones for developers
16. Gantt charts and critical path analysis for project planning

Registry system updates will be performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest. These quality assurance measures will be based on the existing methods CentralNic’s infrastructure.

24.8. Billing
The DCA DotAfrica Registry will operate a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. The foundation of the process is debit accounts established for each registrar. The DCA DotAfrica Registry will withdraw all domain fees from the registrar’s account on a per-transaction basis and will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar’s account shows a positive balance.

Once ICANN notifies DCA that a registrar has been issued accreditation, The DCA DotAfrica Registry will begin the registrar on-boarding process, including setting up the registrarʹs financial account within the SRS.

24.9. Registrar Support
The DCA DotAfrica Registry will provide a multi-tier support system on a 24x7 basis with the following support levels, replicating that of CentralNic’s infrastructure:
 1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
 2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
 3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.

The DCA DotAfrica Registry will provide a support ticketing system for tracking routine support issues. This is a web-based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from DCA DotAfrica Registry’s support personnel.

When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used:

1. Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
2. Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
3. Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
4. Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall

Registry System operations. Handled by 3rd level support.
Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.

24.10. Enforcement of Eligibility Requirements
The SRS supports enforcement of eligibility requirements, as required by specific TLD policies. However, these will not be used for .africa.

24.11. Interconnectivity With Other Registry Systems
The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by the database which is the single authoritative source of data for the registry as a whole. Individuals modules perform ʺCRUDʺ (create, read, update, delete) actions upon the database. These actions then affect the behaviour of other registry systems: for example, when a registrar adds the ʺclientHoldʺ status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the ʺStatus: CLIENT HOLDʺ appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.

24.12. Resilience
The SRS has a stateless architecture designed to be fully resilient in order to provide an uninterrupted service in the face of failure or one or more parts of the system. This is achieved by use of redundant hardware and network connections, and by use of continuous ʺheartbeatʺ monitoring allowing dynamic and high-speed failover from active to standby components, or between nodes in an active-active cluster. These technologies also permit rapid scaling of the system to meet short-term increases in demand during ʺsurgeʺ periods, such as during the initial launch of a new TLD.

24.12.1. Synchronisation Between Servers and Sites
DCA DotAfrica Registry’s system will be implemented as multiple stateless systems which interact via a central registry database. As a result, there will only be few situations where synchronisation of data between servers is necessary:

1. replication of data between active and standby servers (see §33). CentralNic implements redundancy in its database system by means of an active⁄standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.

2. replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see §34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a ʺhotʺ backup site which can be used to provide registry services in the event of a failure at the primary site.

24.13. Operational Testing and Evaluation (OT&E)
An Operational Testing and Evaluation (OT&E) environment is provided for registrars to develop and test their systems. The OT&E system replicates the SRS in a clean-room environment. Access to the OT&E system is unrestricted and unlimited: registrars can freely create multiple OT&E accounts via the Registrar Console.

24.14. Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, DCA DotAfrica Registry will maintain a team of full-time developers and engineers who will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.

CentralNicʹs resourcing model assumes that after launch, the ʺdedicatedʺ resourcing required for .africa (ie, that required to deal with issues related specifically to .africa and not to general issues) will be equal to the proportion of the overall registry system that .africa will use. After three years of operation, the optimistic projection for .africa states that there will be 529,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore .africa will require 12% of the total resources available for this area of the registry system.

Except where specified this answer refers to the operations of the DCAʹs Backend Registry Service Provider, CentralNic.

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.

CentralNic has operated its EPP system since 2005 and it currently operates at significant load in terms of registrars, sessions and transaction volumes. This system will be replicated for DCA DotAfrica Registry. DCA DotAfrica’s EPP system will be fully compliant with the following RFC specifications:
 5730 - Base Protocol
 5731 - domains
 5732 - Host Objects
 5733 - Contact Objects
 5734 - TCP Transport
 3735 - Extension Guidelines
 3915 - RGP Extension
 5910 - DNSSEC Extension

25.1. Description of Interface
EPP is a stateful XML protocol layered over TCP (see RFC 3734). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).

EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.

EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.

Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.

EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.

25.1.1. Objects supported
Registrars may create and manage the following object types in the DCA DotAfrica’s EPP system:
 domains (RFC 5731)
 host objects (RFC 5732)
 contact objects (RFC 5733)

25.1.2. Commands supported
DCA DotAfrica will support the following EPP commands:
 “hello” - retrieve the “greeting” from the server
 “login” and “logout” - session management
 “poll” - message queue management
 “check” - availability check
 “info” - object information
 “create” - create object
 “update” - update object
 “renew” - renew object
 “delete” - delete object
 “transfer” - manage object transfer

25.2. EPP state diagram
Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.

25.3. EPP Object Policies
The following policies apply to objects provisioned via the EPP system:

25.3.1. domains
1. domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
2. domains must have a registrant attribute which is associated with a contact object in the database.
3. domains must have an administrative contact attribute which is associated with a contact object in the database.
4. domains must have a technical contact which attribute is associated with a contact object in the database.
5. domains may have an billing contact attribute which is associated with a contact object in the database.
6. domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
7. the host object model for domains is used rather than the host attribute model.
8. domains may have a number of status codes. The presence of certain status codes indicates the domainʹs position in the lifecycle, described further in §27.
9. where policy requires, the server may respond to a “domain:create” command with an ʺObject Pendingʺ (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
10. when registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
11. when renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. domains which auto-renew are renewed for one year at a time.
12. domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
13. domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
14. only the sponsoring registrar of the domain may submit “update”, “renew” or “delete” commands for the domain.

25.3.2. Host objects
1. host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
2. in-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
3. multiple IP addresses are not currently permitted.
4. sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
5. if a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.
6. registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.
7. a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
8. inter-registrar transfers are not permitted.
9. only the sponsoring registrar of the host may submit “update” or “delete” commands for the object.

25.3.3. Contact objects
1. contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
2. phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
3. contact information is accepted and stored in ʺinternationalizedʺ format only: that is, contact objects only have a single “contact:postalInfo” element and the type attribute is always ʺintʺ.
4. the “contact:org”, “contact:sp”, “contact:pc”, “contact:phone” and “contact:fax” elements are optional.
5. contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
6. a contact cannot be deleted if one or more domains are associated with it.
7. only the sponsoring registrar of the contact may submit “update” or “delete” commands for the object.

25.4. EPP Extensions
DCA DotAfrica will support the following EPP extensions. CentralNicʹs implementations fully comply with the required specifications.

25.4.1. Registry Grace Period Mapping
Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915. This is described further in §27.

25.4.2. DNSSEC Security Extensions Mapping
Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.

DCA DotAfrica will support the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. DCA DotAfrica will support the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the “secDNS:dsData” element. The maxSigLife element is optional in the specification and is not currently supported.

25.4.3. Launch Phase Extension
CentralNic has assisted development of a standard EPP extension for registry ʺlaunch phasesʺ (ie Sunrise and Landrush periods), during which the steady-state mode of ʺfirst-come, first-servedʺ operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft (see http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-00). It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.

DCA DotAfrica’s system will implement this extension and will support the most recent version of the draft during the initial launch of .africa. Once .africa enters General Availability, this extension will no longer be available for use by registrars. Example frames describing the use of this extension are included in Appendix 25.2. As of writing, the current draft does not include a full schema definition, but a schema from a previous version has been included in Appendix 25.3. When the Draft is updated to include a schema, it will be based on this version.

25.5. Registrar Credentials and Access Control
Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the ʺManagementʺ access level can change their EPP password via the Registrar Console.

RFC 5730 requires ʺmutual, strong client-server authenticationʺ. CentralNic requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with CentralNic via the Registrar Console. Registrar officers with the ʺManagementʺ access level can upload SSL certificates for their account.

25.6. Session Limits and Transaction Volumes
There are no limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However the system is fully capable of imposing connection limits and this measure may be used in future to ensure equal access amongst registrars.

25.7. Transaction Logging and Reporting
All ʺtransformʺ commands are logged. Transform commands are: “create”, “renew”, “update”, “delete” and “transfer”. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.

The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console.
The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.

Query commands (“check”, “info”, “poll op=ʺreqʺ“) and session commands (“login”, “logout” and “hello”) are not logged due to the large volume of such queries (particularly “check” queries). The EPP system uses counters for these commands to facilitate generation of monthly reports.

25.8. EPP Message Queue
The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic’s infrastructure currently supports the following EPP message notifications which will be replicated for DCA DotAfrica:
 approved inbound transfer
 rejected inbound transfer
 new outbound transfer
 cancelled outbound transfer
 approved or rejected domain registration request (where TLD policy requires out-of-band approval of “domain:create” requests)

25.9. Registrar Support, Software Toolkit
CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:
 Net::EPP, a general purpose EPP library for Perl. See http:⁄⁄code.google.com⁄p⁄perl-net-epp⁄
 Preppi, a graphical EPP client written in Perl. See https:⁄⁄www.centralnic.com⁄company⁄labs⁄preppi
 Net_EPP, a PHP client class for EPP. See https:⁄⁄github.com⁄centralnic⁄php-epp
 Simpleepp, a Python client class for EPP. See https:⁄⁄bitbucket.org⁄milosn⁄simpleepp
 tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python. See https:⁄⁄bitbucket.org⁄milosn⁄tx-epp-proxy

These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.

25.10. Quality Assurance, RFC Compliance
To ensure that its EPP system fully complies with the relevant specifications documents, CentralNic has implemented the following, which will be replicated for DCA DotAfrica:

25.10.1. Schema Validation
The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected. By default, this feature is disabled in the production environment but it is enabled in all other environments (as described below).

25.10.2. Multi-stage Deployment and Testing
EPP system code is developed, tested and deployed in a multi-stage environment:
1. Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
2. All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
3. Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.

25.10.3. Registrar Feedback
Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation on the responses they receive. When issues are detected by registrars, they are encouraged to submit bug reports so that developers can rectify the issues.

25.11. EPP System Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, DCA DotAfrica will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time person.

CentralNicʹs resourcing model assumes that after launch the ʺdedicatedʺ resourcing required for .africa (ie, that required to deal with issues related specifically to .africa and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .africa will use. After three years of operation, the optimistic projection for .africa states that there will be 529,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore .africa will require 12% of the total resources available for this area of the registry system.

Except where specified this answer refers to the operations of DCAʹs Backend Registry Service Provider, CentralNic.

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.
Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.

26.1. Compliance
The Whois service for .africa will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as WEIRDS) then CentralNic will implement these as soon as reasonably practicable.

DCA DotAfrica will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. DCA DotAfrica will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.

26.2. Domain Name
By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:
 Domain ROID
 Domain Name
 Domain U-label (if IDN)
 Creation Date
 Last Updated
 Expiration Date
 EPP status codes
 Registrant Contact Information
 Administrative Contact Information
 Technical Contact Information
 Billing Contact Information (if any)
 Sponsoring Registrar ID
 Sponsoring Registrar Contact Information
 DNS servers (if any)
 DNSSEC records (if any)
An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the “domain:roid” element of EPP “info” responses.

A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:

 PENDING CREATE - a “domain:create” command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.

 ADD PERIOD - the domain is in the Add Grace Period
 CLIENT HOLD - the registrar has added the clientHold status
 DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
 INACTIVE - the domain has no DNS servers
 PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
 PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
 PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
 PENDING TRANSFER - there is an active inter-registrar transfer for the domain
 RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
 RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
 SERVER HOLD - the registry has added the serverHold status
 TRANSFER PERIOD - the domain is in the Transfer Grace Period
 TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
 UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
 OK - present if none of the above apply.

The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.

Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the ʺINACTIVEʺ status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.

26.3. Contact
Users can query for information about a contact by submitting a query of the form ʺcontact [ID]ʺ, where ʺ[ID]ʺ is the contact ID equivalent to the “contact:id” element in EPP “info” responses. This is also the ID used when referring to contacts in domain responses.
The following information is included in Dontact records:
 Contact ID
 Sponsoring Registrar
 Creation Date
 Last Updated Date
 EPP Status Codes
 Contact Name
 Organisation
 Street Address (1-3 fields)
 City
 State⁄Province
 Postcode
 Country Code (2 character ISO-3166 code)
 Phone number (e164a format)
 Fax number (e164a format)
 Email address

An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:
 DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
 TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
 UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
 PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
 LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status

26.4. Host Objects
Users can query for information about a host object by submitting a query of the form ʺnameserver [HOST]ʺ. The following information is included in host records:
 Server Name
 IPv4 address (if any)
 IPv6 address (if any)
 EPP status codes
 Sponsoring Registrar
 Creation Date
 Referral URL (if any)

An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is ʺin-bailiwickʺ, ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for ʺout-of-bailiwickʺ hosts.
Host objects may only have two status codes:
 INACTIVE - the host is not associated with any domain names
 LINKED - the host is associated with one or more domain names

The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in .africa, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original “create” request.

26.5. Character Encoding
Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.

26.6. IDN Support
The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.

26.7. Bulk Access
DCA DotAfrica will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). DCA DotAfrica will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.

At ICANNʹs request, DCA DotAfrica will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. DCA DotAfrica will provide the data within 2 business days.

26.8. Load Projections
As described in §31, CentralNicʹs existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.

The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in .africa and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.

CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for DCA DotAfrica’s whois for .africa. A projection of query load for the Whois system for the first 24 months of operation can be found inAppendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.

26.9. Technical Implementation
A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service will be operated at the primary operations centre in Nairobi. During failover conditions, it is operated at the Disaster Recovery site in the Isle of Man (see §34).

Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one a server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.

26.9.1. Application Server Architecture
Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whois Apache module (see http:⁄⁄modwhois.sf.net⁄) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.

26.9.2. Caching
Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.

26.9.2. Database
The DCA DotAfrica Whois service will draw data directly from the primary database. The query volume required to sustain the Whois service will be comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system will not be required. As can be seen in Figure 26.1, a separate logging database will be used to aggregate log data for use with the rate limiting system.

26.10. Web based Whois Service
DCA DotAfrica will provide a web interface to the Whois service on its website. In addition, DCA will provide a similar service on the .africa registry website. The web Whois will act as a proxy to the port 43 Whois service: users will enter a query into a form, and a server-side process will submit the query to the Whois server, and display the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.

26.11. Searchable Whois Service
DCA will provide a Searchable Whois Service (SWS). This service will be made available on the .africa website. The SWS provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including:

 domain name (partial match)
 registrant name, organisation, address, email
 administrative, technical and billing contact information
 Nameservers
 Nameserver IPv4⁄IPv6 address

Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the system. These terms are included as Appendix 26.5. Once their request has been reviewed and approved, they are issued with credentials that permit them to login to the SWS.
To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.

26.12. Anti-Abuse Mechanisms
CentralNic has implemented measures to mitigate the threat of abuse of the Whois service and these will be observed by DCA DotAfrica. The primary threat to the Whois service are so-called ʺdictionaryʺ attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.

The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing ⁄48 will be blocked.

Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels which are unappealing for attackers.

DCA DotAfrica will keep a ʺwhite listʺ of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists will also be incorporated into the white list, and IP addresses registered on ICANNʹs RADAR system will also be included. Queries from IP addresses that appear on the white list will not be rate-limited. Interested parties can request addition to the white list by contacting DCA DotAfrica’s public customer service team.

The web-based Whois will not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.

26.12.1. Denial-of-Service attacks
The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNicʹs network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see §42) proactively detects these threats. As the Whois service directly queries the primary SRS database, CentralNic rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.

26.13. Monitoring and Logging
Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.

26.14. Resourcing
As can be seen in the Resourcing Matrix found in Appendix 23.2, DCA DotAfrica will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to almost one full-time person (83%).

Except where specified this answer refers to the operations of DCAʹs Backend Registry Service Provider, CentralNic.

The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.

27.1. Available
The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a ʺNOT FOUNDʺ response to queries. An EPP “check” command will return an ʺavailʺ status of 1.

27.2. Registered
A registrar submits an EPP “create” command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrarʹs balance. The initial registration period may be any whole number of years between one (1) and ten (10).

For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).

While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain nameʹs DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a “renew” EPP command or using the Registrar Console.

The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.

27.3. Expired
When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrarʹs account.
For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.

27.4. Redemption Grace Period
Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from .africa zone.

For the first thirty (30) days after receipt of the delete request, the domain is in the ʺPending Delete Restorableʺ state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the ʺPending Restoreʺ state.

The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the ʺPending Delete Restorableʺ state.

27.5. Redemption Period State Diagram
Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.

27.6. Pending Delete
Forty (40) days after the receipt of the delete request, the domain leaves the ʺPending Delete Restorableʺ and enters the ʺPending Deleteʺ status. The registrar cannot submit a Restore Request during this period.

27.7. Released
Five (5) days after the domain enters the ʺPending Deleteʺ status the domain name is purged from the database and is once again available for registration.

27.8. Other Grace Periods
The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.

27.8.1. Add Grace Period
As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.

27.8.2. Auto-renew Grace Period
As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.

27.8.3. Renew Grace Period
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP “renew” command, or via the Registrar Console.

27.8.4. Transfer Grace Period
The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.

27.9. Hold Periods
The DCA DotAfrica Registry will implement the following hold periods:

27.9.1. Registration Hold Period
The Registration Hold Period will forbid inter-registrar transfers of domain names within sixty (60) days of initial registration.

27.9.2. Transfer Hold Period
The Transfer Hold Period will forbid transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.

27.10. Lock Statuses
The DCA DotAfrica Registry system will permit the following lock statuses for domain names:

27.10.1. clientHold
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.

27.10.2. clientDeleteProhibited
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can delete the domain.

27.10.3. clientRenewProhibited
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP “update” command before they can renew the domain.

27.10.4. clientUpdateProhibited
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the “update” request frame includes a “rem” element to remove this status. Once the status has been removed, subsequent “update” commands will succeed.

27.10.5. clientTransferProhibited
This status may be set by registrars using an EPP “update” command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP “transfer” command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.

27.10.6. serverHold
This status will be set by the DCA DotAfrica Registry in accordance with policy. It cannot be removed by registrars. Domains with this status will be removed from the DNS and will not resolve.

27.10.7. serverDeleteProhibited
This status will be set by the DCA DotAfrica Registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP “delete” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.8. serverUpdateProhibited
This status will be set by the DCA DotAfrica Registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP “update” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.9. serverRenewProhibited
This status will be set by the DCA DotAfrica Registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP “renew” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.10.10. serverTransferProhibited
This status will be set by the DCA DotAfrica Registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP “transfer” command will be refused with EPP response code 2304 (Status Prohibits Operation).

27.11. Lifecycle Processing
Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.
Billing runs take place once per day. The billing run performs the following batch jobs:
 auto-renewal of expired domains
 processing of registration and renewal fees for domains that move outside their grace periods
 processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
 purging of domains scheduled for deletion
The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.

27.12. Inter-Registrar Transfer Period
When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.

27.13. Pending Create Status
The DCA DotAfrica Registry system will support the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent “create” commands would fail with an Object Exists error) but are not present in the DNS.
This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.

If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain that begins to resolve.

27.14. Resourcing
The domain registration lifecycle will be managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure that supports the lifecycle processing systems. Backend systems will be hosted on a flexible virtual infrastructure hosted at the primary operations centre in Nairobi, Kenya.

The domain registration lifecycle will not have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent will be dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 30% of a full time person. Because of the maturity and stability of this system (which has been in use for more than 16 years), only 5% of time of a technical developer has been allocated to this area.

Top Level Domain registries stand in a unique position within the global DNS infrastructure.

TLD registries collect registrants’ registration data and so often “know” the entity responsible for a particular domain name. TLD registries record associations between domain names, registrars and registrants and therefore are in the core of the control chain for every domain name in .africa. Registries also directly control the delegation records and therefore have the power to enable or disable a particular domain name in the DNS.

This unique position gives power and calls for responsibility. DCA DotAfrica as a future TLD registry recognizes its important role in maintaining law and order and is committed to acting in the best interests of the public.

Hereby we provide a description of the principles and procedures we will apply to mitigate abusive conduct.

28.1. Single Abuse Point of Contact
To streamline the information flow and to facilitate ease of communication with the public, DCA DotAfrica Registry will dedicate a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in .africa. The contact information will consist of at least an email address and a telephone number. This point of contact will be prominently published on the registry website by the commencement of the Sunrise period.
DCA DotAfrica Registry will ensure that:
 The e-mail account is continuously monitored and all communication securely stored
 The telephone number is either answered by a live person or diverted to a monitored voicemail account.
 Abuse contact information will be kept current and will be updated should it ever change in a timely manner
Messages received through the published abuse point of contact will be processed via the same procedure and within the same timeframe as the signals coming from the monitoring systems. Each message, both via email and phone channels, triggers the creation of a support ticket in a dedicated queue and procedures for ticket escalation exist. Messages originating from law enforcement authorities are by default assigned an escalated level. For critical tickets personnel is available 24x7 to react accordingly.

DCA and CentralNic commit to responding to all abuse complaints within 24 hours of receipt (on a 24x7 basis). During the time periods when its global offices are open (typically 8am-6pm in London, Los Angeles, Dubai and Nairobi for DCA DotAfrica Registry) response times are expected to be substantially faster, at around 2-3 hours.

28.2. Policy on Handling Complaints Regarding Abuse
DCA DotAfrica Registry is prepared to deal with situations where registry intervention may be required in order to stop illegal activity, prevent abusive conduct or to enforce the law.

DCA DotAfrica Registry will adopt a comprehensive Acceptable Use Policy that will establish what constitutes acceptable use of the domain and will contain a description of procedures registry that will apply to enforce the Policy. The initial policy is provided in answer to question 29.
An enforcement action may be triggered by a variety of events including complaints from the public, registrars or ICANN, decisions of a competent dispute resolution provider, outreach from a governmental agency or findings produced by internal investigation or monitoring processes.

Normally if abusive behaviour in a TLD is encountered, the reports of such behaviour and the evidence available will be analysed by the Registry. If the Registry, in its sole discretion, concludes that a Domain Name Holder has indeed violated a TLD Policy, the registrant will be given a notice and opportunity to correct the breach.

Furthermore, the registry reserves the right to lock the domain name or put it on hold (preventing domain resolution in the DNS). In extreme cases where a domain is involved in malicious or illegal activity there are provisions for rapid takedown of the domain name in question. The situations in which rapid takedown provisions may be applied, include, but are not limited to:
 Phishing
 Pharming
 Distribution of illegal content
 Distribution of malware
 Fast flux hosting
 Botnetting
 Unauthorized access to information systems
 Threats to the security and⁄or stability of .africa

The .africa Acceptable Use Policy will be incorporated into the Registry-Registrar agreements and Registrars will be required to pass through the requirements to comply with the policy to the registrants.

DCA will take reasonable steps to investigate and respond to any reports of illegal activity in connection with the use of .africa and will cooperate with the competent governmental agencies in such investigations.

DCA will utilize the expert services CentralNic to implement and enforce all of our anti-abuse policies in our TLD. CentralNic has dedicated and scalable resources for this function, described below.

CentralNic has long experience in the domain registry business, and is an industry leader with respect to its anti-abuse policies. CentralNic has a dedicated Dispute Resolution Policy in place with WIPO, found at WIPO’s website: http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. CentralNic has trained personnel who handle interaction with WIPO, to ensure that panelists’ decisions are carried out expeditiously as required by the DRP.

CentralNic also enforces a Policy on Phishing and Fraud, found at its dedicated Phishing & Abuse page at the following website: https:⁄⁄www.centralnic.com⁄support⁄abuse. Pursuant to clause 13, sections (f) and (h) of CentralNicʹs Terms and Conditions, CentralNic may cancel the registration or suspend registration of a domain name:

(f) if CentralNic believes that the domain name was registered for use in a ʺphishingʺ attack or other illegal activity of any kind.
(h) if inaccurate or false contact details are provided.

Further to these conditions, CentralNic operates the following policy regarding suspected ʺphishingʺ domain names:
- If we have a reasonable suspicion that a domain name registered at CentralNic is being used in a phishing attack, or otherwise being used for other illegal activities, we will place the domain name ʺOn Holdʺ and under a Registry Lock. - We will then notify the current registrar for the domain name. If the registrar can provide confirmation that the domain name was registered in ʺgood faithʺ by the registrant, then CentralNic will immediately unlock the domain name and place it on the ʺLiveʺ status. - If no confirmation is received, or the registrars agree that the domain name was registered in ʺbad faithʺ, the domain name will be placed onto ʺPending Deletionʺ, and will be fully deleted from the database after 45 days.

28.3. Orphan Glue
CentralNicʹs registry system includes effective measures to prevent the abuse of orphan glue records. These measures will also apply to DCA DotAfrica.

First, the Shared Registry System will reject any request to create host object that is the child of a non-existent domain name. That is, if EXAMPLE.africa does not exist, then NS0.EXAMPLE.africa cannot be created. If the parent domain name does exist, then only the sponsoring registrar of that domain is permitted to create child host objects.

CentralNicʹs registry system currently follows the third model described in the SAC 048 report: orphan glue records are deleted from the registry and removed from the DNS when the parent domain name is deleted. If other domains in the database are delegated to orphan hosts that are removed, then the delegation is also removed from these domains. DCA DotAfrica Registry will observe this system.

28.4. Measures to Maintain Whois Accuracy
DCA DotAfrica Registry will operate a “thick” WHOIS system, in which all registrants’ contact information will be stored in a single database maintained by the registry. Accredited registrars will have the ability to change the records in that database through the Shared Registration System. The Registry-Registrar agreement requires registrars to ensure that the WHOIS data is accurate at the time of submission and also requires the information provided on the system to be updated in a timely manner in case of any changes. Corresponding provisions also exist in the Registrar Accreditation Agreement (RAA), para. 3.7.7.

In addition to the standard measures described above, the .africa WHOIS system will feature extra levels of reliability with regards to Whois information.

28.4.1. Extra checks on WHOIS data
DCA, through its Registry-Registrar agreements will require registrars to perform the following additional checks on the WHOIS data:
 Verify syntactic correctness of email addresses and phone numbers by validating them against the corresponding standards
 Verify that the domain holder receives email at the addresses listed in WHOIS as registrant’s email address and administrative contact email address, by requiring them to click a unique web link that is sent to those addresses.
28.4.2. Random audits of WHOIS records by the Registry

DCA DotAfrica Registry will periodically (at least once every 12 months) perform a random check of WHOIS records in .africa for prima facie evidence of fraudulent or inaccurate WHOIS information. For those suspicious records that may be found, DCA will further require registrars to conduct a reasonable investigation and to respond with one of the three possible actions:
 confirm that the information provided in WHOIS is accurate, or
 correct the WHOIS information, or
 delete the domain name(s).
The measures described above exceed the ICANN requirements and are adequate to improve accuracy of WHOIS information while maintaining low implementation cost for registrars and good user experience for registrants.

28.5. Resourcing
DCA DotAfrica Registry will provide abuse response on a 24x7 basis. The resourcing to fulfill this function will be provided by a combined team of support and operations personnel. The first response function will be provided by support agents during normal office hours, with this responsibility being passed to the Network Operations Centre (NOC) during 24x7 operations.

As can be seen in the Resourcing Matrix found in Appendix 23.2, DCA DotAfrica Registry will maintain a team of full-time developers and engineers who will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 75% of a full-time role.

Although DCA DotAfrica Registry will operate on a dedicated registry environment, the .africa registry will be operated identically to CentralNic’s existing registry by the same team, and will benefit from an economy of scale with regards to access to CentralNicʹs resources.
CentralNicʹs resourcing model assumes that after launch the ʺdedicatedʺ resourcing required for .africa (i.e, that required to deal with issues related specifically to .africa and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .africa will use. After three years of operation, the optimistic projection for .africa states that there will be 600,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore .africa will require 13% of the total resources available for this area of the registry system.

28.6. Periodic review of anti-abuse policies
DCA acknowledges that new types of abusive behaviour emerge in cyber space and is prepared to take steps to counter any new types of abuse. DCA will periodically (once every 12 months, or more frequently depending on the circumstances) require registrars registering under DotAfrica to provide reports regarding the received abuse-related complaints. Such reports should contain categorisation of the abusive behaviour reported, actions taken and response time. DCA will analyse the reports and will review its anti-abuse policies to continually improve the handling of abuse complaints.

DCA DotAfrica Registry Services recognizes providing appropriate mechanisms to protect legal rights of others as one of the core objectives of the Registry. DCA DotAfrica Registry Services will follow rules and policies developed by ICANN with regards to Rights Protection Mechanisms (RPMs). DCA DotAfrica Registry Services will fully comply with Specification 7 of the new gTLD registry agreement and will provide additional rights protection mechanisms over and above the ICANN requirements. Both standard and additional RPMs are described below.

29.1. Sunrise Period
Prior to the open registration phase DCA DotAfrica Registry Services will offer a priority registration period for owners of trademarks and service marks. This period will last at least 30 days.

DCA DotAfrica Registry Services will support Trademark Clearinghouse (TCH) once it is implemented by ICANN. Owners of trademarks pre-validated by the Clearinghouse will be able to secure their domain registrations during the Sunrise period without further verification of their intellectual property rights.

The flowchart of the Sunrise and eligibility validation process is available in Figure 24.4.

29.1.1. Sunrise Eligibility Requirements
Any entity that holds a trademark or service mark will be qualified to register a domain during the Sunrise period. Registrations obtained during the Sunrise Period will be subject to challenge as described below.
At a minimum, the Registry will recognize as qualifying all word marks that:
 Are nationally or regionally registered and for which proof of use is available, or
 Marks that have been validated by the court, or
 Marks that are specifically protected by a statute or treaty.

All the Sunrise Eligibility requirements will have to be met by the cut-off date which will be announced in due course.
Full details of the Sunrise registration process will be finalized after the Trademark Clearinghouse service is implemented and full documentation, policies, terms and conditions are made available. For guidance, data items that will need to be provided by the qualifying trademark or service mark owner to apply for a DotAfrica Sunrise registration are listed below:
 name or description of the trademark
 registration number
 registration date
 country of registration
 capacity of applicant
 reference to the Trademark Clearinghouse database record
 Representation that the information provided is true and correct

29.1.2. Sunrise Challenge Process
The result of the evaluation of Sunrise applications will be published on the Registry website. A process will be put in place to allow third parties to dispute the registrant rights to own a domain name. DCA DotAfrica Registry Services will engage with a reputable adjudicator to manage the Sunrise challenge process. The adjudicator will charge a reasonable fee for Sunrise challenges.

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

29.2. Trademark Claims Service
The Trademark Claims service will be launched by the registry as soon as the open registration period starts and will be provided for at least 90 days (exceeding the period mandated by ICANN). DCA DotAfrica Registry Services will review the effect of the Trademark Claims service and based on the results of such review DCA DotAfrica Registry Servces is prepared to consider providing the Trademark Claims service on an ongoing basis.

The essence of the Trademark Claims service is as follows: if a domain name registration is attempted for which there exists a matching record in the Trademark Clearinghouse database, then the prospective registrant will be presented with a notice that third party trademark rights exist for a matching designation and will be required to provide a statement that to the best of his or her knowledge, the registration and use of the requested domain name will not infringe on the rights of the trademark holders.

If the registrant chooses to proceed with the registration, the corresponding trademark holder(s) will be notified that such registration has taken place.

Operational rules of the Trademark Claims service are heavily dependent on the specific implementation of the Trademark Clearinghouse which is not yet available in writing. Therefore full details of the Trademark Claims service will be finalized after the TCH is implemented by ICANN and full documentation, policies, terms and conditions become available.

29.3. Uniform Domain Name Dispute Resolution Policy (UDRP)
The Uniform Domain Name Dispute Resolution Policy is an ICANN consensus policy for adjudication of disputes between domain name holders and owners of matching trademarks. Every registrant must agree to this mandatory administrative procedure in its Domain Registration Agreement with the registrar. Registrars have certain responsibilities to facilitate adjudication of UDRP disputes and to enforce the decisions of the arbitration panels.

DCA DotAfrica gTLD Registry will comply with the Uniform Domain Name Dispute Resolution Policy or with any successor thereof. The UDRP will be incorporated by reference into Registry-Registrar Agreements. Similarly, Registrars will be required to incorporate it into their Domain Registration agreements with the Registrants.

The UDRP process does not provide for any participation by the Registry and is fully borne by the Registrar, Registrant, Complainant and the Dispute Resolution Provider. However, DCA DotAfrica Registry Services is prepared to collaborate with all relevant stakeholders to ensure UDRP decisions are implemented.

CentralNic, DCA’s back-end registry services provider, has maintained a similar dispute resolution policy with WIPO which is available at http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. CentralNic has dedicated personnel trained to address these types of complaints and to communicate with WIPO and other relevant stakeholders.

29.4. Uniform Rapid Suspension System (URS)
The Uniform Rapid Suspension System (URS) described in the ICANN gTLD Guidebook is a new Rights Protection Mechanism for rapid takedown of domain names that by clear and convincing evidence infringe on legitimate trademark rights of third parties.

As opposed to the UDRP procedure, registries are required to participate in the URS procedure and enforcement of the URS decisions. DCA DotAfrica Registry Services will comply with the URS policy once implemented by ICANN.

The current URS draft procedure as described in the ICANN Applicant’s Guidebook (11 January 2012) is as follows: within 24 hours of receipt of the Notice of Complaint from a URS Provider, the Registry has to lock the domain, restricting all changes to the registration data, including transfer and deletion. The domain name will continue to resolve at this stage. The Registry will notify the URS Provider immediately upon locking the domain name.

If the URS Determination is in favour of Complainant, upon receipt of the Determination the Registry will suspend the domain name which is intended to remain suspended for the balance of the registration period and will not resolve to the original web site. Instead, the nameservers will be redirected to an informational web page provided by the URS Provider about the URS. The Whois record for the domain name will continue to display all of the information of the original Registrant except for the redirection of the nameservers. In addition, the Whois will reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.

If the URS Determination is in favour of the Respondent, the Registry will remove the lock status from the domain name allowing the registrant to continue using it normally.

The URS compliance function will be performed by DCA DotAfrica Registry Services and overseen by CentralNIC. Given CentralNic’s long-standing experience in dealing with trademark-related disputes in domain names, DCA has no doubt that this function will be flawlessly performed by the DCA DotAfrica gTLD Registry.

29.5 Mediation
CentralNic has implemented a solution that complements the UDRP by adopting a best practice of Nominet and other ccTLDs. This solution will be implemented for the DCA DotAfrica Registry system. CentralNic has experienced a high percentage of domain disputes resolved without the need for filing a formal and relatively expensive UDRP complaint, by offering informal mediation to any person or entity who submits a Request for Mediation to the registry. The Mediation rules that CentralNic intends to apply to gTLDs are copied below:
ʺCentralNicʺ means CentralNic Ltd, 35-39 Moorgate, London EC2R 6AR, United Kingdom.

ʺComplainantʺ means the party submitting a Request for Mediation concerning a Domain Name registration pursuant to the CentralNic Mediation Rules.

ʺDomain Nameʺ means any domain name registered under a sub-domain provided by CentralNic.
ʺMediationʺ means a mediation conducted by CentralNic in accordance with the CentralNic Mediation Rules that are incorporated by reference and made a part of the Registration Agreement.
ʺPartyʺ means a Complainant or a Respondent.
ʺRegistration Agreementʺ means the agreement between CentralNic and a Domain Name holder.
ʺRespondentʺ means the holder of a Domain Name registration in respect of which a Request for Mediation is submitted pursuant to the CentralNic Mediation Rules.

1. Request for Mediation: (a) Any person or entity may submit a Request for Mediation relating to a Domain Name registration in accordance with the CentralNic Mediation Rules. A copy of the Request for Mediation shall be sent to the Respondent and to CentralNic. (b) The Request for Mediation shall be submitted in writing by e-mail and shall: (i) State that the Complainant wishes to submit the dispute to Mediation in accordance with the CentralNic Mediation Rules; (ii) Provide the name, postal and e-mail addresses, and the telephone and telefax numbers of the Complainant and of any representative authorized to act for the Complainant in the Mediation; (iii) Specify a preferred method for communications directed to the Complainant in the Mediation (including person to be contacted, medium, and address information); (iv) Provide the name of the Respondent and all information (including any postal and e-mail addresses and telephone and telefax numbers) known to Complainant regarding how to contact the Respondent or any representative of the Respondent, including contact information based on pre-Request dealings; (v) Specify the Domain Name(s) that is⁄are the subject of the Request; (vi) Contain a brief statement of the nature of the dispute. (c) The Request for Mediation may relate to more than one Domain Name, provided that the Domain Names are registered by the same Domain-Name holder.

2. Commencement: (a) The date of commencement of the Mediation shall be the date on which the Request for Mediation is received by CentralNic. (b) CentralNic shall inform the Parties of the receipt by it of the Request and of the date of commencement of the Mediation.

3. Mediation: (a) CentralNic shall conduct the Mediation in a manner which CentralNic, in its sole discretion, considers appropriate. (b) The language of the Mediation shall be English, unless decided otherwise by CentralNic. (c) CentralNic will not reveal details of the Mediation to any third parties unless ordered by a court of competent jurisdiction or required by applicable laws or regulations or except as may be provided under the CentralNic Dispute Resolution Policy and the Rules for CentralNic Dispute Resolution Policy.

4. Termination of the Mediation: The Mediation will terminate ten (10) calendar days after the date of commencement. At the request of the Parties or on its own motion, CentralNic may, in exceptional cases, extend the period of time for the Mediation. The fact of termination shall be recorded by CentralNic.

5. Fees: No fees shall be payable by either party for the conduct of the Mediation.

6. Exclusion of Liability: Except in the case of deliberate wrongdoing, CentralNic shall not be liable to a Party for any act or omission in connection with the Mediation.

7. Waiver of Defamation: The Parties agree that any statements or comments, whether written or oral, made or used by them or their representatives in preparation for or in the course of the Mediation shall not be relied upon to found or maintain any action for defamation, libel, slander or any related complaint, and this Paragraph may be pleaded as a bar to any such action.

8. Amendments: CentralNic reserves the right to modify these Rules at any time. CentralNic will post the revised Rules at least thirty (30) calendar days before they become effective. The version of these Rules in effect at the time of the submission of the Request for Mediation to CentralNic shall apply to the Mediation commenced thereby.

DCA notes this is CentralNic’s current policy for its current registry businesses. DCA may make modifications to this Policy, without limitation by charging a reasonable fee and⁄or by specifying the mediation mechanism, as its business plans develop prior to launch of DotAfrica. However, DCA remains committed to offering a less formal and less expensive procedure than the UDRP, and perhaps even the URS, to the extent commercially feasible.

29.6 Abusive use⁄takedown policies
Answer to question 28 contains a detailed description of measures that the DCA DotAfrica gTLD Registry will take to prevent and mitigate abusive registrations and the description of policies that the DCA will apply to handle complaints regarding abuse and take down abusive registrations. To summarize;
 DCA will dedicate a single abuse point of contact. Correspondence and complaints coming through that point of contact will be continuously monitored and responded to within 24 hours.
 DCA will adopt a comprehensive Eligibility and⁄or Acceptable Use Policy that will set forth the limits of acceptable use of domains and the procedures the Registry will apply in case of violations of applicable laws or policies, including takedown procedures. The initial Eligibility and Acceptable Use Policy is provided in Section 29.9 below.
 DCA will delete orphan glue records once the parent domain is deleted to prevent abuse of these orphan glue records
 DCA will require registrars to perform extra checks on WHOIS data to improve its accuracy
 DCA will perform random audits of WHOIS data and will flag suspicious registrations via registrars

29.7. Post-Delegation Dispute Resolution Procedure
DCA reaffirms its intention to fully comply with the ICANN-mandated Post-Delegation Dispute Resolution Procedure (PDDRP).
DCA believes that its choice of TLD string and the way DotAfrica is intended to be operated represents a good faith offering of Top Level Domain Registry service and does not infringe on any legitimate third party trademark rights.

DCA also reaffirms its commitment to maintain DotAfrica free of violations of third party trademark rights through second level domain registration and use. DCA has all the required resources, policies and procedures in place to address any situations of abuse without the need to invoke the PDDRP procedure.

29.8. Resourcing
The Rights Protection Mechanisms described above include a combination of both technical and non-technical systems: for example, the Trademark Claims Service may (depending on the final specification published by ICANN) require development, maintenance and support of an EPP extension, as well as real-time integration with the TCH API, whereas the UDRP is a primarily manual process of managing and responding to communications from complaints, respondents and UDRP service providers.

As can be seen in the Resourcing Matrix found in Appendix 23.2, DCA DotAfrica Registry Services will maintain a team of full-time developers and engineers who will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to half of a full-time role.

Although DCA DotAfrica Registry will operate on a dedicated registry environment, the DotAfrica registry will be operated identically to CentralNic’s existing registry by the same team and supported by additional technical and local operations staff in Kenya, and will benefit from an economy of scale with regards to access to CentralNicʹs resources.

CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for DotAfrica (i.e., that which is required to deal with issues related specifically to DotAfrica and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that DotAfrica will use. After three years of operation, the optimistic projection for DotAfrica states that there will be 529,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore DotAfrica will require roughly 12% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of DotAfrica are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of DotAfrica for at least the first 18 months of operation.

29.9. Proposed TLD Eligibility and Acceptable Use Policy

1. Definitions

Registry TLD: DotAfrica Top Level Domain.
Registry: DCA DotAfrica Registry Services which is responsible, in accordance with its Registry Agreement, for operating the Registry TLD. Where applicable, the term “Registry” also includes the Registry’s service providers, agents and subcontractors.
Accredited Registrar: an entity that (i) has entered into a Registrar Accreditation Agreement with ICANN (ii) is authorised to provide domain name registration services for the Registry TLD, (iii) contracts with Domain Name Holders, and (iv) submits Domain Name Holders’ registration data into the Registry database.

Domain Name Holder: an entity that holds the domain name registration and is entitled to use it.
TLD Policies: this Acceptable Use Policy, ICANN consensus policies and such other policies as may be adopted by the Registry or ICANN for application to Registry TLD.

2. Introduction
This Acceptable Use Policy establishes the operational principles of the Registry TLD and sets forth rules relating to unacceptable use of a domain name in the TLD. It also describes the situations in which the Registry can intervene into functioning of a domain name in our TLD, and the procedures associated with such intervention.
3. Parties subject to this policy

This policy applies to:
a. The Registry;
b. Accredited Registrars; and
c. Domain Name Holders.

4. Eligibility
The DotAfrica TLD is open to registrations by all parties in accordance with registration rules.

5. Registration
A Sunrise period open to Trademark holders will precede a Landrush or Premium Name availability period during which applicants are able to register their interest for various domain names (in the event of conflicting requests, the names will be sent to auction). The Landrush phase will be followed by General Availability, during which time domain names will become available for purchase by any entity on a first-come, first-served basis.

6. Acceptable Use policy
Domain names can only be used for lawful purposes, i.e. in the manner that is not prohibited by the laws applicable in the jurisdiction where Registry is domiciled. The Registry is committed to maintaining the environment free from online crime, malicious or illegal activities. The Registry will investigate all reports of illegal activity and will cooperate with the competent governmental agencies in such investigations.

7. Enforcement
An action in enforcement of a TLD Policy may be triggered by a variety of events including reports from the public, registrars or ICANN, decisions of a competent dispute resolution provider, outreach from a governmental agency or findings produced by internal investigation or monitoring processes.
This paragraph describes default enforcement procedures.

7.1 Notice of Violation and Opportunity to Correct
In case the Registry encounters or is informed of any alleged violation of the TLD Acceptable Use Policies, by an Accredited Registrar or a Domain Name Holder, it will investigate the alleged violation. If the Registry, in its sole discretion, concludes that the Domain Name Holder has indeed violated a TLD Policy, it will normally request the Domain Name Holder to comply with this Policy within a thirty (30) days’ notice period.

The Registry may use any notification methods, but as a minimum it will send an email to the email address of the Administrative contact that is on record with the Registry. Such e-mail notification shall be deemed a sufficient notice.

7.2 Revocation
In case an inadequate response or no response has been received within the notice period given to the Domain Name Holder, the Registry may revoke the domain name registration without any further notice, and without the Domain Name Holder being entitled to any refund or damages resulting from such actions.

7.3 Interim Measures
During the applicable notice period, the Registry may, without liability to any other party, make inactive or otherwise change the state of the Domain Name in question, in which case, the Domain Name cannot be updated or transferred, and may not resolve.

In extreme situations where there is evidence that a domain name in a Registry TLD is used in connection with illegal or malicious activity including, but not limited to phishing, pharming, distribution of illegal content, distribution of malware, fast flux hosting, botnets, unauthorized access to information systems, or the domain name is used in a way that threatens security and stability of the Registry TLDs, the Registry reserves the right, in its sole discretion, to apply these interim measures as soon as practically possible, and prior to any notice to the Domain Name Holder.

In addition, the Registry reserves the right to apply these interim measures in its discretion; (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 as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by the Registry or any Registrar in connection with a domain name registration.

7.4 Registrar Assistance
The Registry may seek assistance from the sponsoring Registrar in enforcing the requirements of this Policy or other TLD Policies, and the Registrar will provide such assistance.

30(a).1. Introduction
CentralNicʹs Information Security Management System (ISMS) complies with ISO 27001. CentralNic is working towards achieving full ISO 27001 certification and has secured the services of Lloydʹs Register Quality Assurance (LRQA), a UKAS accredited certifier for its ISO 27001 certification. A letter from LRQA confirming this engagement is included in Appendix 30(a).1. Stage One of this process is scheduled during May 2012, with Stage Two occurring in July 2012. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.

30(a).2. Independent Assessment
As part of ISO 27001 compliance, CentralNicʹs security policies will be subjected to annual external audit. Further details can be found in §30(b).

30(a).3. Augmented Security Levels
DCA believes that .africa requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, DCA DotAfrica Registry will operate .africa to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.

Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast (ʺAnycastʺ) addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a ʺhotʺ Disaster Recovery site in the Isle of Man, as well as a backup provider relationship with GMO Registry in Japan.

30(a).4. Commitments to Registrars
DCA DotAfrica Registry will make the following commitments to .africa registrars:
 The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
 The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
 The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of .africa.
 The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
 Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
 Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
 Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.

30(a).5. Access Controls
DCA DotAfrica Registry will operate an access control policy for the registry system. For example, the web-based Staff Console which will be used to administer the SRS and manage registrar accounts will support a total of ten different access levels, ranging from ʺTraineeʺ, who have read-only access to a subset of features, to ʺSystem Administratorʺ who have full access to all systems.

Underlying server and network infrastructure will also be subjected to access control. A centralised configuration manager will be used to centrally control access to servers. Individual user accounts will be created, managed and deleted via the configuration server. Access to servers will be authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the ʺsudoʺ command which is logged and audited as described below.

Only operations personnel will have access to production environments. Development personnel will be restricted to development, staging and OT&E environments.

30(a).6. Security Enforcement
As per CentraNic protocol, security controls will be continually monitored to ensure that they are enforced. Monitoring will include use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) will trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
DCA DotAfrica Registry will operate a centralised logging and monitoring system (see §42), analyzing access logs in order to generate access reports which will then be reviewed by NOC personnel. This will include access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems will be investigated with a view to correcting any breaches and⁄or revoking access where appropriate.

30(a).8. Security Incident Response Policy
DCA DotAfrica Registry will operate a Security Incident Response Policy which will apply to all events and incidents as defined by the policy, and to all computer systems and networks operated by DCA DotAfrica Registry.

The Policy will provide a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It will also define the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).

The Policy will establish an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST will conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

The Policy will make use of DCA DotAfrica Registry’s support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy will also describe the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.

30(a).9. Role of the Network Operations Centre (NOC)
In addition to its role in managing and operating CentralNicʹs infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.

30(a).10. Information Security Team
As per CentralNic, DCA DotAfrica Registry will maintain an Information Security Team (IST) to proactively manage information security. The IST will be a cross-functional team from relevant areas of DCA DotAfrica Registry operations. These key members of staff will be responsible for cascading rules, regulations and information to their respective departments. They will also be the first port of call for their departmental staff to report potential security incidences and breaches. The IST will be members of an internal email group used to co-ordinate and discuss security related issues.

The IST will comprised the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
IST responsibilities will include:
 Review and monitor information security threats and incidents.
 Approve initiatives and methodologies to enhance information security.
 Agree and review the security policy, objectives and responsibilities.
 Review client requirements concerning information security.
 Promote the visibility of business support for information security company-wide.
 Manage changes to 3rd party services that may impact on Information Security
 Perform internal audits with the assistance of Blackmores.

30(a).11 Auditing and Review
ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. CentralNic’s IST periodically reviews the ISMS and conducts a gap analysis, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work. DCA DotAfrica Registry’s IST will follow the same review process.

30(a).12. Testing of Controls and Procedures
DCA DotAfrica Registry will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both ʺblack boxʺ testing of public registry services such as Whois and the Registrar Console, ʺgrey boxʺ testing of authenticated services such as EPP, and tests of physical security at DCA DotAfrica Registry’s offices and facilities.
DCA DotAfrica Registry will retain the services of a reputable security testing company such as SecureData (who, as MIS-CDS, performed the 2009 assessment of CentralNicʹs security stance). The results of this test will be used in annual reviews and audits of the ISMS.

30(a).13. DCA Security Policy
The following policy relates to DotConnectAfrica’s offices and systems rather than to the DCA DotAfrica Registry system.
30(a).13.1. Controls on Confidential Data

Data that relates to .africa are only accessible by authorized staff. Access to the system is via keys and passwords, no other staff can access the server and cabinets which store backups and confidential physical documents.

30(a).13.2. Storage of Records

Physical documents will be placed under lock and key accessible only to authorized persons. Regular auditing ensures that all information is secure.

Soft-copy data will be kept in a secured server with encryption that will ensure that data is not accessible to any third party. The server will be isolated from the rest of the network at all times to ensure that it is not accessible except for authorized access.

30(a).13.3. Storage of Credentials

Credentials to registry services are only authorized to one person who has access to the Registry Console, who works in conjunction with other staff to provide any necessary information.

30(a).13.4. Logging of Access

Access logs are monitored in a regular basis, all logins are recorded as well as a log sheets that lists the specific times that systems were accessed and the person that accessed the system.

30(a).13.5. Physical Access Controls

Alarm systems, razor fence perimeter wall with guards patrols with Alarm remote monitoring. All services are available 24x7.

30(a)13.6. Physical Security

30(a).13.6.1. Buildings

• Security, Access Control and CCTV
• Cameras installed at every entrance and at the perimeter of the facility
• Security access control is centralized
• Fence surrounds the facility backed up by security patrols.
• Logbook at entrance for records of all entrances into the Premises

30(a).13.6.2. Offices

• Proximity card with pin grants access to authorized personnel only.
• Cameras installed at every entrance into the building

30(a).13.6.3. Computer Equipment

• Proximity card with pin grants access to authorized personnel only.
• Every user has a designated workstation with monitored network access.
• Each workstation, laptops and tablet has password with a policy that all passwords must be changed in a regular period

30(a).13.6.4. Network Equipment and Infrastructure

• Equipment is located in a secured area that has an electric door with Logbook at the entrance for records of entrances into the data centre.
• No staff are allowed to access to equipment except authorized engineers
• Proximity card with pin grants access to authorized personnel only.
• All network infrastructure is secured in trunking and conduits, routine maintenance ensures that trunking is well secured and intact
• Wireless transmitters are placed beyond reach and well secured in braces.

30(a).13.6.5. Portable Media

• Staff are assigned USB sticks that are only authorized for internal storage and transfers.
• No portable media that belongs to company is allowed outside unless by express permission

30(a).13.6.6. Physical Documents

• Each business unit has a designated cabinet where they keep documents under lock and key
• All company documents are required to be filed and archived as necessary in chronological order.
• Access to these files is restricted to the said business unit unless by express authorization from the unit manager

30(a).13.7. Network Access Controls

• Network equipment is located in a secured area that has an electric door with Logbook which records all entrances into the data centre.
• No staff are allowed to access to equipment except authorized engineers
• All workstations, laptops, tablets, and printers are configured not to allow access to network settings except the network administrator.
• Firewalls, routers and all network equipment have secured passwords that are changed regularly
• Each business unit has its own VPN which restricts users from accessing beyond their VPN
• Users have access times and tickets which ensure that no one can access devices except during authorized hours.

30(a).13.8. Malware

• Staff are not allowed to access websites that are not work related and an access log for each PC is produced periodically to check this.
• Requiring the scanning of media from outside of the organization for malware before they can be used
• Requiring that e-mail file attachments, including compressed files (e.g., .zip files), be saved to local drives or media and scanned before they are opened
• Forbidding the sending or receipt of certain types of files (e.g., .exe files) via e-mail and allowing certain additional file types to be blocked for a period of time in response to an impending malware threat
• Restricting or forbidding the use of unnecessary software, such as user applications that are often used to transfer malware (e.g., personal use of external instant messaging, desktop search engine, and peer-to-peer file sharing services), and services that are not needed or duplicate the organization-provided equivalents (e.g., e-mail) and might contain additional vulnerabilities that could be exploited by malware
• Restricting the use of administrator privileges by users, which limits the privileges available to malware introduced to systems by users
• Requiring that systems be kept up-to-date with OS and application upgrades and patches
• Restricting the use of removable media (e.g., floppy disks, compact discs, USB flash drives), particularly on systems that are at high risk of infection,
• Specifying which types of preventive software (e.g., antivirus software, spyware detection, and removal utilities) are required for each type of system (e.g., file server, e-mail server, proxy server, workstation, personal digital assistant [PDA]) and application (e.g., e-mail client, Web browser), and listing the high-level requirements for configuring and maintaining the software
• Permitting access to other networks (including the Internet) only through organization-approved and secured mechanisms
• Requiring firewall configuration changes to be approved through a formal process
• Specifying which types of mobile code may be used from various sources (e.g., internal Web servers, other organizations’ Web servers)
• Restricting the use of mobile devices on trusted networks
• All workstations, laptops and servers are installed with antivirus software which automatically updates virus signature files to detect malicious software.

30(a).13.9. User Accounts and Passwords

• All the devices that are connected to the network are accessed via a domain logon which mean that they must connect to a domain and cannot be accessed as standalones unless during repairs and maintenance by authorized staff.
• Users are not allowed to have the same password on multiple systems.
• Account Lockout Policy settings, disables accounts after a specific number of unsuccessful logins. This disabled accounts can then be restored by the system administrator after proper explanation for the reasons why account was disabled
• The system has an enforceable password history to ensure that all new passwords are unique ,also there is a maximum password age after which the user is required by the system to automatically change the passwords
• Passwords must meet complexity requirements, i.e. contain Uppercase, lowercase, numerals, non-alphanumeric and Unicode characters this ensures that all passwords are strong enough.
• All accounts and devices connected to specific domains have a routine audit to ensure that vulnerabilities and illegal attempts for log in are mitigated and accessed.

30(a).13.10. Communications with Stakeholders

• Our organization has in place mechanisms to enable unrestricted access to the Local law enforcement officers that are in proximity to the organizations offices.
• DCA will establish a channel of communication and format with which to reach ICANN as the authority, these communications will include mandatory routine communications required between the registry and ICANN as per normal registry operations
• In Conjunction to above normal operations, DCA intends to communicate to ICANN in cases where there is need for urgent mitigation measures arising from issues related to running of registry, conflicts and all other issues deeded to arise in the course of normal business.
• DCA will keep a log of all relevant emails, fax and telephone numbers to be used appropriately for each communication.
• Alternative ways to complete all remittances have been made in advance shall the normal authorized channels be unavailable due to unavoidable circumstances to ensure that all regular operations are sustained.
• In cases where such measures cannot be carried out completely, appropriate notifications shall be made to ICANN or any other affected persons in advance to explain failure to perform the regular actions thereof via email.

Mr. Barry Ryan	Corporate Advisor
Mr. Gedion Rop	Project Support Engineer (DCA)
Mr. Samuel Ochanji	Project Analyst⁄Coordinator(DCA)
Mr.Gavin Brown	Chief Technology Officer (CTO) of CentralNIC
Mr.James Waweru	CISCO Engineer (DCA)
Mr.Julius Muchoki Maina	Chief Accountant (DCA)
Ms. Sophia Bekele	Executive Director⁄Chief Executive Officer(CEO)
Paul Kuria	Social Media Engineer⁄Web Development Consultant (DCA)

Mr.Shanil Ramtohul	As Trustee of DotConnectAfrica Trust
Ms. Kim Elisabeth	Trust⁄Manager of Trust Fund- DotConnectAfrica
Ms.Sophia Bekele	Executive Director (Sophia Bekele is also Protector of DotConnectAfrica Trust)

New gTLD Application Submitted to ICANN by: DotConnectAfrica Trust

String: africa

Originally Posted: 13 June 2012

Application ID: 1-1165-42560

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.