Application number: 1-1243-89583 for UniForum SA (NPC) trading as Registry.Africa

UniForum SA (NPC) trading as Registry.Africa

COZA House, Gazelle Close
Corporate Park South
Midrand Gauteng 1685
ZA

+27 11 314 0077

+27 11 314 0088

http:⁄⁄www.AfricaInOneSpace.org

Mr. Neil Duncan Dundas

Director

+27 82 468 1858

+27 11 314 0088

ndundas@registry.net.za

Ms. Simla Rathilal Budhu

Manager - Legal & Policy

+27 82 575 0926

+27 11 314 0088

sbudhu@registry.net.za

Not for Profit Company (NPC)

Initially incorporated as a Section 21 Company (Not for Gain), under the Companies Act of 1973, with the Registrar of Companies (Companies and Intellectual Property Registry Office - CIPRO)
In terms of the new Companies Act of 2008, has been reclassified as a Not for Profit Company, registered with the South African Companies and Intellectual Property Commission (CIPC)

Not Available

Not applicable

Not applicable

BROWNE, Calvin Scott
Director
DUNDAS, Neil Duncan
Director
ELKINS, Mark James
Director
KRAMER, Theodorus
Director
WALLACE, Fiona Jean
Director

BUDHU, Simla Rathilal
Legal & Policy Manager
ELS, Lizette
Administration Manager
MAASDORP, Sedrick Marco
Human Resoruces Manager

EL BASHIR, Mohamed
Chairperson: dotAfrica Steering Committee

africa

Not Available

There are no known issues, specific operational or rendering problems with the applied for string. It is a Latin alphabet based string that conforms to the specifications laid out in RFC 1035.
As with all new TLDs there is the potential for legacy applications to fail to recognize the new TLD string. Some older applications may have hardcoded lists of ʺvalidʺ TLDs or, worse case, assume anything that is not ʺ.comʺ, ʺ.netʺ or ʺ.orgʺ to be invalid. There are existing initiatives, including The Public Suffix List operated by the Mozilla Foundation, which the Applicant will work with to help educate the broader Internet Community.

Introduction: Mission, Vision and Purpose:

UniForum SA is a non-profit company incorporated in South Africa and trading as the .ZA Central Registry (“ZACR”). The African Union Commission (AUC) has, on behalf of its member states, officially appointed UniForum SA to apply for and launch the dotAfrica TLD. 

In this application the Applicant may be referred to as UniForum SA, Registry.Africa, the ZA Central Registry and⁄or simply ZACR. Although it is the intention of the Applicant to conduct its business under the Registry.Africa banner in the event that its application is successful, the evaluating team should, for purposes of this application, consider any reference to UniForum SA, Registry.Africa, ZA Central Registry and⁄or ZACR as interchangeable and synonymous with the Applicant. 

The ZACR and its partners in Africa, representing governments, ccTLD administrators, the technical and user communities, share a collective vision of establishing and running a successful, African-based registry operation for the benefit and pride of Africa. 

Our primary objective and mission can therefore be summarised as follows: “To establish a world class domain name registry operation for the dotAfrica Top Level Domain (TLD) by engaging and utilising African technology, know-how and funding; for the benefit and pride of Africans; in partnership with African governments and other ICT stakeholder groups”.

Our mission is to establish the dotAfrica TLD as a proud identifier of Africa’s online identity, fairly reflecting the continent’s rich cultural, social and economic diversity and potential. In essence we will strive to develop and position the dotAfrica TLD as the preferred option for individuals and businesses either based in Africa or with strong associations with the continent and its people.

The dotAfrica TLD represents a unique opportunity for Africa to develop and enhance its domain name and Internet eco-systems and communities by collaborating with each other to: 
- identify, engage and develop African-based specialist skills and resources; 
- share knowledge and develop DNS thought-leadership; and 
- implement world class registry standards and contribute towards their continued development.

By Africa, for Africa:

The dotAfrica TLD is a collaborative, public-private, African initiative, supported by African governments through the African Union and administered through the expertise and resources of the private sector. Shortly after its appointment in terms of the African Union RFP process, the Applicant, in consultation with Internet community representatives from all over Africa, at a meeting held in Johannesburg, established a Steering Committee to exercise moral and ethical oversight over the dotAfrica project. 

Representatives of the broader African Internet community are currently participating in the project through the SteerCom, which comprises African Internet experts, country code managers, registrars and others volunteers. For a list of the SteerCom members refer to www.AfricaInOneSpace.org. 

The SteerCom is engaged under formal Terms of Reference, which include, amongst others, a mandate to identify the criteria and processes for the incorporation of a new non-profit organisation, namely the dotAfrica Foundation. The SteerCom is therefore the precursor to the dotAfrica Foundation, which will work closely with the Applicant in assuming the moral and ethical oversight of the dotAfrica TLD and the development of policy issues. The SteerCom will be dissolved once the Foundation is incorporated and established.

Benefitting the African and Global Internet Communities:

Reinvestment into Africa:
Funds generated through the administration of the dotAfrica TLD will benefit Africans and the African continent through various skills development and capacity-building initiatives relating to the local domain name and Internet sectors. By investing in the development and enhancement of critical Internet infrastructure and resources, end-users will receive more efficient and reliable services, which will have a follow-on enabling effect on socio-economic growth and investment in the region.

Upon delegation of the dotAfrica TLD the Applicant will establish a Development Fund, which will comprise surplus operational funds generated through the administration of the dotAfrica gTLD. This Fund will be transferred to and administered by the dotAfrica Foundation, to be applied to development projects and initiatives in Africa. These include:
 
(A) The Development of African ccTLDs:
ccTLDs provide important Internet infrastructure that promote and support local economic growth, education and communication. The Development Fund must support the role of existing organisations such as AfTLD and strengthen and develop new African ccTLDs. Primary objectives of this development initiative are to: 

(i) make available and⁄or share technical resources and know-how, developed and maintained in Africa; 

(ii) develop and harmonise African ccTLD strategy and policy to make it more attractive and accessible to local and international markets; 
(iii) harness and optimise the business potential that ccTLDs present, and to develop domestic strategies and partnerships to facilitate the dissemination of benefits down the domain name value chain; and 

(iv) establish collaborative centres of excellence throughout Africa through which new technical skills and thought leadership can thrive and develop. 

(B) The Development of the African Registrar Market:
Of the over 900 ICANN-accredited registrars in the world, more than 500 are based in the United States, whilst Africa has only 5. Of these only 4 are operational. Africa is clearly lagging behind its international counterparts and a solution must be found from within Africa. 

The Development Fund must support and facilitate the expansion of the African Registrar market. Some of the broad objectives of this development initiative are to: 
(i) promote awareness of (and engage with) the registrar model as a mechanism for domestic and regional enterprise and skills development; 

(ii) develop and implement industry best practices and consumer (registrant) protection mechanisms; 

(iii) develop and provide shared, cost-effective resources and services; 

(iv) collectively address associated business challenges, including billing and banking issues; 

(v) provide a mechanism for registrars to enter the market and to nurture their businesses into becoming globally competitive and viable; and 

(vi) harness the business potential of a competitive and vibrant registrar market for the benefit of African registrants and ccTLDs. 

(C) The Development of African Online Content: 
The dotAfrica project is a fantastic opportunity to drive content development focusing specifically on Africa. In order to kick-start this process and achieve some level of critical mass, the Applicant will reserve certain high-search value names and then utilise these, either on its own or through strategic partnerships with content providers, to develop online content and services. The Development Fund must support and facilitate the origination, development and maintenance of African-related online content and services. 

Some of the broad objectives of this development initiative are to: 

(i) Encourage existing African content and service providers to associate their content with the dotAfrica TLD in order to better engage with this user community. This is specifically relevant to African online content and service providers who utilise gTLDs instead of African ccTLDs. Potential targets for this initiative include African governments and agencies, large multi-national and parastatal organisations.
(ii) Develop strategic partnerships and associations with existing, well-established international online content and related services providers, to encourage and assist them to develop and customise their products and services specifically for the African market. Potential targets for this initiative include social media platforms, search engines providers, and leisure and business service providers.
(iii) Establish partnerships and associations with African service providers and businesses with the potential and capacity to develop sound business models for developing and driving online content and services; and assist them by making available high-search value names, start-up funding, technical support and mentoring, etcetera.

(D) The Support of Socio-Economic Development Projects and Initiatives: 

The Applicant, through its administration of the successful CO.ZA domain name space in South Africa over the past 16 years, has already demonstrated its ability to establish and maintain a highly successful and sustainable social development initiative through its ‘CoZa Cares’ division. By 2011, this division, in collaboration with its strategic partners, had channelled over ZAR40mill (USD5,5M) towards the establishment of ICT infrastructure in over 250 schools, in 7 South African provinces. 

The Development Fund must support and facilitate various African socio-economic development initiatives and projects relating to the ICT sector. Supporting ICT skills development and capacity-building initiatives, from primary school to tertiary level, is critical to develop the African thought leaders of tomorrow. 

The broad objectives of this development initiative are to: 

(i) facilitate the coordination of various ICT-related social-economic development initiatives in Africa, in order for the various participants to learn and benefit from each others’ experiences and, where possible, to pool resources and expertise in order to address developmental challenges faced by Africa more effectively; and
(ii) identify and support worthy ICT-development projects and initiatives throughout Africa in order to ensure their sustainability.

Although the above development initiatives and projects undertaken by the dotAfrica Project partners are almost exclusively focused on the African community, we believe that there is a compelling benefit for the rest of the world. Africa comprises nearly 1 billion people, based in 54 countries with a wide diversity of language and culture. A successful dotAfrica TLD, supported by an empowered and vibrant African community, presents significant business, social and leisure opportunities for the world. Success in Africa means success for the world. 

In addition to the development projects and initiatives administered through the dotAfrica Foundation, the Applicant will endeavour, as part of its registry operations, to establish a Centre of Excellence, in terms of which African specialist skills and expertise, relating to the DNS environment, will be identified and developed. Specialist DNS expertise is a critical success factor in order to benefit the dotAfrica registry operation and African ccTLDs. The development of African DNS thought leadership and technical innovation is needed in order to sustain the empowerment of African ccTLDs.

Building a Global Brand with a Focus on Africa:

Africa, the Cradle of Humankind: 
“Africa is the worldʹs second-largest and second-most-populous continent, after Asia. Africa, particularly central Eastern Africa, is widely regarded within the scientific community to be the origin of humans and the Hominidae clade , as evidenced by the discovery of the earliest hominids and their ancestors, as well as later ones that have been dated to around seven million years ago.” (wikipedia)

Africa, the Economic Opportunity: 
“The economies of the fastest growing African nations experienced growth significantly above the global average rates. Many international agencies are gaining increasing interest in investing emerging African economies, especially as Africa continues to maintain high economic growth despite the current global economic recession. The rate of return on investment in Africa is currently the highest in the developing world.”

Differentiation of dotAfrica from other new gTLDs:
There will be many arguments raised by registries in differentiating their new gTLDs from others. As a geographic indicator, the dotAfrica TLD, which is unique in essence, will automatically assume the reputation and goodwill of the region it represents. Africa represents a unique part of the world, with unique people, challenges and prospects. dotAfrica, therefore presents an opportunity to engage with the region and its people, thereby potentially unlocking the economic and social potential of a vast and diverse continent. 

Whilst there are 54 ccTLDs that could potentially serve the needs of the African Internet community, not a single one of these is ideally positioned to provide a collective identity to the continent as a whole. With many of these ccTLDs in turmoil or unable to provide reliable services, dotAfrica will offer a secure, stable, and open TLD that will be recognized in Africa as well around the world.

Marketing, Communication and Public Relations:
The marketing of the dotAfrica domain name brand will occur in terms of a defined strategy to create competitive advantages to governments, businesses and individuals within Africa and abroad. The entire African continent has unique needs, cultures, and political realities, market requirements and socio-economic conditions, which are influenced by internal and external forces. These variables need to be taken into account in our marketing and communication strategy with our various stakeholders. 

Multiple media tools must be used in the dotAfrica marketing strategy. Radio remains a major source of information throughout Africa, but mobile penetration must also be used to dotAfrica’s advantage. Broadband penetration outside of a very small number of countries has been limited, but Internet access via mobile telephone is on the rise. Digital and pay-for-service television access is on the rise. The vast target market needs to be segmented, in order to develop key messaging for each market sector. Each dotAfrica registration will help fund the dotAfrica Foundation that has the core mandate to promote digital inclusion, social development, and technical development of the Internet in the region. 

A dotAfrica domain name is the perfect platform for global branding, marketing, and visibility with a focus on customers and markets in Africa which can help increase tourism, build and enhance international business relationships with Africa, and boost economic benefits. The marketing and communication campaign for dotAfrica is already using a number of communication platforms to create awareness and communicate with the various stakeholders, including: Facebook & Twitter and; dotAfrica website (africainonespace.org); and dotAfrica mailing lists. Traditional media such as newspapers, and radio and modern digital media have been used to spread the dotAfrica message. An African multi-stakeholder committee comprising of diverse skills has been established to focus on activities and strategy required for a successful PR campaign.

Registry Operations: 
From a technical⁄operational perspective the dotAfrica TLD registry will operate on the Extensible Provisioning Protocol platform, which is an internationally accepted standard for registry functions across the world and which has the flexibility to incorporate extensions such as DNSSEC and extensions pertaining to domain specific policy requirements. The dotAfrica registry platform is wholly developed, maintained and hosted in Africa. 

The applicant has a highly experienced team of experts dedicated to the on going development, maintenance, administration and training of the core registry services. The dotAfrica registry platform, which has been developed, implemented and maintained on the back of over 17 years registry experience by the Applicant, also provides WHOIS services, Secure EPP Message Handling, DNS and DNSSEC services. A key point of the registry system is the flexible Policy Integration and configuration independent of the core development team. 

As part of the global DNS environment, the dotAfrica registry platform also integrates with specialist 3rd party DNS related systems and services, which when viewed collectively, provides a mature comprehensive, well-balanced world-class registry solution for dotAfrica. External systems and services compliant with industry best practises and ICANN requirements include: Data Escrow services; Anycast and Unicast services; and Off-site Hot Standby Failover Hosting.

We envisage that the investment by the Applicant into the development of the African ccTLD and Registrar communities will encourage the adoption and implementation of unified standards and policies across the Africa region. This should in turn facilitate the growth of a competitive and sustainable registry⁄registrar market and cost savings and efficiencies for registries that collaborate on the implementation of shared services and systems. 

Preliminary steps have already been taken to create awareness and engage with the African registrar and registry communities on the subject of the proposed dotAfrica registry system. A wiki site which highlights the Applicant’s EPP functionality and provides a walkthrough for current and potential registrars has been created at http:⁄⁄registry.net.za

Apart from providing a platform for growth of the cctLD and registrar communities, the dotAfrica registry solution allows registrars access to a number of key services including an automated Registrar Accreditation Process, reporting and tracking, a Registry Notification Portal, and a secure flexible interface for retrieving financial statements and invoices. This allows for the registration and maintenance of domain names by registrars and results in ease of domain registration for registrants. 

More importantly it provides a registry platform that promotes simple, accessible, secure, accurate and abuse free domain registration by registrars and ultimately the end user. The dotAfrica TLD registry function will be managed in a way that is service driven, secure and stable.

Registration Policy:
The dotAfrica registration policy will be established, implemented and maintained through a multi-stakeholder Policy Committee established by the Applicant in partnership with the Steering Committee or the Foundation. The registration policy will set out the technical and administrative procedures and criteria used by the registry with regards to domain name registrations or requests for such registrations, cancellations, transfers, suspensions and revocations. The policy will be informed and guided by those developed through the ICANN multi-stakeholder process. 

Although a comprehensive final registration policy must still be approved, the broad parameters of the registration policy will include: 

(i) following the Sunrise and Land Rush periods, registrations will be delegated on a “first-come-first-served” basis; 

(ii) registrations will be open to anyone; 

(iii) access to the registry will be available only through an ICANN-Accredited Registrar who has executed a suitable accreditation agreement with the registry; 

(iv) registration periods will range from 1 – 10 years. 

Similar criteria will apply to the establishment, implementation and maintenance of a privacy policy for the dotAfrica TLD that is based on international best practices as well as local and international standards. The registry will strive to protect the rights and privacy of all individuals or companies associated with dotAfrica TLD names.

Financial Aspects: 
The Applicant, over 17 years of administering the successful CO.ZA domain in South Africa, has demonstrated an ability and capacity to manage and administer its financial affairs in a professional and transparent manner. The Applicant has maintained highly competitive fees charged to registrars within reasonable international parameters. Simultaneously it has generated reasonable surplus funds, not only to provide a suitable operating buffer for the efficient and effective operation of the registry, but also to fund social development initiatives and projects. 

The Applicant will, under the scrutiny and oversight of the SteerCom or Foundation, apply similar financial disciplines and procedure to the administration of the dotAfrica TLD. As outlined above, the operating revenues generated through the administration of the dotAfrica TLD will be accounted for in accordance with internationally-accepted accounting practices. All surplus funds will be channelled into a Development Fund to be administered by the dotAfrica Foundation.

Although the financial parameters and policies must still be finalised and approved by the Policy Committee, the following are of importance concerning the application and launch of the dotAfrica TLD. The Applicant has made available up to US$1,300,000 to apply for and launch the dotAfrica TLD. The above funds have been committed to a dedicated dotAfrica bank account that will be used exclusively for the dotAfrica project. 

