Application Downloaded On: 17 Feb 2014
String: africa
Application ID: 1-1243-89583
1. Full legal name
ZA Central Registry NPC trading as Registry.Africa
2. Address of the principal place of business
COZA House, Gazelle Close
Corporate Park South Midrand, Gauteng - 1685 ZA
3. Phone number
+27 11 314 0077
4. Fax number
+27 11 314 0088
5. If applicable, website or URL
http://www.AfricaInOneSpace.org
6(a). Name
Neil Dundas
6(b). Title
Director
6(c). Address
6(d). Phone Number
+27 82 468 1858
6(e). Fax Number
+27 11 314 0088
6(f). Email Address
ndundas@registry.net.za
7(a). Name
Simla Budhu
7(b). Title
Manager - Legal & Policy
7(c). Address
7(d). Phone Number
+27 82 575 0926
7(e). Fax Number
+27 11 314 0088
7(f). Email Address
sbudhu@registry.net.za
8(a). Legal form of the Applicant
Not for Profit Company (NPC)
8(b). State the specific national or other jurisdiction that defines the type of entity identified in 8(a).
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)
8(c). Attach evidence of the applicant's establishment.
Attachments are not displayed on this form.
9(a). If applying company is publicly traded, provide the exchange and symbol.
9(b). If the applying entity is a subsidiary, provide the parent company.
Not applicable
9(c). If the applying entity is a joint venture, list all joint venture partners.
11(a). Name(s) and position(s) of all directors
|
| BROWNE, Calvin Scott | Director |
| DUNDAS, Neil Duncan | Director |
| ELKINS, Mark James | Director |
| KRAMER, Theodorus | Director |
| WALLACE, Fiona Jean | Director |
11(b). Name(s) and position(s) of all officers and partners
|
| BUDHU, Simla Rathilal | Legal & Policy Manager |
| ELS, Lizette | Administration Manager |
| MAASDORP, Sedrick Marco | Human Resoruces Manager |
11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility
|
| EL BASHIR, Mohamed | Chairperson: dotAfrica Steering Committee |
13. Provide the applied-for gTLD string. If an IDN, provide the U-label.
africa
14A. If applying for an IDN, provide the A-label (beginning with "xn--").
14B. If an IDN, provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.
14C1. If an IDN, provide the language of the label (in English).
14C2. If an IDN, provide the language of the label (as referenced by ISO-639-1).
14D1. If an IDN, provide the script of the label (in English).
14D2. If an IDN, provide the script of the label (as referenced by ISO 15924).
14E. If an IDN, list all code points contained in the U-label according to Unicode form.
15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
- the applied-for gTLD string relevant to the tables,
- the script or language designator (as defined in BCP 47),
- table version number,
- effective date (DD Month YYYY), and
- contact name, email address, and phone number.
Submission of IDN tables in a standards-based format is encouraged.
15B. Describe the process used for development of the IDN tables submitted, including consultations and sources used.
15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.
16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.
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.
17. OPTIONAL.
Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).
18A. Describe the mission/purpose of your proposed gTLD.
Introduction: Mission, Vision and Purpose:
ZA Central Registry NPC 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 ZA Central Registry NPC to apply for and launch the dotAfrica TLD.
In this application and any supporting documentation relating thereto, the Applicant may be referred to as ZA Central Registry NPC, 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 ZA Central Registry, 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.
18B. How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?
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.
18C. What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences/costs imposed upon consumers?
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.
19. Is the application for a community-based TLD?
No
20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.
20B. Explain the applicant’s relationship to the community identified in 20(a).
20C. Provide a description of the community-based purpose of the applied-for gTLD.
20D. Explain the relationship between the applied- for gTLD string and the community identified in 20(a).
20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.
20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.
21A. Is the application for a geographic name?
Yes
22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.
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.
23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
- Receipt of data from registrars concerning registration of domain names and name servers.
- Dissemination of TLD zone files.
- Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
- Internationalized Domain Names, where offered.
- DNS Security Extensions (DNSSEC). The applicant must describe whether any of
these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.
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:- ZA Central Registry NPC 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
ZA Central Registry NPC, 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 ZA Central Registry NPC 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, ZA Central Registry NPC 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.
24. Shared Registration System (SRS) Performance:
describe
- the plan for operation of a robust and reliable SRS. SRS is a critical registry function for enabling multiple registrars to provide domain name registration services in the TLD. SRS must include
the EPP interface to the registry, as well as any other interfaces intended to be provided, if they are critical to the functioning of the registry. Please refer to
the requirements in Specification 6 (section 1.2) and Specification 10 (SLA Matrix) attached to the Registry Agreement; and
• resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel
roles allocated to this area).
A complete answer should include, but is not limited to: - A high-level SRS system description;
- Representative network diagram(s);
- Number of servers;
- Description of interconnectivity with other registry systems;
- Frequency of synchronization between servers; and
- Synchronization scheme (e.g., hot standby, cold standby).
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.
25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.
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
26. Whois: describe
- how the applicant will comply with Whois specifications for data objects, bulk access, and lookups as defined in Specifications 4 and 10 to the Registry Agreement;
- how the Applicant's Whois service will comply with RFC 3912; and
- resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
A complete answer should include, but is not limited to:
- A high-level Whois system description;
- Relevant network diagram(s);
- IT and infrastructure resources (e.g., servers, switches, routers and other components);
- Description of interconnectivity with other registry systems; and
Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:
- Provision for Searchable Whois capabilities; and
- A description of potential forms of abuse of this feature, how these risks will be mitigated, and the basis for these descriptions
A complete answer is expected to be no more than 5 pages.
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.
27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:
- explain the various registration states as well as the criteria and procedures that are used to change state;
- describe the typical registration lifecycle of create/update/delete and all intervening steps such as pending, locked, expired, and transferred that may apply;
- clearly explain any time elements that are involved - for instance details of add-grace or redemption grace periods, or notice periods for renewals or transfers; and
- describe resourcing plans for this aspect of the criteria (number and description of personnel roles allocated to this area).
The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.
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.
28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:
- An implementation plan to establish and publish on its website a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller;
- Policies for handling complaints regarding abuse;
- Proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6); and
- Resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.
- Measures to promote Whois accuracy (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Authentication of registrant information as complete and accurate at time of registration. Measures to accomplish this could include performing background checks, verifying all contact information of principals mentioned in registration data, reviewing proof of establishment documentation, and other means
- Regular monitoring of registration data for accuracy and completeness, employing authentication methods, and establishing policies and procedures to address domain names with inaccurate or incomplete Whois data; and
- If relying on registrars to enforce measures, establishing policies and procedures to ensure compliance, which may include audits, financial incentives, penalties, or other means. Note that the requirements of the RAA will continue to apply to all ICANN-accredited registrars.
- A description of policies and procedures that define malicious or abusive behavior, capture metrics, and establish Service Level Requirements for resolution, including service levels for responding to law enforcement requests. This may include rapid takedown or suspension systems and sharing information regarding malicious or abusive behavior with industry partners;
- Adequate controls to ensure proper access to domain functions (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Requiring multi-factor authentication (i.e., strong passwords, tokens, one-time passwords) from registrants to process update, transfers, and deletion requests;
- Requiring multiple, unique points of contact to request and/or approve update, transfer, and deletion requests; and
- Requiring the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted.
A complete answer is expected to be no more than 20 pages.
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.
29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:
- A description of how the registry operator will implement safeguards against allowing unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies), and reduce opportunities for behaviors such as phishing or pharming. At a minimum, the registry operator must offer a Sunrise period and a Trademark Claims service during the required time periods, and implement decisions rendered under the URS on an ongoing basis; and
- A description of resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.
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.
30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:
- indication of any independent assessment reports demonstrating security capabilities, and provisions for periodic independent assessment reports to test security capabilities;
- description of any augmented security levels or capabilities commensurate with the nature of the applied for gTLD string, including the identification of any existing international or industry relevant security standards the applicant commits to following (reference site must be provided);
- list of commitments made to registrants concerning security levels.
To be eligible for a score of 2, answers must also include:
- Evidence of an independent assessment report demonstrating effective security controls (e.g., ISO 27001).
A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).
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.
© Internet Corporation For Assigned Names and Numbers.