The Applicant has provided a Continual Performance Guarantee to ICANN of US$140,000 with ABSA Bank, a subsidiary of Barclays Plc to secure the provision of critical registry services for the dotAfrica TLD for up to 6 years. Initial registration fees are estimated to be in the region of US$18 per year. Due to its considerable investment into its technical registry capacity for .ZA, including the procurement and development of technical skills and resources, the Applicant is able to leverage this against the provision of critical registry services for dotAfrica in the event that the TLD is commercially unsustainable in its own right.

Rights Protection:
- Reserved Name Lists (Pre-Sunrise)
- Sunrise 
- Post Delegation Dispute Resolution

The ZACR is committed to protecting the rights of governments, registrars, end users and the greater Internet community against fraudulent, deceptive and unfair business practices that may arise within the dotAfrica TLD. Abusive practices will be minimized through the following initiatives:

(A) Pre-Sunrise:
A pre-sunrise process will take place prior to the full-scale implementation of the Sunrise and Land-rush Policy applicable to the dotAfrica TLD. This is significant as it will provide African governments and government organisations, such as the African Union Commission (AUC), a window of opportunity to compile and submit a list of names that must be reserved or blocked from registration. These names may touch on sensitive territorial or political issues; hold special meaning in Africa (such as country names, city names, cultural sites or groups); or are simply offensive in Africa. 

The Pre-Sunrise process will be done in coordination with the AUC on the terms and conditions agreed to between the AUC and the ZACR in their agreement signed on 1 March 2012 and will also be subject to all reservations prescribed by ICANN (included but not limited to reservations regarding the label ‘example’, two character labels, tagged domain names, prescribed registry operation names, country and territory names, etc.) as well as the GAC principles regarding new TLDS.

Names placed on the Reserve Lists will only be available to pre-defined Applicants who will be expected to apply for the names within a period of time prescribed by the dotAfrica Policy Committee. 

(B) Sunrise: 
A phase-based Sunrise procedure, with associated auction processes, will be implemented to allow established brands and trademark holders to register their corresponding domains within the dotAfrica TLD. Although the Policy Committee must still approve a final Sunrise Policy, a draft policy has already been developed and is currently under review. This policy caters for two Sunrise periods, namely:
- Sunrise 1, which provides priority for eligible owners of trademarks registered in Africa to obtain corresponding domains names.
- Sunrise 2, which allows eligible owners of trademarks to obtain corresponding domains names.

The ZACR will appoint an independent entity or entities to provide certain rights protection services which may include inter alia verification, validation, and dispute resolution services related to the eligibility of trademarks. In this regard the ZACR will endeavour to engage the services of African providers and institutions and has in the past worked closely with the South African Institute of Intellectual Property Law (www.SAIIPL.org.za) concerning the establishment and implementation of alternate dispute resolution mechanisms in ZA.

The final Sunrise Policy will also provide further details and clarity on Sunrise Eligibility Requirements (SERs) and a dedicated dispute resolution policy and mechanism for this phase.

(C) Land Rush
Just as in the Sunrise period, Land Rush will be implemented over several phases and will be administered through the Applicant’s Registrar Web Portal. Although the Policy Committee must still approve a final Land Rush Policy, a draft policy has already been developed and is currently under review. This policy caters for three Land Rush phases, namely:
- The first phase is the “Introductory Land Rush Period” and will see premium domain names made available for purchase for certain periods at time at a certain minimum prices which will decrease as the periods progress. Where there is more than one party interested in the same domain name, that domain name will be referred to auction. 
- The second phase is the “Initiation Land Rush Period”. This period will last for an estimated 14 days and will also be administered through the Registrar Web Portal. A minimum fee (roughly $300 - $500) will apply to registrations during this period. Multiple applications for the same domain name during this period will also be resolved using an auction process. Undisputed applications will be allocated at the end of the period.
- Depending on the decision made by the Policy Committee, the ZACR may elect to implement a “Limited Availability Operational Phase”, following on from the Initiation Land Rush period. This mechanism, which will endure for a limited time (0-14 days) will be to place any newly requested domain name (application) in a reserved queue for a short period. If any additional applications for the same domain name are received during this period then the domain will enter a Land Rush auction for a maximum predetermined period. At the end of the period the bids will be collected and the winner determined. This process, or a process similar to this, may also be introduced by the ZACR on an adhoc basis to mitigate the effects of multiple applications for the same name following domain release as well as spontaneous applications due to international events or announcements

(D) All Rights Protection Mechanisms prescribed by ICANN will be implemented. In particular, the Uniform Rapid Suspension System (URS) will be adopted. Initially, Examiners accredited by ICANN appointed Dispute Resolution Service Providers (according to the Applicant Guidebook Module 3, paragraph 3.2.3) will be requested to make findings in URS applications, but the Registry hopes to arrange for the appointment of a board of suitably qualified Examiners particularly in Africa to make findings in these matters. 

In the case where a Post Delegation Dispute Resolution Procedure (PDDRP) is initiated following allegations that the Registry profited from a bad faith registration, the Registry undertakes to participate in the procedure and be bound by the determination made. This will be specifically included in the agreement with prospective applicants for domain names in this TLD. Providers accredited by ICANN as Dispute Resolution Service Providers (according to the Applicant Guidebook Module 3, paragraph 3.2.3) will initially be requested to stand as Providers in PDDRP applications, but the Registry hopes to arrange for the appointment of a board of suitably qualified Examiners particularly in Africa to make findings in these matters. 

Provision will also be made to file initial complaints that the Registry has not complied with registry restrictions through a Whois Data Problem Report System (WDPRS) through InterNIC.net at a nominal, non-refundable fee. If a complainant is not satisfied that the Registry has complied with its requirements, the matter may be escalated using the RRDRP. 

In the case of Registry Restrictions Dispute Resolutions Procedures (RRDRP), the Registry undertakes to participate in the procedure and be bound by the determination made. This will be specifically included in the agreement with prospective applicants for domain names in this TLD. Providers accredited by ICANN as Dispute Resolution Service Providers (according to the Applicant Guidebook Module 3, paragraph 3.2.3) will initially be requested to stand as Providers in RRDRP applications, but the Registry hopes to arrange for the appointment of a board of suitably qualified Examiners particularly in Africa to make findings in these matters.

A dedicated online advisory ⁄ complaints portal will be created and end-users will have access to email, telephone and fax contact details of an appointed Complaints Officer who will attend to complaints directly or escalate them to the relevant divisions within the registry for resolution. A comprehensive Complaints Handling Policy, that sets out inter alia the scope and ambit of complaints that will be dealt with; the process that must be followed to deal with domain related complaints; and the course of action that the registry may take to deal with complaints depending on their nature, will also be drafted in consultation with the dotAfrica Policy Committee.

(E) The Policy Committee (PC), which is a multi-stakeholder consultative mechanism, will play a determining role in defining policy and determining pricing mechanisms within the dotAfrica TLD. The scope and mandate of the PC will include the review and authorisation of various pricing models, including multi-year (1 – 10 years) pricing, bulk discounts and prices changes. The PC will consider the input and comments of the Registry Operator, the Foundation, Registrars, the broader Internet community and other factors concerning the affordability and competitiveness of the TLD in determining policy, prices and⁄or or price changes. 

The PC will, after due consideration and where circumstances reasonably allow, first publish a proposed policy or price update schedule for public comment on the Registry’s website and will also circulate this to the Registrar mailing lists. The proposed update schedule will also include a description of the implementation roadmap for these changes to come into effect and prescribe a deadline for further comments and objections to be submitted for consideration.

Upon final review, taking into account the input provided and objections raised during the public inspection period, the PC will provide a final policy to the Registry Operator for implementation in the manner prescribed. The Registry Provider will then publish the policy on its website and duly inform all accredited Registrars and ICANN of the policy change. The Registry Operator will then ensure that the policy is implemented as published. 

PARAGRAPH ON IMPLEMENTATION OF IDN WITHIN THE DOTAFRICA gTLD REGISTRY FUNCTION


Some of Africa’s languages are non-Latin scripts for example Arabic and Amharic and also many African languages are written with extended Latin scrip. Africa has diverse cultural, religious and language groups so the impetus to facilitate IDN integration within the dotAfrica gTLD framework clearly exists. The ZACR has the technical knowledge and the specialized skills needed to add IDN capability within the dotAfrica gTLD registry function but believes that it would be premature to implement IDN integration without fully understanding the technical, legal and policy ramifications that this may have in Africa and elsewhere.

Whilst the implementation of IDN is not a new phenomenon internationally, its implementation in the African context will definitely be new. Associated to this is the fact that the African internet⁄domain name community has to be developed in terms of the beneficiation model described earlier in this submission so that it matures in terms of infrastructure, policies and human potential to a stage where the incorporation of IDN becomes axiomatic. Given the diversity and uniqueness of the management model of the dotAfrica gTLD domain name registry and the sensitivities surrounding language issues, the ZACR believes that it would be wise to reserve this issue for future research, discussion, debate and policy development under the guidance of a Policy Oversight Committee. 

The ZACR intends to engage with those registries that have implemented IDN capability within its registry function to learn from their experience. More especially the ZACR plans to engage⁄consult with the broader African internet community, involving representatives from governments, registries, registrars as well as other experts and end users to investigate and resolve the challenges that IDN integration may present to Africa.

No

Not Available

Yes

The ZACR is aware of the GAC adviceon this issue and will take it into consideration in their management of second level domain name registrations and further confirms that it will comply with Specification 5 of the Registry Agreement.

Specification 5 of the New gTLD Registry Agreement initially reserves at the 2nd and all other levels within the TLD:
- Country and territory names contained on the ISO 3166-1 list
- UN Group of Experts on Geographical Names, Technical Reference Manual for the Standardisation of Geographical Names, Part II Names of Countries of the World, and
- The list of UN member states in 6 official UN languages prepared by the Working Group on Country Names of the UN Conference on the Standardization of Geographical Names

In accordance with the provisos contained in Specification 5, such names may be released if the Registry Operator reaches agreement with the applicable government and⁄or the Registry Operator proposes release of the reserved name(s) subject to review by GAC and approved by ICANN.

The Registry will work cooperatively with ICANN to ensure that the 2nd and subsequent levels of the proposed TLD comply with expressed public policies and goals and in particular the following:

1. It is worth noting, as documented by ICANN, that rights of governments or public authorities in relation to the rights of the sovereign state or territory which they represent cannot be limited or made conditional by any procedures that ICANN introduces to new gTLDs. The ZACR will follow the GAC public process relating to geographic names

2. The ZACR will use existing recognised international lists as prescribed by ICANN. The lists will be reserved at the second level at no cost to the governments of the dotAfrica TLD. It will be the prerogative of the relevant governments to adopt 
procedures that allow for applicants to register names from any of teh reserve lists.

3. The AUC shall within three months into force of the agreement with the ZACR, allow member states to submit to the AUC and other member states a limited list of broadly recognised names with regard to geographical and⁄or geopolitical concepts which affect their political or territorial organisation that may either:
- not be registered or
- be registered only under a second level domain according to the public policy rules

4. The African Union Commission (AUC) will furnish the list of notified names to which such criteria apply, and the AUC shall also publish the list at the same time as it notifies the ZACR

5. Where a member state or the AUC within 30 days of publication raises an objection to an item included in the notified list, the ZACR will take measures to remedy the situation

6. Before starting the registration operations, the ZACR will adopt the initial registration policy for the dotAfrica TLD in consultation with the AUC and other interested parties. The ZACR will implement in the registration policy the public policy rules pursuant to the agreement between the AUC and the ZACR taking into account the exception lists and the GAC process as prescribed in the principles regarding new gTLDs.

7. It should be noted that the AUC shall retain all rights relating to the dotAfrica TLD, including in particular, intellectual property and other rights to the registry databases required to ensure the implementation of the agreement between the AUC and the ZACR, and the right to re-designate the registry function.

1 Synopsis

This chapter provides a description of the registry services provided by the
ZA Central Registry including domain provisioning services, domain and
contact publishing services, zone publishing services, and services for inter-
acting with accredited registrars, (Registrars), oversight bodies and statu-
tory bodies such as the judiciary and accredited dispute resolution providers.


2 ZA Central Registry Details
Registry Name:- UniForum SA trading as the ZA Central Registry.
Registry Address:- PO Box 4620, Halfway House, 1685, South Africa.
Registry Contact Number:- +27113140077
Registry Fax Number:- +27113140077
Registry eMail:- gtld@registry.net.za
Registry URL:- http:⁄⁄www.coza.net.za and http:⁄⁄registry.net.za


3 ZA Central Registry Background

UniForum SA, trading as the ZA Central Registry, was established as a non-
profit organisation in 1988 by a group of end users, developers, and vendors
who got together to form a professional association that would promote and
exchange information on open systems. It was handed the responsibility of
administering the CO.ZA domain name space in 1995 because it was seen
as not only having the technical skills to do so but also seen as committed
to neutrality and unity of purpose.
At startup the co.za zone contained around 400 entries. Today, with over
760000 domains in the co.za zone amounting to over 95 % of the total
registrations in the .ZA top level domain are to be found in the co.za domain
and within the top 20 registries world wide.
Over the years UniForum SA played active roles in the internet industry
including, but not limited to, the following

 • establishing the alternate dispute resolution process for adjudicating
 domain name disputes in the co.za domain.

 • translating the CO.ZA registry web site into all 11 official languages
 of South Africa as far back as 2001.

 • cooperating with a range of other industry bodies to drive the growth
 of the South African Internet. We joined the South African Internet
 Service Providers Association (ISPA) in 1996, and have since worked
 with ISPA on a range of web and social responsibility projects.

 • sponsoring and participating in the ISPA “Train the Teachers“ initia-
 tive.

 • by addressing and sponsoring learner education, educator development
 and the provision of IT infrastructure and curriculum development
 through the Mindset Computer Science Curriculum project, COZA
 Cares School of the Month project and ISPA Teacher Training initia-
 tives.

 • participating in important debates, for example, by making contribu-
 tions to parliamentary discussions about important laws with wide-
 reaching consequences for South African Internet users such as the
 Electronic Communications and Transactions Bill, providing regular
 input to the ZADNA on domain related issues and providing regular
 DNS training to the South African Internet community at large.

 • transitioning the CO.ZA registration into a world class EPP registry.

 • collaborating with South African Domain Name Authority (ZADNA)
 in transitioning into the ZA Central Registry in order to administer
 all open second level domains including .org.za, .net.za, and .web.za
 as 2nd level domains in .ZA.

In summary, UniForum SA has served as a non-profit organisation that exists
for the good of the South African Internet. We are proud to have remained
true to the basic premise that surplus funds raised beyond covering our
expenses are invested back into the greater Internet community. Although
our role and the way forward might be changing, our principles and ideals
have remained constant for more than 24 years and will endure into the
future.


4 Registry Registrar Services and Operations

This section provides details on the technical operational services critical
for the provisioning of domains, contacts and hosts as well as the services
related to both publishing domain, host and contact information and the
publishing of zone information as provided by the ZA Central Registry and
as intended for use by the dotAfrica TLD.



4.1 Domain Registration Services

This section provides details on the receipt of data originating from Regis-
trars concerning domain name, contact and nameserver (host) registration.
All registration data from Registrars must be received over a secure TCP⁄IP
connection conforming to the EPP protocol as defined by the IETF Stan-
dard 69, and in particular RFC5730 to RFC5734 as listed below.

Domain Mapping:- Data format for each EPP command must conform
 to RFC 5731 with each data unit conforming to section 4 of RFC 5734.

Host Mapping:- Data format for each EPP command must conform to
 RFC 5732 with each data unit conforming to section 4 of RFC 5734.

Contact Mapping:- Data format for each EPP command must conform
 to RFC 5733 with each data unit conforming to section 4 of RFC 5734.


4.2 Registry Zone Dissemination

The zone is published once every 15 minutes which may change from time
to time depending on the policy for the dotAfrica TLD and the size of the
zone.


4.3 Registry Zone Servers

The dotAfrica TLD will use nameserver infrastructure supplied by the ZA
Central Registry including 2 anycast instances geographically dispersed in-
cluding instances within the Africa continent, and 4 to 6 unicast instances
geographically dispersed with at least 4 in Africa.
The DNS infrastructure will be outsourced to reputable industry service
providers demonstrating geographic diversity and the necessary expertise
for managing anycast services.
Unicast services will be managed both in-house, and optionally outsourced
on a similar basis to the anycast services.


4.4 Zone Server Status Information

Zone Server status information relating to the zone servers of the dotAfrica
TLD will be displayed on the Registrar portal and as detailed under Regis-
trar Notifications in section 6.1. This includes the following



Primary Nameserver Zone Timestamp:- - The timestamp will be dis-
 played in green should it be within expected limits according to the
 dotAfrica TLD policy, in orange if not, and a message in red indicating
 any critical error.

Secondary Nameserver Zone Timestamp:- - The timestamp for each
 secondary nameserver will be displayed in green should it be within
 expected limits according to the dotAfrica TLD policy, in orange if
 not, and a message in red indicating any critical error.


4.5 Registry Whois Services

This dissemination of contact and other information concerning domain
name registrations in the dotAfrica TLD will be determined by the policy
oversight committee of the dotAfrica TLD.
Whois Services offered by the ZA Central Registry for the dotAfrica TLD
will include at least the following

Port 43 Whois:- Service in accordance with RFC3912.

Web Based Whois:- Service.

Typical information will include the following

domain:- The domain string

registrant:- The name of the registrant

registrant address:- The postal address of the registrant

registrant contact number:- The phone⁄fax number of the registrant

registrar:- The name of the sponsoring registrar

registrar address:- The postal address of the registrar

registrar contact number:- The phone⁄fax number of the registrar

billing:- The name of the billing contact

billing address:- The postal address of the billing contact

billing contact number:- The phone⁄fax number of the billing contact

technical:- The name of the technical contact

technical address:- The postal address of the technical contact

technical contact number:- The phone⁄fax number of the technical con-
 tact

registration status:- Status information pertaining to the domain eg. reg-
 istration period, registration date, renewal date, last update, and do-
 main state where the state could be any of the following

 • Pending Update
 • Pending Delete
 • Pending Transfer
 • Inactive
 • Client⁄Server Hold

Name Servers:- The nameservers for the domain

Whois services will be subject to abuse prevention based on industry best
practises including, but not necessarily limited to, load balancing, rate lim-
iting and black listing addresses from where attacks placing undue load on
the registry whois infrastructure occurs.


4.6 Internationalised Domain Names

These will not be supported at the launch of dotAfrica TLD.
Any decision to implement IDNs during the life time of dotAfrica TLD will
be determined by industry best practises, ICANN recommendations and the
dotAfrica TLD Policy Oversight Committee.
Should such a decision be taken then the technical implementation for IDNs
will conform to the draft standards as set out in RFC 5890, RFC 5891, and
RFC 5892.


4.7 DNSSEC

The ZA Central Registry will provide full support for Domain Name System
Security Extensions (DNSSEC) for the dotAfrica TLD zone.
The ZA Central Registry complies with industry best practices for zone
signing and key protection, including security requirements as defined by the
dotAfrica Policy Oversight Committee, industry best practises and taking
international standards such as ISO27001 into account.




5 Registry Services by Agreement

This section provides details on services and products offered by the dotAfrica
TLD over and above the normal registration services as listed above. These
services and products are as per intended agreements with oversight bodies
and role players.
The following services are provisionally intended and will be ratified by
the dotAfrica Policy Oversight Committee prior to opening up registrations
including the sunrise and landrush periods.

Reserved List:- This list provides a service that will allow strings to be
 reserved to particular groups or entities as determined by the dotAfrica
 Foundation. This list may also include abusive names as determined
 by the Policy Oversight Committee.

Management Information System:- The MIS service provides stake-
 holders and oversight bodies such as the African Union and the dotAfrica
 Policy Oversight Committee with an interface to determine registry
 performance, uptime, registration statistics and other information re-
 lating to registry service level agreements.


6 Additional Registry Services

Additional registry services for the dotAfrica TLD include services provided
as business services provided to Registrars as required for their day to day
operations.


6.1 Additional Registrar Services

Services listed here are intended to facilitate Registrar interaction with the
Registry and are typically accessible via the Registrar portal as provided by
the ZA Central Registry.

Registrar Accreditation Process:- This service provides an automated
 step by step process for accrediting prospective Registrars including
 both legal and technical phases of the process.

Registrar Payment Gateway:- This service provides a secure authenti-
 cated interface for topping up Registrar domain registration funds.

Registrar Key Management:- This service provides a secure authenti-
 cated interface for inserting and updating the Registrar public keys as
 used to ensure secure communication using the Transport Layer Secu-
 rity (TLS) protocol over TCP with the dotAfrica EPP based domain
 registration service.

Registrar Issue Tracker:- This service provides an interface allowing ac-
 credited Registrars to log and track technical issues with the Registry.

Registrar Financial Information:- This service provides a secure au-
 thenticated interface allowing Registrars to obtain financial informa-
 tion pertinent to their domain provisioning transactions including in-
 voices, statements, and credit notes.

Registrar Management Information:- This service provides a secure
 authenticated interface allowing Registrars to obtain domain provi-
 sioning statistics and trends including comparative information allow-
 ing Registrars to see how they compare to others.

Registrar News Portal:- This service provides an interface where all Reg-
 istry news items relating to Registrars are published.

Registrar Notifications:- This service provides details on various Reg-
 istry news items including Registry infrastructural issues such as Reg-
 istry Maintenance Times, Whois Maintenance Times and Zone Server
 Status.

1 Synopsis

This chapter provides details on the technical and operational capabilities
of the ZA Central Registry, and as will be used for the dotAfrica TLD.
This covers the operational plans include system and human resourcing to
run the dotAfrica TLD according to the requirements of ICANN, the TLD
Registrars and industry best practices.
A high level architectural diagram and description of the services as provided
by the ZA Central Registry are included as well as the resourcing model for
operating the technical services for the dotAfrica TLD.


2 Shared Registry Ability

The ZA Central Registry has operated the co.za 2nd level domain registry
since September 1995. This registry has grown from around 400 domains
at startup to over 750000 domains and with an average growth of over
15000 domains per month over the past year. Currently the ZA Central
Registry is in further negotiations with the South African Domain Name
Authority (ZADNA) to take over administration of further 2nd level domains
including org.za which consists of around 40000 domains.
The ZA Central Registry has maintained service levels comparable to speci-
fication 10 of the ICANN registry agreement during the time of administrat-
ing co.za zone and will commit the necessary resources necessary to comply
fully. The ZA Central Registry anticipates no issues with compliance to
ICANN service level requirements.


3 High Level Shared Registry System Description

The ZA Central Registry system architecture ensures the necessary scala-
bility allowing for anticipated growth of the registry. The components illus-
trated in diagram DNS-ShareRegistry-Diagram.pdf provide an overview of
the ZA Central Registry Shared Registry System (SRS) as provided by the
ZA Central Registry and as intended for use by the dotAfrica TLD.
The SRS for the dotAfrica TLD will comply to and keep current with all
relevant IETF RFCs in accordance with specification 6 section 1.2 and spec-
ification 10 of the ICANN registry agreement. These include the following

RFC 5730:- Extensible Provisioning Protocol (EPP).

RFC 5731:- EPP Domain Name Mapping.

RFC 5732:- EPP Host Mapping.

RFC 5733:- EPP Contact Mapping.

RFC 5734:- EPP TCP Transport.

RFC 3735:- Guidelines for Extending the Extensible Provisioning Proto-
 col (EPP) should the dotAfrica TLD policy oversight committee im-
 plement policy that require extensions of the default EPP specification
 for domain, host, and contact objects.



4 Shared Registry Infrastructure

This section provides a high level description of the services, related in-
frastructure, human and system resources as provided by the ZA Central
Registry and as will be utilised and expanded on for the dotAfrica TLD.


4.1 Message Handler

The Message System Handler (MSH) provides a secure, authenticating EPP
messaging interface to accredited Registrars complying to IETF RFC 5734.
The functions of the MSH include access control, registrar authentication,
secure message handling between the registrars and the registry, registrar
session management, sophisticated message tracking and EPP XML Message
Schema validation in accordance with the EPP XML Schemas for domains,
hosts and contacts as defined in IETF RFCs 5731 to 5733.


4.1.1 MSH Human Resources

The MSH is a critical front facing component for an SRS as it the gateway
for all Registrar domain operations.
The ZA Central Registry has a complement of 3 MSH administrators and
developers responsible for the day to day operational requirements fulfilling
the roles described in section 7.


4.1.2 MSH System Resources

The ZA Central Registry MSH implementation for the dotAfrica TLD will
consist of 2 co-located servers hosted at the primary site with one acting as
master server and the other as a hot swap standby server.
A remote standby cluster of MSH servers will be located at the Johannesburg
Internet Exchange JINX.
The remote standby cluster will be configured as a replica of the local cluster.


4.2 Registry Engine

The ZA Central Registry Registry Engine (RE) provides the domain regis-
tration functionality of the dotAfrica TLD.
The RE operates on the domain, contact and host objects in accordance
with IETF RFCs 5730 to 5733 and the policies as required for the dotAfrica
TLD.
The RE returns responses for instructions received to the Registrars syn-
chronously or asynchronously either via the MSH and⁄or using other out of
band mechanisms such as e-mail. The RE provides sophisticated logging on
all domain registration instructions.
The RE ensures that all domain object financial transactions are posted to
the appropriate financial accounts.


4.2.1 Registry Engine Human Resources

The ZA Central Registry has a complement of 6 RE administrators, devel-
opers, testers and support staff responsible for the development and day to
day operational requirements fulfilling the roles described in section 7 of this
document.


4.2.2 Registry Engine System Resources

The ZA Central Registry Registry Engine implementation for the dotAfrica
TLD will consist of a cluster of 2 servers hosted at the primary site with one
acting as master server and the other as a hot swap standby server.
A remote standby cluster of Registry Engine servers will be located at the
Johannesburg Internet Exchange JINX.
The remote standby cluster will be configured as a replica of the local cluster.


4.3 Whois

The function of the Whois server provided by the ZA Central Registry is
to provide domain registration information to the public at large and in
accordance with the policies as dictated by applicable policies in accordance
with industry best practises and high availability requirements.
The Whois system provided by the ZA Central Registry, and as will be used
for the dotAfrica TLD, consists of the following

Web Whois:- A web based whois providing domain, host and registrar
 and registrant contact details for the dotAfrica TLD.

Port 43 Whois:- A port 43 whois service providing domain, host and reg-
 istrar and registrant contact details for the dotAfrica TLD.
4.3.1 Whois Human Resources

The ZA Central Registry has a complement of 4 Whois administrators, de-
velopers and testers responsible for the day to day operational requirements
fulfilling the roles described in section 7 of this document.


4.3.2 Whois System Resources

The ZA Central Registry Web Whois implementation for the dotAfrica TLD
will consist of a cluster of 2 servers hosted at the primary site with one acting
as master server and the other as a hot swop standby server.
The ZA Central Registry Port 43 Whois services for the dotAfrica TLD
will be co-hosted on a single server and will be implemented as a cluster of
2 servers hosted at the primary site with one acting as master server and
the other as a hot swap standby server.
A remote standby cluster of Whois servers will be located at the Johannes-
burg Internet Exchange JINX.
The remote standby cluster will be configured as a replica of the local cluster.


4.4 DNS System

The function of the Domain Name System, (DNS), is to provide the nec-
essary publishing of zone records. The DNS system provided by the ZA
Central Registry conforms to the relevant industry standards and is imple-
mented and maintained according to industry best practises, security and
high availability requirements.
The DNS system provided by the ZA Central Registry, and as will be utilised
for the dotAfrica TLD, consists of 8 Nameserver services placed over a strate-
gic geographical wide area. Two Nameservers will be configured as anycast
dns servers, with the rest configured as unicast dns servers.


4.4.1 DNS Human Resources

The ZA Central Registry has a complement of 3 in house DNS administrators
responsible for the day to day operational requirements and fulfilling the
roles described in section 7 of this document.


4.4.2 DNS System Resources

The ZA Central Registry master DNS implementation for the dotAfrica
TLD will consist of a server cluster hosted at the primary site.
A remote standby cluster of DNS servers will be located at the Johannesburg
Internet Exchange JINX.
The remote standby cluster will be configured as a replica of the local cluster.
At least 6 unicast servers will be located at geographical diverse locations.
In addition 2 anycast dns services providers will be contracted to provide
and maintain the geographically dispersed anycast instances.


4.5 Network Infrastructure

The network infrastructure and associated routing provided by the ZA Cen-
tral Registry conforms to the relevant industry standards and is implemented
and maintained according to industry best practises, security and high avail-
ability requirements.


4.5.1 Networking Human Resources

The ZA Central Registry has a complement of 3 inhouse network admin-
istrators responsible for the day to day operational requirements. fulfilling
the roles described in section 7 of this document.


4.5.2 Network System Resources

The dotAfrica TLD initial system network will be co-hosted on the network
of the ZA Central Registry.


4.6 Web Portal

The Web Portal provides the SRS with an interface to both the public and
the accredited registrars with the following functionality


4.6.1 Public

The web portal provides a gateway for the domain registration public to the
SRS. The functionality includes, but is not limited to, general TLD news,
domain registration policy detail pertinent to the dotAfrica TLD, and an
interface for reporting complaints and abuse related issues.
4.6.2 Accredited Registrars

The Registry portal provides accredited registrars with an authenticated
secure interface into the registry enabling management of information per-
tinent to the Registrar. This including facilities for financial management,
contact management and reporting of information relevant to the registrar
and a notice board providing registry status information to the Registrars.


4.6.3 Web Portal Human Resources

The ZA Central Registry has a complement of 3 inhouse Web Portal de-
velopers and administrators fulfilling the roles described in section 7 of this
document.


4.7 Management Information System

The Management Information System, (MIS), is responsible for providing
the required domain registry statistics, trends and usage as required by
oversight bodies including the dotAfrica TLD board and management, and
ICANN.
The MIS will also provide Registrars with necessary service level registry
information, and registration statistics within their mandate. The manage-
ment information system will initially be co-hosted on the hardware of the
Web Portal.


4.7.1 MIS Human Resources

The ZA Central Registry has a complement of 3 inhouse developers and
administrators responsible for the day to day operational requirements ful-
filling the roles described in section 7 of this document.


4.8 Financial System

The Financial System, (FS), provided by the ZA Central Registry is based
on OpenERP and provides the internal system for all financial and account-
ing responsibilities. This including Registrar invoicing, statements, and a
realtime balance checking facility.
4.8.1 FS Human Resources

The ZA Central Registry has a complement of 5 inhouse FS developers, ad-
ministrators and accounting clerks responsible for the day to day operational
requirements fulfilling the roles described in section 7 of this document.


4.9 Administration System

The Administration System provided by the ZA Central Registry provides
the internal operational system for registry administration requirements in-
cluding legal, administrative and technical functions. In addition to the
above the Administration System also provides the necessary infrastructure
to address the following

 * Uniform rapid suspension procedure requirements.

 * Post delegation dispute resolution policy requirements.


4.9.1 Administration System Human Resources

The ZA Central Registry has a complement of 3 inhouse developers and
administrators, 3 technical support staff, 2 legal clerks and 5 administration
clerks responsible for the day to day operational requirements fulfilling the
roles described in section 7 of this document.


4.10 Database

The Registry Database is the repository for various objects critical to the
operation of an SRS. These including domain, contact and host objects.
It is also the repository for all transactions on these objects, including all
financial and statistical records. The database is based on a clustered model
allowing full replication to standby backup infrastructure.


4.10.1 Database Technology

The ZA Central Registry will use PostgreSQL 9.1 for the dotAfrica TLD
implementation based on several reasons but mainly for the ability of scala-
bility and synchronous replication allowing flexible remote failover database
replication which is critical in a generic top level domain (gTLD) implemen-
tation with the potential to grow significantly and as will be used on a global
scale.
4.10.2 Database Human Resources

The ZA Central Registry Registry has been using the PostgreSQL database
in itʹs co.za registry administration operations for the past 12 years and
has built up considerable experience and expertise on this. PostgreSQL is a
powerful, open source object-relational database system.
The ZA Central Registry has a complement of 5 database administrators and
developers responsible for the day to day operational requirements around
the database fulfilling the roles described in section 7.


4.10.3 Database System Resources

The ZA Central Registry database implementation for the dotAfrica TLD
will consist of a cluster of 2 database servers hosted at the primary site
with any one of the 2 servers acting as the master and with the second
server acting as a hot standby server using synchronous replication on a
transaction by transaction basis.
A remote backup cluster of the database servers will be located at the Johan-
nesburg Internet Exchange JINX. These database servers will be configured
as backup standby servers with data replicated asynchronously from the
master database server.


5 Shared Registry Interconnectivity

The dotAfrica TLD will share the multi-homed internet connectivity as used
by the ZA Central Registry for the co.za zone and as illustrated in diagram
DNS-NetworkDiagram.pdf.


6 Shared Registry Synchronisation

The SRS for the dotAfrica TLD will be replicated to co-located standby
servers and the remote backup site co-located at the Johannesburg Internet
Exchange, JINX.
All dynamic data as contained in the database will be synchronously repli-
cated between the master system and co-located standby servers.
In addition all dynamic data as contained in the database will also be
asynchronously replicated between the master site and the remote backup
standby site.
All system software and system configuration will be asynchronously up-
dated to both the co-located standby servers and the remote backup standby
servers as and when changes occur on a schedule to be maintained by the
system administration department.


7 Shared Registry Resourcing

The dotAfrica TLD development, deployment and operational responsibili-
ties for the initial technical requirements will be staffed by members of the
ZA Central Registry during start-up phase. The ZA Central Registry has a
current complement as follows

Board of Directors:- 7

CEO:- 1

Financial Management:- 1

Management:- 3

Junior Management:- 4

Human Resources:- 1

Administration and Accounts:- 7

Technical Support:- 3

Housekeeping:- 2

Senior Development:- 3

Junior Development:- 3

System Administration:- 3

Registrar Liaison:- 1

Public Relations:- 1

African cctld Liaison:- 1
The roles being as follows

Development and Maintenance:- This responsibility covers the devel-
 opment and maintenance of the registry systems. This also includes
 keeping abreast with registry industry trends by participating in or-
 ganisations such as the IETF and ICANN.

Data Modeling:- This responsibility covers the development of data mod-
 els required for the current and ongoing database requirements of the
 business of the registry.

Documentation:- This responsibility covers the documentation require-
 ments.

System Testing:- This responsibility covers regression testing for all new
 releases, as well as providing Registrar documentation and notices re-
 garding any issues that may crop up from time to time.

System Administration:- This responsibility covers administration of the
 registry systems including system installation and configuration, Reg-
 istrar connectivity management, message management, security man-
 agement covering Registrar public key management, operating system
 installation and configuration, etc.

System Monitoring:- This responsibility covers monitoring of the soft-
 ware and hardware dedicated to the registry services including up-
 time, performance, security and abuse monitoring, and general net-
 work, hardware and operating system health. This responsibility also
 covers performance monitoring, reporting, statistics gathering, etc.

Network Administration:- This responsibility covers administration of
 the network services including installation, routing configuration, and
 maintaining the networking hardware.

Backups:- This responsibility covers all backup related activities include
 hot backups to standby servers and cold backups (tape), including
 management of off-site backups as well as backup recovery procedures.

Security:- This responsibility covers all registry security related respon-
 sibilities including data security, hardware security, system services
 security (software) and network security.

Once the dotAfrica TLD becomes operational the plan is to deploy dedicated
staff as follows
General Manager:- 1 person responsible for the day to day management
 including any legal responsibilities and keeping up to date with inter-
 national registry⁄registrar policy standards and best practises.

Financial Manager:- 1 staff member responsible for the financial system
 implementation and the day to day financial policies and procedures.

Registrar Liaison:- 1 person responsible for the day to day registrar re-
 lated issues, as well as for building the registrar base.

Public Relations:- 1 person.

Clerical Staff:- 4 staff members responsible for the administrative and
 support tasks.

Technical Manager:- 1 staff member responsible for all technical related
 issues including keeping up to date with international standards and
 best practises.

System Administration:- 2 staff members responsible for the day to day
 system administration, network administration and system monitor-
 ing.

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY
RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO
THIS QUESTION IS ATTACHED AS PDF FILES dotAfrica-q25.pdf AND dotAfrica-q25-rfc.pdf, ACCORDING TO SPECIFIC
GUIDANCE FROM ICANN UNDER CASE ID 11027.


1 Synopsis

This chapter provides details on the ZA Central Registry Shared Registry
System Extensible Provisioning Protocol EPP functionality as will be used
by the dotAfrica TLD.


2 Overview

The functionality of the ZA Central Registry Shared Registry System allows
registrars to interface using the EPP protocol and commands as defined in
the following RFCs and as referenced in this document:

RFC 3735:- Guidelines for Extending the EPP.

RFC 5730:- EPP Description.

RFC 5731:- EPP Domain Name Mapping.

RFC 5732:- EPP Host Mapping.

RFC 5733:- EPP Contact Mapping.

RFC 5734:- EPP TCP Transport.

RFC 5910:- EPP DNSSEC.

The ZA Central Registry Shared Registry System also conforms to the
above-mentioned RFCs.
The ZA Central Registry does not provide support for Domain Registry
Grace Period Mapping as per RFC 3915.
The ZA Central Registry will not be supporting International Domain Names
at startup.


3 Registrar Interface

The dotAfrica implementation listens for incoming TCP connection requests.
Once a client has issued an EPP 〈login〉 command on the listening port,
the server responds, creating the required session and sending back an EPP
〈greeting〉 to the client.
To end a session, a client may close the connection by issuing EPP 〈logout〉
command or an active close call.



The dotAfrica implementation automatically closes a session once the session
has idled for 24 hours.
A total of 2 concurrent sessions per client are allowed.
A Registrar can only establish a TCP connection to the server if they have
been technically accredited, provided the ZA Central Registry with their
public key and the public key has been successfully installed.
Exchanging of messages between client and server conforms to the require-
ments outlined in RFC 5734, and follows the general client-server message
exchange as outlined in Figure 1 of RFC 5734 Section 3.
Pipelining commands is possible. The server supports command pipelining
to a maximum limit of the connection buffer of 16384 bytes.
The dotAfrica implementation returns a message from the server to the
client for every command performed. If a message is lost due to connection
failure, the result code can only be retrieved if the client issues the same
command using the same client transaction identifier 〈clTRID〉 .
The dotAfrica implementation uses SSL⁄TLS as well as IP based Access
Control Lists. A session is started on login only if an SSL handshake is
established and the client IP Address is listed on the Access Control List.
Further security measures include authentication through use of usernames
and passwords. A session is terminated upon logout. A session is valid for
24 hours.
The dotAfrica handling and interpretation of the EPP Data Units conforms
to RFC 5734 Section 4, whereby the format of any EPP data unit will con-
tain the 32-bit header describing the total length of the data unit, and the
EPP XML Instance.
Length and calculation of data units conform with requirements outlined in
RFC 5734 .
Changes in the implementation can be made and will have to be decided by
the dotAfrica Policy Oversight Committee .


4 Extensible Provisioning Protocol (EPP)

This section describes the capability of the ZA Central Registry Shared
Registry System EPP and compliance with RFC 5730


4.1 Protocol Description

EPP is an XML based protocol used for provisioning domains and their asso-
ciated objects. The dotAfrica EPP implementation supports all commands
as defined in RFC 5730.


4.2 Protocol Commands

A command is any action performed on an object. Commands are grouped
into session, query and object transformation commands as follows in the
list below:

Protocol:-
 • login
 • logout
Query:-
 • Check
 • Info
 • Poll
 • Transfer
Transform:-
 • Create
 • Delete
 • Renew
 • Transfer
 • Update


4.3 EPP 〈login〉 Protocol Command

The dotAfrica implementation of the EPP 〈login〉 command conforms to
the requirements outlined in RFC 5730 Section 2.9.1.1.


4.4 EPP 〈logout〉 Protocol Command

The dotAfrica implementation of the EPP 〈logout〉 command conforms to
the requirements outlined in RFC 5730 Section 2.9.1.2 .


4.5 EPP 〈poll〉 Protocol Command

The dotAfrica implementation of the EPP 〈poll〉 command conforms to
the requirements outlined in RFC 5730 Section 2.9.2.3 .

4.6 Command Response

For each EPP command that is issued by the client to the server, a corre-
sponding response will be returned to the client by the server.
Every response will contain a result code. The result code indicates com-
mand success or failure. The dotAfrica implementation conforms to the
theory of result codes outlined in RFC 5321 Section 4.2.1 and uses a fourth
digit in its response codes.


5 EPP Domain Name Mapping

5.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its domain functionality. Any changes to
the EPP Domain Name Mapping command set will be determined by the
dotAfrica Policy Oversight Committee .


5.2 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


5.3 Object Attributes

Domain and Host Names:- Only domain names conforming to standard
 ASCII will be used. Internationalized Domain Names (IDN)s must be
 provided in A-Label format.

Contact and Client Identifiers:- Client and contact identifiers will be
 represented through a clID element to create an association with a
 domain object.

Status Values:- The dotAfrica implementation supports server and client
 status interaction outlined in RFC 5731.

Dates and Times:- All dates and times conform to RFC 5731 and are
 represented using UTC.

Validity Periods:- The dotAfrica implementation supports validity peri-
 ods in months and years, as well as a combination of both.

Authorisation Information:- The dotAfrica implementation supports do-
 main name object authorisation through use of passwords as defined
 in RFC 5731. Passwords are stored in one-way hash format.


5.4 EPP 〈check〉 Command

The dotAfrica implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5731 . The Domain 〈check〉 command
will be limited to 100 checks per command.


5.5 EPP 〈info〉 Command

The dotAfrica implementation of the EPP 〈info〉 command conforms to the
requirements outlined in RFC 5731 Section 3.1.2. The 〈info〉 command
response will be restricted based on the requester credentials. Expiry dates
and other information will not be presented to unauthorized sources.


5.6 EPP 〈transfer〉 Command

The dotAfrica implementation of the EPP 〈transfer〉 command conforms
to the requirements outlined in RFC 5731.
The dotAfrica implementation supports the following EPP 〈transfer〉 op-
erations which conform to RFC 5730 :

”query”:- Allows a client to identify the current status of a transfer request
 on a domain name object.

”request”:- Allows a client to request a transfer of a domain object from
 one sponsor to another.

”cancel”:- Allows a client to cancel their transfer request for a domain as
 long as the domain has not yet been transferred.

”approve”:- Allows the current domain sponsor to approve a transfer re-
 quest for the requested domain.

”reject”:- Allows the current domain sponsor the reject a transfer request
 for the requested domain.

The dotAfrica implementation incorporates an e-mail voting system whereby
a registrant is allowed to vote on the transfer of a domain. An EPP Poll
message will be queued for the current sponsor for transfer vote notification.

5.7 EPP 〈create〉 Command

The dotAfrica implementation of the EPP 〈create〉 command restricts the
use of the 〈period〉 element where the registry defines the registration pe-
riod of a domain object.


5.8 EPP 〈delete〉 Command

The dotAfrica implementation of the EPP 〈delete〉 command conforms to
the requirements outlined in RFC 5731 Section 3.2.2 . The dotAfrica imple-
mentation denotes that any domain that undergoes a 〈delete〉 command is
checked to conform to subordinate host dependencies outlined in RFC 5731
. A deletion request on a domain object will be prohibited if the subordi-
nate host objects are referenced by other domains belonging to the same
registrar.


5.9 EPP 〈renew〉 Command

The dotAfrica implementation of the EPP 〈renew〉 command restricts the
use of the 〈domain:period〉 element. The domain object can only be re-
newed to a maximum of one period.


5.10 EPP 〈update〉 Command

The dotAfrica implementation of the EPP 〈update〉 command conforms
to the requirements outlined in RFC 5731 . The dotAfrica implementation
utilises the 〈domain:contact〉 element to set ”tech”, ”billing”, ”admin”
contacts to domain name objects.


6 EPP Host Mapping

The following section provides details on how the ZA Central Registry
Shared Registry System maps its host functionality. The dotAfrica imple-
mentation restricts the host creation and usage to the individual registrar.
In other words each registrar controls and maintains their own set of hosts
even if the names are duplicated with other registrars. Subordinate host
glue publication is strictly controlled to prevent nameserver masquerading.

6.1 Relationship of Domain Objects and Host Objects

All created domain name objects require a minimum of 2 unique subordinate
or delegated host objects.


6.2 Object Attributes

Host Names:- Only host names conforming to standard ASCII will be
 used.

Status Values:- The dotAfrica implementation supports server and client
 status interaction outlined in RFC 5732.

Dates and Times:- All dates and times conform to RFC 5732 and are
 represented using UTC.

Glue:- The dotAfrica implementation supports IPv4 and IPv6 addresses,
 conforming to the requirements outlined in RFC 0791 and RFC 4291
 respectively.


6.3 EPP 〈check〉 Command

The dotAfrica implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5732 .


6.4 EPP 〈info〉 Command

The dotAfrica implementation of the EPP 〈info〉 command conforms to
the requirements outlined in RFC 5732 .


6.5 EPP 〈create〉 Command

The dotAfrica implementation of the EPP 〈create〉 command conforms
to the requirements outlined in RFC 5732. The use of the Host create
command might be restricted in lieu of the Domain Host handling during
Domain update and creation. The eventual Host create usage will be deter-
mined by the dotAfrica Policy Oversight Committee .


6.6 EPP 〈delete〉 Command

The dotAfrica Implementation of the EPP 〈delete〉 command conforms to
the requirements outlined in RFC 5732.

The dotAfrica implementation denotes that any host that undergoes a 〈delete〉
command is checked for dependencies outlined in RFC 5731 .


6.7 EPP 〈update〉 Command

The dotAfrica implementation of the EPP 〈update〉 command conforms to
the requirements outlined in RFC 5732.
The dotAfricaimplementation dictates that the changing of a host object
information is performed through the domain object mapping using the
domain 〈update〉 command.


7 EPP Contact Mapping

7.1 Overview

The following section provides details on how the ZA Central Registry
Shared Registry System maps its contact functionality.
Any changes to the EPP Contact Mapping command set will be determined
by the dotAfrica Policy Oversight Committee . In the dotAfrica implemen-
tation the Registrar objects are stored as standard EPP Contact objects,
thus allowing a registrar to adjust contact information such as passwords or
support addresses.


7.2 Object Attributes

Contact and Client Identifiers:- Client and contact identifiers will be
 represented through a clID element to create an association with a
 domain object.

Status Values:- The dotAfrica implementation supports server and client
 statuses outlined in RFC 5733. Status combination interactions con-
 form to RFC 5733 .

Internationalized Postal Info:- The dotAfrica implementation supports
 postal information represented as a subset of UTF-8 encoding in 7-bit
 ASCII. All required and optional elements for a contact object are
 supported by the dotAfrica implementation.

Localized Postal Info:- The dotAfrica implementation also supports postal
 information represented in UTF-8 encoding. All required and optional
 elements for a contact object are supported by the dotAfrica imple-
 mentation.

Telephone Numbers:- The dotAfrica implementation conforms to RFC 5733
 by ensuring that all telephone numbers begin with a plus (”+”) sign
 followed by a country code as defined in ITU.E164.2005, followed by a
 dot (”.”), followed by a sequence of digits representing the telephone
 number.

E-mail Addresses:- The dotAfrica implementation conforms to the re-
 quirements for e-mail addresses as defined in RFC 5322.

Dates and Times:- All dates and times conform to RFC 5733. The dotAfrica
 implementation supports time zone representation in UTC format.

Authorisation Information:- The dotAfrica implementation supports con-
 tact object authorisation through use of passwords, conforming to out-
 lined requirements in RFC 5733. Passwords are stored in one-way hash
 format.

Disclosure of Contact Elements and Attributes:- The dotAfrica im-
 plementation supports disclosure of contact attributes and conforms
 to RFC 5730, by announcing its data collection policies. The dotAfrica
 implementation supports the disclosure elements outlined in RFC 5733.


7.3 EPP 〈check〉 Command

The dotAfrica implementation of the EPP 〈check〉 command conforms to
the requirements outlined in RFC 5733 .


7.4 EPP 〈info〉 Command

The dotAfrica implementation of the EPP 〈info〉 command conforms to the
requirements outlined in RFC 5733. The disclosure of Contact information
will obey the disclose options as provided for the Contact object.


7.5 EPP 〈transfer〉 Command

The dotAfrica implementation of the EPP 〈transfer〉 query command con-
forms to the requirements outlined in RFC 5733.


7.6 EPP 〈create〉 Command

The dotAfrica implementation of the EPP 〈create〉 command conforms to
the requirements outlined in RFC 5733 .
The dotAfrica implementation supports the creation of a contact object with
both 〈contact:postalInfo〉 types of ”loc” and ”int”, conforming to the
requirements outlined in RFC 5733 Section 3.2.1 .


7.7 EPP 〈delete〉 Command

Implementation of the EPP 〈delete〉 command conforms to the require-
ments outlined in RFC 5733 Section 3.2.2.


Current policy states that a contact object cannot be deleted if in any way
it is associated with another object. If a contact object is still associated
with a domain object, the contact object is not deleted until the association
between contact and domain objects is removed.



7.8 EPP 〈update〉 Command

The dotAfrica implementation of the EPP 〈update〉 command conforms to
the requirements outlined in RFC 5733 .
The dotAfrica implementation supports the updating of a contact object
with both 〈contact:postalInfo〉 types of ”loc” and ”int”, conforming to
the requirements outlined in RFC 5733 Section 3.2.5 .



8 EPP Technical Plan

The Technical Layout will include the following:

 • On-site Scalable Master Server with the following configuration:

 Message Server:- The Message Server is responsible for handling
 session management, access control, user authentication EPP
 schema validation and Poll commands.
 Registry Engine:- The Registry Engine is responsible for all object
 level query and transform commands.
 Database:- The primary Registry Engine database.


 • Scalable Standby Co-located Server with the following configuration:

 Message Server:- A secondary Message Server used in the event
 that the Master Server fails.

 Registry Engine:- A secondary registry Engine used in the event
 that the Master Server fails.
 Standby Database:- A secondary database that is used in the event
 that the primary database on the Master Server fails.


 • Off-site Remote Standby Server with the following configuration:
 The Remote Off-Site Server configuration is a mirror of the
 Master site.

From the Technical Layout above, the EPP Technical Plan is as follows:
The initial startup of the EPP System involves starting the Master server
as well as a Standby server. The Standby server acts as a failover measure
in the event that the Master server fails.
EPP traffic is received via the External Network Bus, flows to the Mes-
sage Server. The Message Server handles all access control, SSL session
management, authentication and EPP schema validation in accordance to
RFC 5731 to 5733 and RFC 5910. The Registry Engine handles authenti-
cation of Registrars as well as processes all EPP commands in accordance
with RFC 5730.
The Standby Server acts as a failover server in event that the Master Server
fails. The Standby server is in a constant waiting state and is monitored
for availability in the event that is needs to be used. In the event that
the Master Server is overloaded, the Standby Server may be used for load
balancing.
The Remote Standby System is an off-site server that is a complete dupli-
cation of the Master Server and the Standby Server. In the event that the
Master Server and Standby Server fail, the Remote System will act as a
failover and perform exactly as the Master and Standby Servers.
The Remote Off-Site Server will be located at the Johannesburg Internet
Exchange (JINX). Both the primary site (hosting the Master Server and
Standby Co-Located Server) and the backup site (hosting the Remote Off-
Site Server) are highly redundant, state of the art data centers with multiple
power supplies, on-site backup facilities, and offer protection from natural
disasters.
Scalability for the EPP System covers hardware scalability related to system
utilization. Additional servers and required hardware will be added for
the Master Server as well as the Standby Co-Located Server as resource
utilization nears 50%. Any scalability changes made to the Master Server
and Secondary Co-Located server will also be duplicated to the Remote
Off-Site Server.

9 DNSSEC

The dotAfrica implementation supports the DNSSEC and conforms to RFC 5910.
The ZA Central Registry will be operating as a thick registry. A thick reg-
istry reflects on DNSSEC in the following way:

 Only DNSKEYS will be supported. The Registry will generate the corre-
 sponding DS record.

 The provided DS record is used for validation purposes only.

 Removal of DS records will not be supported on the client side.

 Removal of DNSKEYS will remove the associated DS record.

Any changes to the DNSSEC EPP Command Mapping will be determined
by the dotAfrica Policy Oversight Committee .


10 EPP Resourcing

The following section provides a high level description of the related in-
frastructure, human and system resources as provided by the ZA Central
Registry and as will be utilised and expanded on for the dotAfrica TLD.


10.1 SRS Human Resource

The ZA Central Registry has a compliment of 6 RE administrators, devel-
opers, testers and support staff responsible for the development and day to
day operational requirements including the following roles

System Testing:- Responsibility covers regression testing for all new re-
 leases, as well as providing Registrar documentation and notices re-
 garding any issues that may crop up from time to time.

System Administration:- Responsibility covers administration of the RE
 including installation, configuration, and operating system installation
 and configuration.

System Monitoring:- Responsibility covers monitoring of the hardware
 dedicated to the RE, RE uptime, RE performance, security and abuse
 monitoring, and general operating system health.

Backups:- Responsibility covers the backup requirements of the RE ma-
 chines including total system backup and log backups.

Development and Maintenance:- Responsibility covers the development
 and maintenance of the RE system including registry policy updates as
 may be required from time to time as registry policy changes dictate,
 SRS performance monitoring, reporting, statistics gathering, etc.


10.2 Registrar Technical Support

The ZA Central Registry uses its human resources to provide technical sup-
port to Registrars beyond the day to day operational requirements, includ-
ing:

Registry Online Portal:- Support covers the development and mainte-
 nance of the online Registry portal, updating EPP related frequently
 asked questions and the EPP Command wiki pages.

Registrar Technical Assistance:- The Registry portal incorporates an
 online contact mechanism where a Registrar can electronically ask
 a question and acquire technical support relating to their enquiry.
 Enquiries are tracked through a ticketing system, offering a platform
 for effectively monitoring and tracking Registrar enquiries.

Accreditation Support:- The ZA Central Registry offers online capabil-
 ity for Registrars to follow a policy aligned process for acquiring ac-
 creditation. The accreditation process is performed in 6 steps as listed
 below:

 1. Providing Registrar contact information
 2. Providing Company Registration Document
 3. Providing contact information for a primary contact
 4. Providing additional information including Registrar logo
 5. Reviewing status of integration with the EPP system
 6. Uploading of SLL Certificate and acquiring live system creden-
 tials
 Support relating to accreditation comes in the form of answering ac-
 creditation process related queries, assigning test account credentials
 to newly applied Registrars, monitoring accreditation progress and
 providing live account credentials for accredited Registrars.

Key Management Support covers the safe acquisition of SSL Certificates
 from accredited Registrars. Accredited Registrars can safely request
 to change their current in-use key.

Any alterations to or removal of proprietary extensions will be determined
by the dotAfrica Policy Oversight Committee .

11 Domain Extensions

The following section provides the domain name proprietary extensions im-
plemented by the ZA Central Registry for the dotAfrica TLD. All propri-
etary extensions conform to the requirements outlined in RFC 3735, and are
written in RFC format as below.

1 Abstract

This document describes an Extensible Provisioning Protocol (EPP) exten-
sion mapping for the provisioning and management of Domain Name exten-
sions for domain objects stored in a shared central repository. Specified in
XML, the mapping extends the EPP domain name mapping to provide ad-
ditional features required for the control of the DNServices Registry Domain
Objects.


Contents

1 Abstract 1

2 Introduction 2

3 Conventions Used in This Document 2

4 Object Attributes 2
 4.1 Auto Renew . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

5 EPP Command Mapping 3

6 EPP Query Commands 3
 6.1 EPP 〈check〉 Command . . . . . . . . . . . . . . . . . . . . . 3
 6.2 EPP 〈info〉 Command . . . . . . . . . . . . . . . . . . . . . 3
 6.3 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 4

7 EPP Transform Commands 4
 7.1 EPP 〈create〉 Command . . . . . . . . . . . . . . . . . . . . 4
 7.2 EPP 〈delete〉 Command . . . . . . . . . . . . . . . . . . . . 6
 7.3 EPP 〈renew〉 Command . . . . . . . . . . . . . . . . . . . . . 6
 7.4 EPP 〈transfer〉 Command . . . . . . . . . . . . . . . . . . . 6
 7.5 EPP 〈update〉 Command . . . . . . . . . . . . . . . . . . . . 6

8 Formal Syntax 9




 1
2 Introduction

This extension provides additional functionality to the Domain object as
described in RFC 5731. The additional functionality is listed below:

 1. Auto Renew

 2. Cancel Pending Action


3 Conventions Used in This Document

The key words ”MUST”, ”MUST NOT”, ”REQUIRED”, ”SHALL”, ”SHALL
NOT”, ”SHOULD”, ”SHOULD NOT”, ”RECOMMENDED”, ”MAY”, and
”OPTIONAL” in this document are to be interpreted as described in BCP
14, RFC 2119.
In examples, ”C:” represents lines sent by a protocol client, and ”S:” rep-
resents lines returned by a protocol server. ”⁄⁄⁄⁄” is used to note element
values that have been shortened to better fit page boundaries. Indentation
and white space in examples is provided only to illustrate element relation-
ships and is not a mandatory feature of this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications and ex-
amples provided in this document MUST be interpreted in the character
case presented in order to develop a conforming implementation.
gtldd is used as an abbreviation for http:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-
1-0.


4 Object Attributes

This extension adds an Auto Renew attribute to a domain name object.


4.1 Auto Renew

The auto renew flag is a boolean flag used to control the renew functionality
around a domain upon expiry. If the flag is set to TRUE then the domain
will be automatically renewed in the Registry assuming:

 1. There are sufficient funds

 2. There are subordinate host dependencies on the domain



 2
5 EPP Command Mapping

6 EPP Query Commands

6.1 EPP 〈check〉 Command

This extension does not add any elements to the EPP 〈check〉 command
or 〈check〉 response described in the EPP domain mapping RFC 5731.


6.2 EPP 〈info〉 Command

This extension does not add any elements to the EPP 〈info〉 command
described in the EPP domain mapping RFC 5731. However, additional ele-
ments are defined for the 〈info〉 response.
When an 〈info〉 command has been processed successfully, the EPP 〈resData〉
element MUST contain child elements as described in the EPP domain map-
ping RFC 5731. In addition, the EPP 〈extension〉 element MAY contain
a child 〈gtldd:infData〉 element that identifies the extension namespace
if the domain object has data associated with this extension and based on
server policy. The 〈gtldd:infData〉 element contains the following child
elements:

- An OPTIONAL 〈gtldd:autoenew〉 element that indicates the domain
 object preference for automatic renewal

Example 〈info〉 Response for Auto Renew:



S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1000ʺ〉
S: 〈epp:msg〉Domain Info Command completed successfully〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:resData〉
S: 〈domain:infData〉
S: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
S: 〈domain:roid〉DOM_2W-COZA〈⁄domain:roid〉
S: 〈domain:status s=ʺokʺ〉Domain Creation〈⁄domain:status〉
S: 〈domain:registrant〉testCont〈⁄domain:registrant〉
S: 〈domain:ns〉

 3
S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns1.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈domain:hostAttr〉
S: 〈domain:hostName〉ns2.otherdomain.gtld〈⁄domain:hostName〉
S: 〈⁄domain:hostAttr〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉testrar1〈⁄domain:clID〉
S: 〈domain:crID〉testrar1〈⁄domain:crID〉
S: 〈domain:crDate〉2011-02-23T14:43:12Z〈⁄domain:crDate〉
S: 〈domain:upID〉testrar1〈⁄domain:upID〉
S: 〈domain:upDate〉2011-02-23T14:46:18Z〈⁄domain:upDate〉
S: 〈domain:exDate〉2013-02-22T14:43:12Z〈⁄domain:exDate〉
S: 〈⁄domain:infData〉
S: 〈⁄epp:resData〉
S: 〈epp:extension〉
S: 〈gtldd:infData〉
S: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
S: 〈⁄gtldd:infData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984723857-97L2〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52FC3CEB-A80EF〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S:〈⁄epp:epp〉


6.3 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7 EPP Transform Commands

7.1 EPP 〈create〉 Command

This extension defines additional elements for the EPP 〈create〉 command
described in the EPP domain mapping RFC 5731. The additional auto re-
new elements are defined for the EPP 〈create〉 response as follows.
The EPP 〈create〉 command provides a transform operation that allows a
client to create a domain object. In addition to the EPP command elements



 4
described in the EPP domain mapping RFC 5731, the command MAY con-
tain an 〈extension〉 element, and the 〈extension〉 element MAY contain
a child 〈gtldd:create〉 element that identifies the extension namespace if
the client wants to associate data defined in this extension to the domain
object.
The 〈gtldd:create〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:autorenew〉 element that indicates a child’s
 preference to automatically renew this domain object upon expiration.

Example 〈create〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:create〉
C: 〈domain:create
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈domain:ns〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns1.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.57〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈domain:hostAttr〉
C: 〈domain:hostName〉ns2.exampledomain.gtld〈⁄domain:hostName〉
C: 〈domain:hostAddr ip=ʺv4ʺ〉160.124.24.58〈⁄domain:hostAddr〉
C: 〈⁄domain:hostAttr〉
C: 〈⁄domain:ns〉
C: 〈domain:registrant〉rant1〈⁄domain:registrant〉
C: 〈domain:authInfo〉
C: 〈domain:pw〉coza〈⁄domain:pw〉
C: 〈⁄domain:authInfo〉
C: 〈⁄domain:create〉
C: 〈⁄epp:create〉
C: 〈epp:extension〉
C: 〈gtldd:create〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:create〉

 5
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When a 〈create〉 command has been processed successfully, the EPP re-
sponse is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ’False’ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉


7.2 EPP 〈delete〉 Command

This extension does not add any elements to the EPP 〈delete〉 command
or 〈delete〉 response described in the EPP domain mapping RFC 5731.


7.3 EPP 〈renew〉 Command

Although this extension does not add any elements to the EPP 〈renew〉 com-
mand or 〈renew〉 response described in the EPP domain mapping RFC 5731
it does extend the Registry’s handling of the domain object upon expiry.


7.4 EPP 〈transfer〉 Command

This extension does not add any elements to the EPP 〈transfer〉 command
or 〈transfer〉 response described in the EPP domain mapping RFC 5731.


7.5 EPP 〈update〉 Command

This extension defines additional elements for the EPP 〈update〉 command
described in the EPP domain mapping RFC 5731. The additional elements
and attributes are defined for the EPP 〈update〉 response as follows.
The EPP 〈update〉 command provides a transform operation that allows a
client to modify the attributes of a domain object. In addition to the EPP
command elements described in the EPP domain mapping, the command
MAY contain an 〈extension〉 element, and the 〈extension〉 element MAY

 6
contain a child 〈gtldd:update〉 element that identifies the extension names-
pace if the client wants to update the domain object with data defined in
this extension. The 〈gtldd:update〉 element MAY contain a 〈gtldd:chg〉
element. The 〈gtldd:chg〉 element contains a 〈gtldd:autorenew〉 element
to adjust the automatic renewal status of a domain object.
The 〈gtldd:update〉 element also contains an OPTIONAL ”cancelPendin-
gAction” attribute that a client can use to ask the server operator to cancel
a predefined action as provided by the Registry software. This attribute ac-
cepts XML token values meaning standard text without leading or trailing
whitespace.
The 〈gtldd:update〉 element contains the following child elements:

- An OPTIONAL 〈gtldd:chg〉 element that contains a 〈gtldd:autorenew〉
 element that is used to adjust the auto renew flag on the domain ob-
 ject.

- An OPTIONAL cancelPendingAction attribute that contains the
 predefined action name as provided by the server.

Example 〈update〉 Command for autorenew false:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update〉
C: 〈gtldd:chg〉
C: 〈gtldd:autorenew〉false〈⁄gtldd:autorenew〉
C: 〈⁄gtldd:chg〉
C: 〈⁄gtldd:update〉
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉


 7
When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731 with the
extension element as follows:

S:〈epp:epp xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
S: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ〉
S: 〈epp:response〉
S: 〈epp:result code=ʺ1001ʺ〉
S: 〈epp:msg〉Domain action ’PendingUpdate’ pending〈⁄epp:msg〉
S: 〈⁄epp:result〉
S: 〈epp:extension〉
S: 〈gtldd:gtldData〉
S: 〈gtldd:detail result=ʺsuccessʺ〉
S: AutoRenew ’False’ successful
S: 〈⁄gtldd:detail〉
S: 〈⁄gtldd:gtldData〉
S: 〈⁄epp:extension〉
S: 〈epp:trID〉
S: 〈epp:clTRID〉CLTRID-12984717630-F490〈⁄epp:clTRID〉
S: 〈epp:svTRID〉DNS-EPP-12E52F2BC78-8AC51〈⁄epp:svTRID〉
S: 〈⁄epp:trID〉
S: 〈⁄epp:response〉
S: 〈⁄epp:epp〉

If a domain object enters a deletion process through expiry or command
then the action MAY be cancelled.
Example 〈update〉 Command for cancelling a pending action:

C:〈epp:epp xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
C: xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
C: xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ
C: xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
C: 〈epp:command〉
C: 〈epp:update〉
C: 〈domain:update
C: xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsdʺ〉
C: 〈domain:name〉exampledomain.gtld〈⁄domain:name〉
C: 〈⁄domain:update〉
C: 〈⁄epp:update〉
C: 〈epp:extension〉
C: 〈gtldd:update cancelPendingAction=ʺPendingDeletionʺ⁄〉

 8
C: 〈⁄epp:extension〉
C: 〈⁄epp:command〉
C:〈⁄epp:epp〉

When the 〈update〉 command has been processed successfully, the EPP
response is as described in the EPP domain mapping RFC 5731. However
the action that was specified MUST be cancelled and any status effects on
that domain object removed. If the action is not pending or does not exist
then an appropriate message is returned to the client.


8 Formal Syntax

An EPP object mapping is specified in XML Schema notation. The formal
syntax presented here is a complete schema representation of the object
mapping suitable for automated validation of EPP XML instances. The
BEGIN and END tags are not part of the schema; they are used to note the
beginning and ending of the schema for URI registration purposes.

BEGIN
〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
 xmlns:gtldd=ʺhttp:⁄⁄co.za⁄epp⁄extensions⁄gtlddomain-1-0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0 domain command extension ⁄⁄⁄⁄
 schema for gTLD required extensions 〈⁄documentation〉
 〈⁄annotation〉

 〈element name=ʺcreateʺ type=ʺgtldd:createTypeʺ⁄〉
 〈element name=ʺupdateʺ type=ʺgtldd:updateTypeʺ⁄〉
 〈element name=ʺinfDataʺ type=ʺgtldd:infoResponseTypeʺ⁄〉
 〈element name=ʺgtldDataʺ type=ʺgtldd:gtldDataTypeʺ⁄〉

 〈complexType name=ʺchgTypeʺ〉
 〈sequence〉
 〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉



 9
〈complexType name=ʺupdateTypeʺ〉
 〈sequence〉
 〈element name=ʺchgʺ type=ʺgtldd:chgTypeʺ minOccurs=ʺ0ʺ⁄〉
 〈⁄sequence〉
 〈attribute name=ʺcancelPendingActionʺ type=ʺstringʺ use=ʺoptionalʺ⁄〉
〈⁄complexType〉

〈complexType name=ʺcreateTypeʺ〉
 〈sequence〉
 〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺinfoResponseTypeʺ〉
 〈sequence〉
 〈element name=ʺautorenewʺ type=ʺgtldd:autoRenewTypeʺ minOccurs=ʺ0ʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉
〈complexType name=ʺgtldDataTypeʺ〉
 〈sequence〉
 〈element name=ʺdetailʺ〉
 〈complexType〉
 〈simpleContent〉
 〈extension base=ʺstringʺ〉
 〈attribute name=ʺresultʺ type=ʺgtldd:resultTypeʺ use=ʺrequiredʺ⁄〉
 〈⁄extension〉
 〈⁄simpleContent〉
 〈⁄complexType〉
 〈⁄element〉
 〈⁄sequence〉
〈⁄complexType〉

〈simpleType name=ʺresultTypeʺ〉
 〈restriction base=ʺNMTOKENʺ〉
 〈enumeration value=ʺsuccessʺ⁄〉
 〈enumeration value=ʺfailureʺ⁄〉
 〈⁄restriction〉
〈⁄simpleType〉

〈simpleType name=ʺautoRenewTypeʺ〉
 〈restriction base=ʺbooleanʺ〉
 〈⁄restriction〉
〈⁄simpleType〉
〈⁄schema〉
END

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY
RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO
THIS QUESTION IS ATTACHED AS PDF FILE dotAfrica-q26.pdf, ACCORDING TO SPECIFIC
GUIDANCE FROM ICANN UNDER CASE ID 11027.

1 System Description

The ZA Central Registry whois system supports both RFC 3912
port 43 whois and a web based system. The system is designed for high per-
formance and high availability by ensuring that the system is scalable, redun-
dant and geographically dispersed. Diagram DNS-DetailedWhoisVM.pdf
provides an overview of the dotAfrica TLD initial whois service implemen-
tation

1.1 Master Site Implementation

The hardware in use at the master site at startup phase will consist the
following servers:

 Port 43 whois servers

 HTTP based query servers

 Rate limiting servers

 Query cache servers

 Database servers

The master whois server cluster is replicated onto a co-hosted hot standby
server cluster with incoming queries across the primary server and the
standby server shared.
The system fully complies with the requirements of Specification 4 of the
Registry Agreement.


1.2 Redundant Site Implementation

At the startup phase there will be a single redundant site with an identical
server configuration to the primary site. Queries between the redundant site
and the primary site are shared by means of an anycast address setup.
Additional geographically dispersed redundant sites will be added as whois
query volume demand grows.

2 Synchronisation

Both the port 43 and the Web based whois services are considered critical
infrastructure.
The whois system is replicated synchronously to the onsite standby system
and is up to date to the point of the last transaction.
The whois system is replicated asynchronously to a remote standby site.
Changes are replicated continuously and are well within the limits allowed
by specification 10 of the registry agreement.
Geographical fail-over between the sites is achieved using any-cast IP ad-
dresses such that if one site becomes unreachable whois queries will continue
un-effected.


3 Data Object Specifications

Objects returned by the whois system comply with specification 4 of the
registry agreement. All data returned is in plain text format in key-value
pairs. Additional formats may be provided at a later date as requested by
the community or specified by ICANN.
Sample data returned by the port 43 service for the domain example.africa

Domain Name: example.africa
Domain ID: DOM_1S2XW-AFRICA
WHOIS Server: whois.AFRICA
Referral URL: http:⁄⁄www.africa⁄
Updated Date: 2012-01-22T19:36:00Z
Creation Date: 2012-01-22T19:36:00Z
Registry Expiry Date: 2013-01-22T19:36:00Z
Sponsoring Registrar: EXAMPLE AFRICA REGISTRAR
Sponsoring Registrar IANA ID: 0000
Domain Status: clientTransferProhibited
Registrant ID: coza1buye1494cc2
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State⁄Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State⁄Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State⁄Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Billing ID: EXAMPLE12345
Billing Name: ACCOUNTS 
Billing Organization: EXAMPLE ACCOUNTS
Billing Address: 22 EXAMPLE STREET
Billing City: SOME CITY
Billing State⁄Province:CA
Billing Country⁄Economy:US
Billing Postal Code: 1234
Billing Phone: +1.234567890
Billing FAX: +1.234567890
Billing FAX Ext.:
Billing E-mail: billing@example.com

Name Server: NS01.AFRICARAR.AFRICA
Name Server: NS01.AFRICARAR.AFRICA
=-=-=-=
This WHOIS information is provided for free by the ZA central registry
for .za domain names. This information and the .za WHOIS are:

 Copyright ZA Central Registry 2012.

This port 43 whois facility is made available ʺas is,ʺ and we do not
guarantee its accuracy or uninterrupted availability. By submitting a
port 43 whois query, you agree that you will not use this facility to
enable high volume, automated, electronic processes that unduly stress or
load the whois database system. The commercial compilation, repackaging,
dissemination or other use of the data you obtain from this  facility
is expressly prohibited without prior written consent from us.

We reserve the right to modify these terms at any time. By submitting
this query, you agree to abide by these terms.

4 Lookups

4.1 Search Capabilities

The RFC 3912 system only allows domain name lookups. The web based
whois tool is a full feature system. Two types of users are catered for:

 Unauthenticated users. I.e the average anonymous Internet user.

RFC 5731:- Authenticated Registrars or nominated authenticated users.


4.1.1 Unauthenticated Users

The user may search for domain names only. Information returned is iden-
tical to as returned by the port 43 whois system other than being formatted
for web browsers. Information is returned when the query exactly matches
the domain.
The user may use wild card queries. Eg: examp*.africa. In this case a
list of the matching domains are returned. The user may then click on the
domain to view its details. To prevent data-mining abuse only a subset of
the matches are returned.


4.1.2 Authenticated Users

Authenticated users have access to a full featured system offering partial
match capabilities on at least the following fields:

 1. Domain name

 2. Registrantʹs name

 3. All sub-fields described in EPP (e.g., street, city, state or province,
 contact numbers etc.)

 4. Registrant and or billing, registrar or other contact ids,

Exact match search will be offered on the following:

 1. Registrar id

 2. EPP host objects (server names).

 3. Glue records (IP addresses)

The system will allow for Boolean combinations of fields using the standard
AND, OR and NOT operators.
Returned results will always include the domain names as per the specifica-
tion. Objects owned by the authenticated user (e.g a registrar querying a
list of their owned domains) will be fully displayed while objects owned by
other registrars will honour any 〈contact:disclose〉 settings.
The level of information displayed for non owned objects will be adjusted
from time to time as per industry and ICANN recommended best practice
as determined by the dotAfrica Policy Oversight Committee


4.2 Abuse Prevention

Unauthenticated users are controlled by a rate limiting system to prevent
wholesale mining of the whois database.
Authenticated users will also be limited but to a much lesser degree. All
matching objects owned by the requester will be returned in a search. A
limited subset of matching objects will be returned when the objects are
NOT owned by the requester.
Two aspects of abuse prevention are covered by the rate limiting system.

IP Address:- - Abuse originating from a single IP address or range of IP
 addresses will be limited by a Token Bucket algorithm separate to
 other mechanisms but having the highest priority.
Domain Name:- - Abuse on a single domain name will have an isolated
 limitation based on the algorithm above to prevent multiple sources
 querying the same name. This prevents denial of service issues when
 a domain name is due for deletion and multiple source continuously
 query the domain to check for availability.

If a user exceeds the limits imposed by the token bucket system on the web
based whois system the user is then required to enter a CAPTCHA test to
continue using the system.
dotAfrica undertakes to add additional measures if it becomes apparent that
large amounts of information are being retrieved by any single entity.


5 RFC 3912 Compliance

The implementation conforms with the requirements of RFC 3912 (WHOIS
Protocol Specification)
A whois query to the system connects to TCP port 43 on the public WHOIS
server. A single domain name is sent with the line terminated by a carriage
return and a new line. The server responds with the result of the whois
query in plain ASCII.
Since RFC 3912 does not specify any details for internationalisation, the
whois service of the dotAfrica TLD will provide ASCII character set data.
This implies that where EPP contact addresses exist of both local and in-
ternational types, the International version will be returned.
RFC 5733 disclosure settings are honoured when returning information.
For example

〈contact:disclose flag=ʺ0ʺ〉
 〈contact:email⁄〉
 〈contact:voice⁄〉
〈⁄contact:disclose〉

will prevent the registrantʹs email or contact number from being displayed
in the whois query.

6 Resourcing Requirements

The dotAfrica TLD development, deployment and operational responsibil-
ities for the above will be staffed by members of the ZA Central Registry
during start-up phase. Once the dotAfrica TLD becomes operational ded-
icated staff will initially be deployed to manage both the RFC 3912 whois
and the web based whois as follows

Technical Manager:- - 1 staff member responsible for all technical related
 issues including keeping up to date with international standards and
 best practises.

System Administration:- - 2 staff members responsible for the day to
 day system administration and system monitoring.


7 Bulk Access

Bulk access here is defined as a full copy of the whois database.
Bulk access of objects in the Whois service will only be provided to ICANN
or their appointed agents in accordance with the specifications 4 and 10 of
the ICANN Registry Agreement.

1 Synopsis

This chapter provides details on the proposed lifecycle of domains regis-
tered in the proposed gTLD. Included in the details is an elaboration on
the various states, pending action periods and the registration periods of a
domain.


2 Registration Life Cycle

2.1 Introductory Life Cycle

The diagram DNS-DomainLifecycle-SRLR.pdf details the introductory do-
main life cycle with Sunrise and Landrush periods. Domains registered
during the Sunrise and Landrush periods will be registered for a period of
5 years.


2.1.1 Sunrise

On introduction of dotAfrica there will be a Sunrise period as defined be-
low. Applications for Trademark names will be accepted during the Sunrise
period. The Sunrise phase will be administered by an external provider as
decided by the dotAfrica Policy Oversight Committee
The Sunrise period will be broken up into 3 phases as described in dia-
gram DNS-DomainLifecycle-Sunrise.pdf.

 1. Pre-Sunrise - Name collection for reservation and blocking starting
 from June 2012 and reserved names being held for a period of 24 months
 while blocked names will be held indefinitely.

 2. Sunrise Phase 1 - The initial Sunrise period for African Registered
 Trademark holders running a period estimated at 2 weeks + 4 weeks,
 and to be ratified by the dotAfrica policy oversight committee with
 the latter period being used for examination and verification.

 3. Sunrise Phase 2 - The secondary Sunrise period for International Reg-
 istered Trademark holders running for a period estimated at 2 weeks +
 4 weeks, and to be ratified by the dotAfrica policy oversight committee
 with the latter period being used for examination and verification.

Application names will be reserved during the above periods until resolution
occurs. Should an application be rejected or withdrawn the reserved names
will be auctioned as part of the Landrush process.


2.1.2 Landrush

A Landrush period of estimated at 14 days, and to be ratified by the
dotAfrica policy oversight committee will be enforced on the introduction
of dotAfrica.


2.2 Operating Life Cycle

The diagram DNS-DomainLifecycle-LR.pdf details the Domain Operating
Life Cycle.

Available:- The domain is available for creation and will not appear on
 the registry whois or EPP info query. The name might appear on a
 Sunrise⁄Landrush whois like interface.

Landrush:- The domain application has been submitted and is pending
 creation. Multiple creates will be accepted for the same domain during
 this period with any conflicts resulting in an auction period of 0 to 14
 days.

Grace Period:- Once the domain has been created it will be in a state of
 grace lasting estimated at 10 days, and to be ratified by the dotAfrica
 policy oversight committee. The domain can be released and return
 to the available state should the registrant of the domain choose. The
 result will be a partial refund and a tasting fee as to be determined
 by the dotAfrica TLD policy oversight committee.

Registered:- The domain is now registered and in operation until a further
 change in state by one of the following operations:

 1. Domain Renew
 2. Domain Update
 3. Domain Expiry
 4. Domain Deletion
 5. Domain Transfer

Expired:- A rollover of the domain expiry date will result in one of 2 ac-
 tions:

 Auto Renew:- If the auto renew attribute has been set on the do-
 main and sufficient funds exist in the sponsor account then the
 domain will be renewed and move to the registered state for an-
 other period.
 Suspension:- If the auto renew attribute has not been set or the
 sponsor has insufficient funds then the domain will enter the
 pending suspension state for eventual release.

Pending Suspension:- The domain may enter a state of pending suspen-
 sion for estimated at 15 days, and to be ratified by the dotAfrica policy
 oversight committee should it be deleted or expire. The domain will
 still be published to the zone. The pending suspension state may be
 cancelled at any time which may result in re-instatement should there
 be sufficient funds (if the pending suspension was due to an expiry).

Pending Deletion:- Once the period for pending suspension lapses so the
 domain will enter a state of pending deletion for estimated at 5 days,
 and to be ratified by the dotAfrica policy oversight committee. The
 domain will no longer be published to the zone but will still appear
 on whois and EPP info queries. The pending deletion state may be
 cancelled at any time which may result in re-instatement should there
 be sufficient funds (if the pending deletion was due to an expiry).

Released:- The domain will enter the available state in the eventual case of
 a domain being deleted which will then be available for re-registration.


3 Domain Life Cycle State Definition

The domain object status will be adjusted to any of the following states
during its registration life cycle. The Domain Status interaction as defined
in RFC 5731 will apply.
The diagram DNS-DomainLifecycle-Registration.pdf details the Domain Reg-
istration Life Cycle.


3.1 Pending Create

A pendingCreate status with an appropriate message will be applied upon
receipt of a domain create command. During the state, the domain may be
pending Sunrise legal resolution or Landrush auction. The domain object
will be held by an escrow registrar as ordained by dotAfrica. The domain
object will be transferred to the winning applicant upon expiration of the
Sunrise or Landrush period defined below.


3.1.1 Sunrise

A Sunrise period estimated at 2 weeks + 4 weeks, and to be ratified by the
dotAfrica policy oversight committee will begin on the launch of dotAfrica.
The domain object will be held and advertised as being in Sunrise phase.
Applications will be collected then accepted or rejected.


3.1.2 Landrush

The Landrush state will comprise of three phases:

Introduction:- A Landrush period estimated at 14 days, and to be ratified
 by the dotAfrica policy oversight committee will apply. Domain names
 will be offered at a premium fee which will be reduced at selected
 intervals until the next Landrush phase begins.

Initiation:- Thereafter a secondary Landrush period estimated at 14 days,
 and to be ratified by the dotAfrica policy oversight committee will
 apply. During the Landrush phase a domain in contention; which is a
 domain that is requested by multiple parties over the period; will enter
 an auctionary period. The auction will be maintained and monitored
 by an external provider as defined by the dotAfrica Policy Oversight
 Committee .

Operation:- During standard operation a period of 0 to 14 days will apply.
 The period will increase based on the amount of applications received
 for a domain name to a maximum period. Should more than one
 application be received for a single domain name then the applicants,
 or further applicants, shall enter a private auction to determine the
 ultimate owner of the name. The private auction is specific to recently
 released domain names where an out-of-band notification mechanism
 is utilized.

3.2 OK

The domain state of OK will apply until further commands are issued re-
sulting in a change of state.


3.3 Pending Update

Domain update commands will be processed asynchronously resulting in
an EPP Result Code of 1001. The Update period may vary depending on
the extent of the update command and the domain update policy as to be
determined by the dotAfrica TLD policy oversight committee.


3.4 Pending Transfer

A Registrar transfer may be initiated during the registration period. The
transfer will result in a period varying 0 to 5 days depending on the creden-
tials supplied with the transfer command.


3.5 Pending Delete

The pending delete state will apply for the periods of two of the phases in
the domain life cycle as detailed below.

Pending Suspension:- A pending suspension period of estimated at 15 days,
 and to be ratified by the dotAfrica policy oversight committee during
 which the domain will remain in the dotAfrica zone.

Pending Deletion:- A pending deletion period of estimated at 5 days,
 and to be ratified by the dotAfrica policy oversight committee during
 which the domain will be removed from the dotAfrica zone.


3.6 Inactive

The domain state of Inactive will apply for the Pending Deletion period of
estimated at 5 days, and to be ratified by the dotAfrica policy oversight
committee. The state flags the domain for removal from the zone.


3.7 Hold States

The hold states of clientHold and serverHold will remove the domain from
the dotAfrica zone and may apply indefinitely.


3.8 Locking States

The following client locking states may be applied indefinitely on a domain
object

 1. clientUpdateProhibited

 2. clientRenewProhibited

 3. clientTransferProhibited - Any domain transfer requests sent while the
 state is in effect will require authentication credentials.

 4. clientDeleteProhibited

The following server locking states may be applied indefinitely on a domain
object

 1. serverUpdateProhibited - State will apply during Sunrise and Lan-
 drush periods as well as during any Universal Dispute Resolution Pro-
 cess, (UDRP).

 2. serverRenewProhibited

 3. serverTransferProhibited - State will apply during Sunrise and Lan-
 drush periods as well as during UDRP.

 4. serverDeleteProhibited - State will apply during Sunrise and Landrush
 periods as well as duringUDRP.


4 Resource Planning

4.1 Personnel Roles

Period and State roles are held by persons that have a role in affecting the
dotAfrica’s Policies and Procedures.
The policy roles are:

 1. Policy Administrator, PA

 2. Legal Advisor, LA

 3. Technical Advisor, TA

4.1.1 Number of persons required per task

At any given time, there must be at least 2 individuals within the organiza-
tion per policy role indicated in 4.1.


4.1.2 Identification and authentication for each role

Only people who have signed a confidentiality agreement and an agreement
to acknowledge their responsibilities with the Registry may hold a policy
role.


4.1.3 Tasks requiring separation of duties

The policy roles in 4.1 above to a maximum of two may be held simulta-
neously by one and the same person. In other words, the PA and TA role
might be held by one person, while the LA role may be held by another.
There must always be a minimum of two personnel present during policy
administration.


4.2 Policy Management

The Registry for dotAfrica includes software for maintaining and controlling
dotAfrica policy. The policy roles in 4.1 must have access to the software
and understand how the policy is implemented by the Registry.

1 Synopsis

This chapter provides details on the Abuse Prevention and Mitigation
procedures as provided by the ZA Central Registry as currently in use for the
co.za 2nd level domain, and as intended for use in the dotAfrica TLD on
ratification by the dotAfrica TLD policy committee and in accordance with
industry best practises and the ICANN Registrar and Registry Accreditation Agreement policies.


2 Abuse Policies and Procedures

2.1 Implementation Plan: Abuse Point of Contact

The ZA Central Registry is committed to protecting consumers, registrars
and the greater internet community against fraudulent, deceptive and unfair
business practices and to provide online advisory assistance to eliminate or at
the very least minimize such practices within the dotAfrica TLD name space
immediately after delegation. The ZA Central Registry, in consultation
with the dotAfrica Policy Oversight Committee , intends investigating and
implementing the following strategy to ensure that the above objectives are
achieved:

 1. Setting up a dedicated online complaints portal with access to email,
 telephone and fax contact details ;

 2. Appointing a dedicated Complaints Officer who will attend to complaints
 or channel them to the relevant divisions within the registry to
 expedite resolution thereof;

 3. Creating policies that will clearly set out inter alia: the scope and
 ambit of complaints that will be dealt with; the process that will be
 followed to deal with domain related complaints; the course of action
 that will be available to the registry to deal with complaints depending
 on their nature.


2.2 Domain Complaints Policy

Policies handling complaints pertaining to the dotAfrica domain name will
be drafted and approved by the dotAfrica Policy Oversight Committee .
What follows is a brief outline of some of the aspects that must be included
as part of the policy framework and content
2.2.1 Background

This document sets out the ZA Central Registry policy on handling complaints
relating to registrants, accredited registrars and resellers in the dotAfrica
TLD domain name space.


2.2.2 Definitions Clause

In this part of the policy it would be imperative to define terms such
as complaints (a party who has lodged a complaint regarding a dotAfrica domain
name or a service provided by an accredited registrar or reseller), domain
complainant ( make it subject to the clause that defines what complaints
will be covered within the scope of the policy); industry complaints (make
it subject to clause that describes what complaints are covered within the
parameters of this policy), respondent (person who lodges a complaint with
the ZA Central Registry).


2.2.3 Jurisdiction to handle domain name complaints

This clause should define the ability of the ZA Central Registry to handle
complaints that fall exclusively within the dotAfrica domain name space and
list those complaints which the ZA Central Registry will not be competent
to handle such as domain complaints relating to generic Top Level Domains
or other country code Top Level Domains; web-hosting, web-management
or web-design services which generally fall within the contractual sphere;
internet access or email services which again falls outside the registry func-
tion; offensive or objectionable website content. Reference should also be
made to relevant policies that may be developed and which may contain
their own internal authority or institution mandated to deal with breaches
thereof. Referrals to these institutions must be possible and perhaps a link
should be provided to the appropriate authority or institution.


2.2.4 Complaints Management Process

This clause should give details of how complaints should be communicated
to the Complaints Officer, i.e. whether by fax, email or post; whether the re-
spondent will be given an opportunity to respond to the complaint; stipulate
the time frames (specific or within a reasonable period of time) within which
the complaint will be resolved; and how the complainant will be notified of
the outcome of the investigations conducted regarding the complaint.

2.2.5 What constitutes domain complaints⁄industry domain com-
 plaints?

This clause should set out the type of complaints that will be addressed
by the Complaints Officer. For example, domain complaints may include
but not be limited to: cybersquatting, spam, phishing, ownership of domain
names, transfer of domain names from one registrant to another, breach of
any dotAfrica published policies; mismanagement of the dotAfrica domain
name space by an accredited registrar or domain name reseller, breaches
of the registrar agreement or any Codes of Conduct that may exist. Com-
plaints that fall outside the competence of the Complaints Officer must also
be specifically mentioned. For example, that the Complaints Officer would
not entertain complaints that relate to competing rights in a domain name
or any commercial disputes between registrars and resellers and⁄or regis-
trars⁄resellers and registrants. The dotAfrica Policy Oversight Committee
would have to decide how broad or narrow this component should be.


2.2.6 Kinds of decisions⁄actions that can be taken

This will depend on the nature of the complaint that is lodged and will
have to be streamlined by the Policy Oversight Committee. Sample of de-
cisions⁄actions could be:

 1. In the case of a registrar or reseller being in breach of the registrar
 accreditation agreement or any published policy, the action could be
 to notify the registrar or reseller of the breach and to give them an
 opportunity (time-based) to remedy the breach or risk more stringent
 action being taken, such as, to deny or cancel the registration, renewal
 or transfer of any .africa domain names, or to place any .africa domain
 name on registry lock, hold or similar status;
 2. In the case of an unauthorized⁄unlawful transfer, it could be a reversal
 of that transfer;
 3. Request the registrar⁄reseller to submit a full explanation of what
 transpired and tender an apology for any abusive practice that has
 negatively affected the complainant.


3 Whois Accuracy

3.1 Ad-hoc Validation Process

Currently, authentication of registrar⁄registrant data on the Whois database
is governed in two ways. Firstly, the ZA Central Registry registrar accredi-
tation agreement contains a number of provisions that places an obligation
on the registrars to ensure that the data uploaded on the registry system is
correct and updated on a periodic basis, failing which, accreditation status
may be lost. The registrar accreditation agreement also places an obligation
on the registrar to enter into contracts, which incorporate the key principles
enunciated in the accreditation agreement as well as any additional legal re-
quirements, with their registrants. This places a reciprocal duty on both the
registrar and registrant community to ensure that at the very least, infor-
mation maintained on the whois database is accurate, complete and current.

Secondly, the ZA Central Registry has a process (clause 7.3 in terms of the
registration agreement, and a subsequent form 15 manual takedown process)
in place to ensure that domain related data submitted to the registry is ac-
curate and complete. The ZA Central Registry conducts ad hoc surveys or
scrutiny of its Whois that shows that material information is missing on the
Whois database and⁄or may also receive complaints from third parties that
critical information on a particular domain is missing or inaccurate. The
clause 7.3 process is activated to handle abusive practices of this nature.
This process entails giving the registrar⁄registrant formal written notice by
email⁄fax⁄postage to its billing⁄admin⁄tech contact to update the Whois
database within 14 to 21 days, failing which the domain will be deleted.
Upon expiry of this a Whois look-up is conducted and if the domain contact
details have not been updated then the registrar⁄registrant is given a final
24 hour period to attend to our update request. If the Registrant contact
details are not updated within the initial and extended periods then a take
down request in terms of form 15 is formally processed and the domain is
subsequently deleted. This process is properly documented and all efforts
are made to ensure that the registrar⁄registrant receives proper notifica-
tion and a reasonable opportunity to ensure that the domain details are
complete and accurate. Within the dotAfrica gTLD context the dotAfrica
Policy Oversight Committee will need to endorse this process or adapt it
for implementation in the dotAfrica gTLD space.


4 Registrar Requirements

Notwithstanding the ICANN Registrar Agreement for accredited registrars
the proposed registrar accreditation agreement for the dotAfrica TLD will
include the following measures to ensure compliance to address abuse pre-
vention, abusive behavior and address service levels for law enforcement
requests.

COMMENCEMENT AND DURATION
 a Duration
 b Registrar may Terminate

REGISTRAR ACCREDITATION


 a Requirement for Accreditation
 b Registrar Service
 c Non-Exclusivity
 d Continuous Disclosure

LOSS OF REGISTRARʹS ACCREDITATION


 a Loss of Accreditation
 b Consequences of Loss of Accreditation

WARRANTIES


 a Information Provided to the Registry
 b The Registryʹs Reliance

USE OF THE REGISTRY NAME AND LOGO


 a Grant of Licence
 b Other Use not Permitted

GENERAL OBLIGATIONS OF REGISTRAR


 a Registrar Services
 b Compliance with Published Policies
 c Notification of changes to Published Policies
 d Compliance with Code of Practice
 e Inconsistencies
 f No Limitation

PAYMENT OF FEES


 a Assessment Fee:
 b Accreditation Fees:
 c Annual Fee:
 d Transaction Fees:
 e Insurance:
 f Value Added Tax (VAT):
 g Timely Payment:
 h Interest on Late Payment:
 i No Set-Off:

APPLICATION FOR A DOMAIN NAME


 a Consideration by Registrar
 b Compliance with Published Policies
 c Final Check by the Registry
 d Approved Domain Name Applications
 e Rejected Domain Name Applications
 f Notice of Registration

REGISTRANT AGREEMENTS


 a Registrant Agreement
 b The Registryʹs Requirements
 c No Inconsistent Terms
 d Make Information Available to the Registrant
 e Registrarʹs Agency:

REGISTRANT DATA


 a Submit to the Registry Operator
 b Updated Registrant Data
 c Access to Registrant Data
 d Information to be Publicly Available

TRANSFER BETWEEN REGISTRARS


 a Transfers
 b Acknowledgement

NON-SOLICITATION OF REGISTRANTS


 a Use of WHOIS Service Information
 b No Application

REGISTRARʹS OTHER OBLIGATIONS


 a Positive Covenants
 b Negative Covenants
 c Insurance
 d Enquiries and Complaints

CONTROL OF RESELLERS


 a Appointment of Resellers
 b Responsibility of the Registrar
 c Reseller Agreement

PRIVACY


INTELLECTUAL PROPERTY RIGHTS


 a Registrant Data:

OBLIGATIONS OF THE REGISTRY


 a General obligations

CONFIDENTIALITY


 a Delivery or Destruction of Confidential Information

LIMITATIONS OF LIABILITY


 a Disclaimer
 b Effect of Legislation
 c Exclusion of Implied Warranties
 d General Exclusion of Liability
 e Specific Performance
 f Limitation of Liability
 g Aggregate Liability
 h Consequential Losses

DISPUTE RESOLUTION


DEFAULT AND TERMINATION


 a Consequences of Default:

CONSEQUENCES OF TERMINATION


 a Rights and Obligations on Termination:
 b Survival:
 c Forced Transfer:

PROHIBITION OF ASSIGNMENT


 a No Assignment:
 b No Change of Control:
 c Fees and Expenses:
 d Details:

GENERAL


 a Entire Agreement and Variations:
 b Further Assurance:
 c Legal Costs and Expenses:
 d Waiver and Exercise of Rights:
 e Time of the Essence:
 f Non-Solicitation:

NOTICES


 a Service of Notice:

INTERPRETATION

 a Governing Law and Jurisdiction:
 b Persons
 c Joint and Several:
 d Legislation:
 e Severance:
 f Rule of Construction:
 g Force Majeure
 h Currency:
 i Business Day:
 j Number and Gender:


5 Domain Operation Control Policies

The domain operation control policies will include adequate controls to en-
sure proper access to domain functions by registrars and token based control
of domain operations by registrants as defined by the following framework.

THE REGISTRY SYSTEM AND SERVICES


 a Introduction
 b Access to the Registry System
 c Registrar Support Services
 d dotAfrica TLD Registrar Interface

NEW REGISTRATIONS


 a Domain Name Registration Process
 b Managing Domain Names
 c Registrar Maintenance
 d Locking Domain Names

CANCELLATIONS, REINSTATEMENTS AND DELETIONS


 a Canceling a Domain Name other than During a Grace Period
 b Canceling a Domain Name during a Grace Period
 c Cancellation of Non-Renewed Domain Names
 d Reinstating Cancelled Domain Names
 e Status Change Notifications to Registrars
 f Status Change Notifications to Registrants

CHANGES TO REGISTRANT INFORMATION


 a Registrant Notification
 b Registrant Change Reinstatement
 c Registrar Guidelines

CHANGES TO ZONE RECORDS


 a General
 b Principles

TRANSFERS BETWEEN REGISTRARS


 a Registrant Notification
 b Registrant Token Control
 c Transfer Control Process (Including Registrant Token Based Control)
 d Transfer Reimbursements


5.1 Authentication and Notification Mechanisms

The dotAfrica TLD Registry implementation will support password based
authentication for Contact and Domain Registry objects. These password
based authentication mechanisms may bypass object locks (EPP client Ac-
tion Prohibited statuses) depending on usage. One-time passwords may be
utilized to issue emergency transfers or suspensions if deemed necessary by
the dotAfrica Policy Oversight Committee .

The dotAfrica TLD Registry implementation employs out-of-band notifica-
tion to the Domain Registrant. The notification system, usually Email⁄SMS
based, is utilized whenever a Domain or Contact object transform command
is executed. The notification provides the Registrant an opportunity to
query and, if applicable, cancel the action or transfer the domain. Addi-
tionally, the notification system allows Domain Registrants to vote via Web
or Email on Domain Transfer requests. If, at any point in the process, the
Registrant feels that the requesting Registrar is being abusive the registrant
may issue an abuse complaint as per section 2.2 of this document.

In addition to the out-of-band notification system, the Registry also em-
ploys EPP based Poll messages for the current sponsor of the EPP object.
A Poll message notifying the sponsoring Registrar will be queued if any
transform command is executed on the Registry.


6 Orphan Glue Record Policy

The dotAfrica Registry implementation may prohibit the use of Host cre-
ate⁄update commands, thus forcing the requester to create Host associations
via the Domain create⁄update commands. The process ensures that a host
cannot be edited directly and glue cannot be adjusted without knowledge of
the superordinate domain. The Zone publication procedures will not pub-
lish Glue records for Host objects if the superordinate domain is not owned
and published by the same Registrar. The process inherently prevents the
creation and publication of orphan glue.
If at any point orphan glue records should exist the ZA Central Registry
will provide a policy for removing it based on document ICANN document
sac-048-en.pdf as published by the ICANN Security and Stability Advisory
Committee (SSAC) dated 12 May 2011.


7 Resource Planning

In the interim post delegation phase, the abuse point of contact portfolio
may require the appointment of at least two people. Costing for this position
is included in the financial model submitted with this application.

1 Synopsis

This chapter provides details on the Rights Protection Mechanisms as pro-
posed for the dotAfrica gTLD including the sunrise and landrush policy
implementation in accordance with the ICANN Uniform Domain Name Dis-
pute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system,
and Trademark Claims and Sunrise services at startup.


2 Launch Process Outline

The ZA Central Registry intends to offer the following launch model.

 * Pre-Sunrise: Allowing names to be reserved for a period of 24 months
 or to be blocked.

 * Sunrise 1: (favouring trademarks registered inAfrica; those trademarks
 registered or applied for 18 months prior to delegation will be granted
 an additional level of priority)

 * Sunrise 2: Favouring all trademarks

 * Introductory Land Rush: seeking to allocate premium names in sepa-
 rate sub-phases, during which the prices of these names will decrease
 in steps.

 * Initiation Land Rush: Seeking to allocate names not previously iden-
 tified as premium at an increased price compared to open delegation.

 * Limited Availability Operational Period: Placing newly requested names
 on a reserved list for a short period before allocation to guard against
 unfair allocation of domain names where multiple applications for the
 same domain name following release of domains or following an an-
 nouncement or event. Conflicted names will be referred to auction.

 * General Availability Operational Period: Steady state pricing; first-
 come-first-served allocation.


3 Sunrise:

The Sunrise process is separated into three phases:

 * Pre-Sunrise provides the opportunity to place names on the reserved
 or blocked lists. Names will be placed on the Reserved list if they hold
 special meaning in Africa (such as city names, names of cultural sites
 or groups, etc). Names will be blocked if the names are offensive in the
 African region. The African Union Commission (AUC) in partnership
 with the African Governments will administer Pre-Sunrise.

 * Sunrise 1 provides priority for eligible owners of trademarks registered
 in Africa to obtain domains corresponding to the trademarks they own
 that are related to the policy of the Registry.

 * Sunrise 2 allows eligible trademark owners to obtain domains corre-
 sponding to the trademarks they own.

There is no priority during the respective Sunrise Periods. A batching sys-
tem is used for identical competing applications, which are then allocated
by auction.

The ZA Central Registry will publish full details of its Sunrise policy and eli-
gibility once it has been approved by the Policy Oversight Committee. What
follows is a basic outline of the proposed policy with some key definitions.
To be eligible to submit a REGISTRATION REQUEST under Sunrise 1, a
Sunrise APPLICANT must:

 1. comply with the SUNRISE ELIGIBILITY REQUIREMENTS; and

 2. be related to the POLICY of the REGISTRY; and

 3. AFFIRM COMPLIANCE with the POLICY of the REGISTRY.

To be eligible to submit a REGISTRATION REQUEST under Sunrise 2, a
Sunrise APPLICANT must:

 1. comply with the SUNRISE ELIGIBILITY REQUIREMENTS; and

 2. AFFIRM COMPLIANCE with the POLICY of the REGISTRY.


3.1 Sunrise Definitions:

The policy will in all likelihood be based inter alia upon the following key
definitions.

ELIGIBLE: A trademark or service mark conforming to the SUNRISE
 ELIGIBILITY REQUIREMENTS (SERs).

OWNERSHIP: Ownership of an ELIGIBLE trademark may mean owner,
 co-owner or assignee. For an assignee, the PROVIDER may request
 appropriate evidence that the assignment has taken place, and meets
 the legal requirements to be an effective assignment in the jurisdiction
 in which the mark is registered. For a co-owner, the PROVIDER may
 request appropriate evidence that the co-owners have joined in the
 application. Any dispute will be decided upon by the PROVIDER.

PROVIDER: An independent entity or entities appointed by the Reg-
 istry to provide certain rights protection services which may include
 inter alia verification, validation, and dispute resolution related to el-
 igibility of trademarks. In this regard the ZA Central Registry has
 provisionally elected to engage the South African Institute of Intel-
 lectual Property Law (www.SAIIPL.org.za) for assistance and advice
 concerning the establishment of a specialist panel of experts.

REGISTRATION REQUEST: An application submitted by an AC-
 CREDITED REGISTRAR on behalf of an APPLICANT to register
 a name in the TLD.


3.2 Sunrise Dispute Resolution Policy

The REGISTRY will operate a Sunrise Dispute Resolution Policy either it-
self or via the PROVIDER, full details and the fees of which will be published
on the REGISTRY WEBSITE.
The policy will allow challenges based on the following grounds:

 * at the time the challenged domain name was registered, the domain
 name REGISTRANT did not hold an ELIGIBLE trademark;

 * the trademark registration on which the domain name REGISTRANT
 based its Sunrise registration is not ELIGIBLE;

 * the domain name is not identical to the trademark on which the do-
 main name REGISTRANT based its Sunrise registration; and

 * the REGISTRATION REQUEST which led to the award of the do-
 main name was in some way incorrect, misleading or fraudulent.


3.3 Sunrise Eligibility Requirements (SERs)

 1. These are cumulative.

 * OWNERSHIP of a word mark registered in the Trademark Clearinghouse; or

 * OWNERSHIP of a word mark of national or regional or interna-
 tional effect registered in one of the states or entities in the WIPO
 Standard ST.3, that is in full force and effect at the time of sub-
 mission of the REGISTRATION REQUEST, and at the time of
 Registration of any awarded name, and for which acceptable ev-
 idence of USE in the class for which it is registered is provided;
 or

 * OWNERSHIP of a word mark that has been court-validated; or

 * OWNERSHIP of a word mark that is specifically protected by
 a statute or treaty currently in effect. Trademarks that were in
 effect on or before a date 18 months prior to delegation will be
 given priority in Sunrise 1;

 2. a word mark which directly corresponds to the name in the REGISTRATION REQUEST;

 3. a statutory declaration or an affidavit signed by the APPLICANT:

 * that the information provided is true, correct and complete;

 * that no pertinent information has been withheld;

 * that acknowledges the fact that if there is any information with-
 held, that it automatically results in the loss of rights in any do-
 main name(s) acquired, or the loss of the right to seek to register
 same; and

 * that the application is compliant with the relevant Sunrise requirements;

 4. provision of data conforming to the SUNRISE INFORMATION REQUIREMENTS sufficient
 to document rights in the trademark;

 5. is not a word mark that includes the STRING as a portion of the
 trademark;

 6. is not a trademark for which an application for registration has been
 filed, but is not actually registered;

 7. is not a trademark for which an application has lapsed, been with-
 drawn, revoked, or cancelled;

 8. is not an unregistered trademark including such common law marks;

 9. is not a U.S. state trademark or service mark or a U.S. supplemental
 registration;

10. is not an international application for the registration of trademarks,
 made through the Madrid system, unless based on or have resulted in
 a registered trademark of national effect;

 11. is not intellectual property other than a word mark such as rights in a
 sign or name, including domain names, trade names, and appellations
 of origin.

 12. is not a trademark registration that came into full effect after the
 effective date of the Registry Agreement;

 13. is not a trademark registration that was applied for after the 1 May
 2012 being the date at which ICANN announced the applications re-
 ceived.

One key objective of the SERs is to facilitate marks registered and used in
good faith and not merely as a means to register a domain name.


3.4 Sunrise Information Requirements

APPLICANTS in Sunrise 1 and Sunrise 2 must submit the following in-
formation, either in an ACCEPTABLE ELECTRONIC FORMAT, as pre-
scribed by the ZA Central Registry, or via a link to the relevant database
of the trademark registry, as part of a REGISTRATION REQUEST:

 * EITHER OF: the Trademark name and its corresponding Trademark
 Clearing House identity number; or

 * Two (2) all of the following:

 - the trademark corresponding to the name to be Registered;
 - the country, region, or organization found in WIPO STANDARD
 ST.3 in which the trademark is registered;
 - the current registration number of the trademark;
 - the date on which the trademark application was submitted;
 - the date on which the trademark was registered;
 - the class or classes under the latest publication of the Nice system
 (or its equivalent) for with the trademark is registered (see: ; and
 - the status of the APPLICANT being one of owner, co-owner, or
 assignee of the trademark.

USE: Acceptable evidence of use will be a signed declaration and a sin-
gle specimen of current use, which might consist of labels, tags, containers,
advertising, brochures, screen shots, or something else that evidences cur-
rent use in the relevant jurisdiction, provided in an ACCEPTABLE ELECTRONIC FORMAT.
The form of the signed declaration will be as follows. I⁄We [name of applicant]
declare that I⁄we have used the trademark [name of work mark] since
[date] in [country] on [state goods or services] and attach a sample of [type
of sample] as evidence.


4 Land Rush:

Land Rush is a period designed to allocate domain names (by price) that
may be regarded by the market as desirable (premium names). The Land
Rush Period is divided into sub phases and will be administered through
the Applicants Registrar Web Portal.

The first phase is the Introductory Land Rush period. All Domain Names
not taken up during the Sunrise Periods are made available for purchase
for a certain period at a certain price. Where there is more than one party
interested in the same domain name, that domain name will be auctioned.
Only parties that indicated that they were willing to pay the price for the
domain name during that period (by submitting an application for the name
in the prescribed manner) will be entitled to bid in the subsequent auction.
During the Introductory Land Rush period the price of domain names will
start at USD 10000, and will fall by USD 2000 at the beginning of each
subsequent period (such as a week) until it reaches USD 2000. Bids will be
collated at the end of each of these periods and undisputed applications will
be allocated, whilst disputed application (more than 1 (one) application for
the same name) will be referred to auction.

Then starts the Initiation Land Rush period. This period will last for an
estimated 14 days. It will also be administered through the Registrar Web
Portal. A minimum cost of USD 300 will apply to registrations during this
period. Multiple applications for the same domain name during this period
will also be resolved using an auction process. Undisputed applications will
be allocated at the end of the period.

To be eligible for Land Rush an applicant must AFFIRM COMPLIANCE
with the POLICY of the REGISTRY. An applicant may submit one or more
REGISTRATION REQUESTS during Land Rush for any available name.


5 Operational Phase: Limited Availability:

Depending on the decision made by the dotAfrica Policy Oversight Commit-
tee , the ZA Central Registry may elect to implement a limited availability
operational phase, following on from the Initiation Land Rush period. This
phase could last between 0 and 14 days, and will be administered through
the Applicants SRS EPP system.
The procedure will be to place any requested domain name (application)
in a reserved queue for a short period. If any additional applications for
the same domain name are received during this period then the domain will
enter a Land Rush auction for a maximum predetermined period. At the
end of the period the bids will be collected and the winner determined.
This process is intended to mitigate the effects of multiple applications for
the same name following domain release as well as spontaneous applications
due to international events or announcements.


6 Operational Phase: General Availability:

General Availability starts at the close of the limited availability operational
phase. Domain names are available at fixed prices (via Registrars) on a first-
come first-served model.


7 Trademark Clearing House:

During Sunrise 1 and Sunrise 2, all applications will be compared to the
Trademark Clearinghouse database, and the applicant will be informed if
there is any trademark in that database that is an identical match to the
domain name applied for.
The notice will be sent in English, and the applicant will be required to:

 1. Acknowledge receipt of the notice;

 2. Confirm that it understands the notice; and

 3. Confirm that, to the best of its knowledge and belief, use of the domain
 name applied for will not infringe the rights of the trademark cited.

During Sunrise 1, Sunrise 2 and Introductory Land Rush, all applications
will be compared to the Trademark Clearinghouse database and, if the do-
main name is identical to any trademark recorded in this database, the owner
of that trademark shall be given notice of the domain name application in
good time for him to also make application for the domain name.

8 Rights Protection Mechanisms (RPMs):

All RPMs prescribed by ICANN will be implemented.
In particular, the Uniform Rapid Suspension System (URS) shall be avail-
able. Examiners accredited by ICANN appointed Dispute Resolution Ser-
vice Providers (according to the Applicant Guidebook Module 3, paragraph
3.2.3) will be requested to make findings in URS applications.
In the case of where a Post Delegation Dispute Resolution Procedure (PDDRP)
is initiated following allegations that the Registry profited from a bad faith
registration, the Registry undertakes to participate in the procedure and be
bound by the determination made. This will be specifically included in the
agreement with prospective applicants for domain names in this TLD.
Providers accredited by ICANN as Dispute Resolution Service Providers
(according to the Applicant Guidebook Module 3, paragraph 3.2.3) will be
requested to stand as Providers in PDDRP applications.
Provision will be made to file initial complaints that the Registry has not
complied with registry restrictions through a Whois Data Problem Report
System (WDPRS) through InterNIC.net at a nominal, non-refundable fee.
If a complainant is not satisfied that the Registry has complied with its
requirements, the matter may be escalated using the RRDRP.
In the case of Registry Restrictions Dispute Resolutions Procedures (RRDRP),
the Registry undertakes to participate in the procedure and be bound by
the determination made. This will be specifically included in the agreement
with prospective applicants for domain names in this TLD.
Providers accredited by ICANN as Dispute Resolution Service Providers
(according to the Applicant Guidebook Module 3, paragraph 3.2.3) will be
requested to stand as Providers in RRDRP applications.
The Registry will endeavour to encourage and support suitably qualified
persons in Africa to apply to be appointed to the board of Examiners in the
present ICANN Dispute Resolution Bodies.


9 Resources:

Supporting RPMs requires several departments within the registry operator
to work together. The implementation of Sunrise and the Trademark Claims
service and on-going RPM activities will pull from the members of the en-
gineering, product management, development, security and policy teams at
the registry. No additional hardware or software resources are required to
support this as the Applicant has fully operational capabilities to manage
abuse today.

1 Synopsis

This chapter provides a summary of the security policy for the proposed
dotAfrica TLD to be provided and implemented by the ZA Central Registry.


2 Independant Assessment

The ZA Central Registry has developed and ISO27001 Information Security
Management System (ISMS) policy with an accreditation provider. The ZA
Central Registry is committed to obtaining ISO27001 certification. Further
details are included in Question 30b.


3 Registry Security Policy

The Registry Security Policy acts the overseeing policy for the following key
aspects:

Data Security:- The data security must be maintained to ensure data
 integrity and confidentiality. All the policies and procedures for data
 security are detailed in the Data Security Policy.

Hardware Security:- Hardware security must be instituted to maintain
 system availability, integrity and confidentiality. All the policies and
 procedures for hardware security are detailed in the Hardware Security
 Policy.

Network Security:- Network must be secure to ensure system availabil-
 ity, integrity and confidentiality. All the policies and procedures for
 network security are detailed in the Network Security Policy.

Software Security:- Software security for all system services must be main-
 tained to ensure system availability, integrity and confidentiality. All
 the policies and procedures for software security are detailed in the
 System Services Security Policy.

Physical Security:- Physical security must be maintained at all sites to
 ensure system availability, integrity and confidentiality. All the poli-
 cies and procedures for physical security are detailed in the Physical
 Security Policy.

Threat Security:- Threats must be identified mitigated and managed to
 ensure system availability, integrity and confidentiality. All the policies
 and procedures for threats are detailed in the Threat Security Policy.
Issue Tracking System:- The registry must provide and maintain a issue
 tracking system for tracking security incidents, the system will contain
 all information detailed the Security Incident Report contained in the
 Threat Response Procedure.

The Main Policy Statement is:
The ZA Central Registry must ensure the registry system main-
tains availability, integrity and appropriate confidentiality of all
information.
Compliance to the Registry Security Policy is ensured through the following
Compliance Clause:
The security measures will be tested and a report will be compiled
and reviewed by management in accordance with the security pol-
icy schedule to be defined by management.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


4 Data Security

The security policy governing Data Security is the ʺData Security Policyʺ
with the following Main Policy Statement:
The ZA Central Registry does ensure the protection of registry
system data and backups and prevent any unauthorised access.
The Data Security Policy address the following key aspects:

Access Control:- Access to registry system must be performed through
 the following mechanisms:

 1. Authentication in accordance with the following procedure:Authentication
 Procedure
 2. Access Control Lists (ACL) in accordance with the following pro-
 cedure:Access Control List Procedure

Data Encryption:- All communication with the database must be over
 encrypted SSL connections.
Private Keys:- Private Keys for zone signing must be stored in Hardware
 Security Module HSM devices. These will be managed according to
 the HSM Key Procedure.

Backups:- Backups are stored in secure storage and in secure off site stor-
 age facilities. Backups are also encrypted and will be performed ac-
 cording to the procedure detailed in the Backup Procedure.

Data Escrow:- dotAfrica TLD conforms with ICANNʹs requirements on
 registry data escrow as outlined by Specification 2 of the Agreement
 as contained in the Applicant Guidebook. The procedure for handling
 data escrow is defined in the Data Escrow Procedure.

Portable Storage:- Sensitive registry data must not be stored on portable
 drives or USB flash disks unless required to by security procedure and
 fully encrypted.

Compliance to the Data Security Policy is ensured through the following
Compliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


5 Hardware Security

The security policy governing Hardware Security is the ʺHardware Security
Policyʺ with the following Main Policy Statement:
The ZA Central Registry must ensure the registry system hard-
ware including servers, HSMʹs and routers are protected from
unauthorised access.
The Hardware Security Policy address the following key aspects:

Physical Access:- Physical access to the area containing registry hardware
 including servers, HSMʹs and routers are controlled by keycard and
 biometric access control mechanisms. Keycards are used and issued
 according to the Keycard Issuing Procedure.
Server Access:- All servers are housed in locked server cabinets.

Router Access:- All routers are housed in locked server cabinets.

HSM Access:- All HSMʹs are housed in locked server cabinets or locked
 safes.

Console Access:- All console access is restricted by system level password
 authentication and follow the procedures defined in the Authentication
 Procedure.

Auditing Access:- All network access is logged and audited in accordance
 with the Threat Detection Through Auditing section.

Compliance to the Hardware Security Policy is ensured through the following
Compliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


6 Network Security

The security policy governing Network Security is the ʺNetwork Security
Policyʺ with the following Main Policy Statement:
The ZA Central Registry must ensure the registry system network
infrastructure routers are protected from unauthorised access and
DOS attacks.
The Network Security Policy address the following key aspects:


6.0.1 Supporting Statements

Firewall:- A Firewall is configured to limit connections according to an
 ACL. The ACL will be operated in accordance with the Access Control
 List Procedure
Routers:- Routers are secured by limiting access according to an ACL.
 The ACL must be operated in accordance with the Access Control
 List Procedure

DOS Mitigation:- A plan is in place to mitigate the effects of a DOS
 attack. The procedures for mitigating security threats is detailed in
 the Threat Mitigation Procedure.

Network Access:- Network access is controlled by the use of the following
 2 mechanisms:

 1. Authentication in accordance with the Authentication Procedure

 2. Access Control Lists (ACL) in accordance with the Access Con-
 trol List Procedure



Compliance to the Network Security Policy is ensured through the following
Compliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.


7 System Service Security

The security policy governing System Service Security is the ʺSystem Service
Security Policyʺ with the following Main Policy Statement:
The ZA Central Registry must ensure the registry system software
is maintained and updated to prevent any security issues.
The System Service Security Policy address the following key aspects:

Operating System:- All registry systems run Ubuntu LTS 12.04 or newer.

Operating System Security Updates:- All security patches for operat-
 ing systems that are identified as required by the registry system are
 applied as follows:

 Critical :- within 24 hours of the notice being received.
 High :- within the next maintenance window.
 Warning :- within the next 4 maintenance windows.
OpenSSL Software Updates:- All security updates to the OpenSSL li-
 braries that are identified as required by the registry system are applied
 as follows:
 Critical :- within 24 hours of the notice being received.
 High :- within the next maintenance window.
 Warning :- within the next 4 maintenance windows.
OpenSSH Server Software Updates:- All security updates to the OpenSSH
 server that are identified as required by the registry system are applied
 as follows:
 Critical :- within 24 hours of the notice being received.
 High :- within the next maintenance window.
 Warning :- within the next 4 maintenance windows.
BIND Server Software Updates:- All security updates to the BIND server
 that are identified as required by the registry system are applied as
 follows:
 Critical :- within 24 hours of the notice being received.
 High :- within the next maintenance window.
 Warning :- within the next 4 maintenance windows.

Compliance to the System Security Security Policy is ensured through the
following Compliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


8 Physical Security

The security policy governing Physical Security is the ʺPhysical Security
Policyʺ with the following Main Policy Statement:
The ZA Central Registry must ensure the registry system physical
sites are secure to prevent any unauthorized access.
The Physical Security Policy address the following key aspects:
Regulation Compliance:- The registry physical security measures com-
 ply with local safety codes, building codes and fire prevention codes.

Building Access:- Building Access is controlled by the use of key cards.

Server Room Access:- Server Room Access is controlled by the use of
 biometric testing.

Server Cabinet Access:- Server Cabinet Access is controlled by the use
 of keys.

Access Auditing:- All access logs are kept for auditing purposes.

Compliance to the Physical Security Policy is ensured through the following
Compliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


9 Threat Security

The security policy governing Threat Security is the ʺThreat Security Pol-
icyʺ with the following Main Policy Statement:
The ZA Central Registry must ensure the registry system man-
ages its security risk against threats identified.
The Threat Security Policy addresses the following key aspects:

Threat Identification:- Threats that are identified are reported on in ac-
 cordance with the Threat Identification Procedure.

Threat Classification:- Threats are classified. Threat Classification must
 be done in accordance with the Incident Severity Classification Proce-
 dure.

Threat Detection:- Threats are identified through auditing logs. Threat
 Detection is done in accordance with the Threat Auditing Procedure.
Threat Mitigation:- Threats are mitigated to reduce risk to the registry
 system where reasonable. Threat mitigation is done in accordance
 with the Threat Mitigation Procedure.

Threat Response:- Threats are responded to in accordance with the threat
 classification and Threat Response Procedure.

Compliance to the Threat Security Policy is ensured by the following Com-
pliance Clause:
The security measures will be tested every 6 months and a report
will be compiled and reviewed by management. This period may
be reviewed at the discretion of the IT Manager.
Any reports required for decision making will be made available in a timely
manner prior to the policy compliance review date.
All processes and procedures are supported by reporting systems, allowing
timely access to required information.
Compliance is measured according to the success or failure of the abovemen-
tioned key aspects as well as any other criteria identified by the management.


10 Additional Information

Monitoring of systems for compliance to the abovementioned policies is per-
formed by various tools that review logs, monitor critical systems availabil-
ity, produce security reports and will escalate identified anomalies to the
network and system administrators on a 24x7 basis.


11 Commitment to Registrants

The ZA Central Registry is committing to running industry standard secu-
rity practices or higher where possible.


11.1 Registrant Rights

The registrant will retain control of their domain name, and in this regard
registrants must be able to choose the registrar they wish to use to maintain
the domain name. The registrar will not operate in such a way that the
registrant is locked-in, or such that their actions could make the registrant
reasonably believe that they are locked-in.