ICANN New gTLD Application

Building a dotCapeTown Brand Identity

- Creating a unique On-Line Identity
- Benefiting South Africa
- Building a Global Brand
• Cape Town
• Differentiating dotCapeTown from other major cities
• Marketing, Communications and Public Relations
- Registry Operations
- Financial Aspects

Creating a unique On-Line Identity

dotCapeTown will provide a gTLD that gives the City of Cape Town a clear, distinct online identity.

The dotCapeTown TLD will provide the following added benefits:

- Give local and international businesses, organisations and individuals an opportunity to secure domain names that identify them with Cape Town.
- Enable the Cape Town Municipality to group all its services and entities under the dotCapeTown TLD, thus effectively carrying and promoting Cape Town as a brand.
- Provide South African and Cape Town tourism bodies an opportunity to group their products and services specific to Cape Town under the dotCapeTown TLD.
- Enable ZADNA and the South African government to implement a domain name strategy that ensures local geo-gTLDs are complementary to ZA and enjoy an economies of scale advantages of being operated from a reliable, secure and robust registry infrastructure

Benefitting the City of Cape Town and the South African Internet Community Nationally and Globally

In essence, dotCapeTown will benefit registrants particularly in and around Cape Town in particular to have websites that bear the name of their city, and automatically identify their geographic location.

Local and international organisations and businesses trading in and around Cape Town will be able to have websites that clearly identify Cape Town as their area of business. Local communities will be able to use dotCapeTown to brand and position their community projects better than other gTLDs.

Competition:

In the case of the South African market, dotCapeTown will give registrants a more identifiable geographic identity than the general ZA. It will also mean registrants that lost out on their most preferred domain names in ZA and other TLDs can now have an opportunity to register such names and enjoy the reputation and commercial credibility that comes with doing business in, or being identified with, Cape Town – South Africa’s mother city.

dotCapeTown is not meant to be positioned as competing with ZA. Instead it is meant to complement ZA in the sense that it will be run from a ZA infrastructure and use ZA policies as far as these are in line with ICANN requirements.

In essence, the population of the City of Cape Town is estimated to be around 3,5 million. This implies that ZADNA does not primarily see dotCapeTown as a gTLD for high registration numbers. Rather, ZADNA primarily sees dotCapeTown as an enabler of more focused online identity and innovation for the communities and businesses around Cape Town.

From this perspective, ZADNA intends to have ZACR operate dotCapeTown on a non-profit, cost recovery basis, and intends subsidizing its operations (including ICANN fees) from the ZA domain name fees.

Differentiation:

The important and most obvious advantage dotCapeTown gives is clear differentiation, in particular for local and international businesses trading in or with Cape Town. For the Cape Town City Municipality, dotCapeTown provides it with the opportunity to house all its websites, entities and services under one gTLD bearing its name: dotCapeTown.

For national government, dotCapeTown allows it to be able to have dotCapeTown websites for all its projects, programmes, services and divisions servicing or located in and around Cape Town.

As a geographic indicator, the dotCapeTown TLD will automatically assume the reputation and goodwill of the region it represents. In the mind of the user, Africa represents a unique part of the world, with unique people, challenges and prospects. dotCapeTown, as a TLD, 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 city.

Innovation:

Innovation possibilities for dotCapeTown are expected to be material. dotCapeTown will allow local communities in and around Cape Town to group certain websites under the name “Cape Town”. For example, the domain name “Gugulethu.CapeTown” can allow businesses in Gugulethu to have 3rd level registrations identifying them clearly to be based in Gugulethu, Cape Town.

Think of the Parliament in Cape Town having parliament.citybowl.capetown. The historic District 6 landmark can be found at district6.gugulethu.capetown, while the famous restaurants, shops and guesthouses can all benefit from websites such as restaurantA.gugulethu.capetown, shopB.gugulethu.capetown and guesthouseC.gugulethu.capetown.

Such innovation potential, therefore, opens up entrepreneurship opportunities. dotCapeTown registrants can become second level “registries” and “registrars”, and sell domain names at the third level.

In addition, dotCapeTown allows for the allocation of certain domain names to specific organisations and communities to use for running websites. In this sense, the allocated names can be required to have active, dynamic content to ensure the visibility of dotCapeTown online.

ZADNA intends to reserve a limited number of premium names and to use these to generate content that will ensure the online visibility of dotCapeTown.

(B) The Development of the Local Domain Name Entrepreneur Market:

In the event that the dotCapeTown gTLD is awarded to the ZACR then the dotCapeTown TLD is intended to result in the expansion of the South African local Registrar and Reseller market. The initial opportunity will exist through dotCapeTown Registrants being able to sell 3rd level registrations. For example, the gugulethu.capetown Registrant may sell names to businesses and organisations in Gugulethu. This possibility means that dotCapeTown may open up business opportunities for secondary “Registrars” and Resellers at the 2nd level.

In addition, the dotCapeTown Registrants can become second level Registry operators without having to comply with any more formality than simply obtaining a dotCapeTown name.

These possibilities are intended to gradually use dotCapeTown to encourage local domain name entrepreneurs to grow their businesses to the level where they can obtain ICANN Registrar Accreditation.

The dotCapeTown project is a fantastic opportunity to drive content development focusing specifically on the City of Cape Town. In essence, in order to kick-start this process and achieve some level of critical mass, the ZACR will reserve (pre-register) 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.

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

- encourage existing city and the broader South African communities and service providers to associate their content with the dotCapeTown TLD (and, if possible, to customise it) in order to better engage with this user community. Potential targets for this initiative include South African government departments and agencies, large multi-national and parastatal organisations as well as the broader African internet community.

- 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 South African market. Potential targets for this initiative include social media platforms, search engines providers, and leisure and business service providers.

- establish partnerships and associations with South African and international 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, etc.

Building a Global Brand with a Focus on Cape Town and South Africa:

Marketing, Communication and Public Relations:

The aim of marketing and communication is to create awareness of the dotCapeTown gTLD and to rally support by keeping stakeholders engaged with the process.

The marketing of the dotCapeTown brand will occur in terms of a defined strategy based on the following internal values:

- managing competitive advantage by striving to provide value to stakeholders and users (governments, businesses and individuals within South Africa and abroad), by engaging in focussed, time-based marketing strategies to develop and enhance the dotCapeTown brand in South Africa and abroad. Innovation is key to the success of the dotCapeTown domain namespace;

- viewing change as an opportunity by recognising the fluidity in the Internet environment as an opportunity and not a threat, in order to improve processes, systems and culture relevant to the dotCapeTown domain namespace;

- developing a strategically managed enterprise by establishing an innovative, well governed and transparent organisation with effective systems, excellent staff and shared values.

The Marketing Campaign will focus on the following strengths:

- the availability of sufficient funding and other resources;
- an able, skilled and qualified management team;
- already available infrastructure and hardware;
- sustainable and strong partnerships in the DNS industry;
- a clear vision of the market need for dotCapeTown;
- the know-how to implement and operate the registry services.
- a city that serves as the tourist hub of Africa

Target Market:
The purpose of dotCapeTown is not primarily to generate profits, although this may be explored over time. The purpose is to provide a unique online identity for the City of Cape Town using the ZA registry infrastructure.

However, ZADNA will incorporate dotCapeTown within its ongoing marketing, communications and awareness campaigns. The gTLD will be communicated and positioned as being a complementary string to ZA, but with a specific focus to Cape Town.

Outreach activities will be primarily focused to businesses, organisations and communities in and around Cape Town, as these are the markets with a great potential for the growth of dotCapeTown.

ZADNA’s plan to reserve a limited number of premium names to use them to generate content that will ensure visibility of dotCapeTown on the Internet should help in creating online awareness of the advent of the dotCapeTown gTLD.

Emphasis will be on utilising the most appropriate and available media tools depending on access to them by the target market identified above. The vast target market needs to be segmented, in order to develop key messaging for each market sector and to determine our ‘Go to market’ strategy.

A dotCapeTown domain name is the perfect platform for global branding, marketing, and visibility with a focus on customers and markets in South Africa and internationally. This can help increase tourism, build and enhance international business relationships with the city as well as South Africa, and boost economic benefits. In fact, the very act of registering a dotCapeTown domain name tells the world that this is a registrant proud of its association with the city of Cape Town and deserving of recognition.

Value proposition
Cape Town is the second-most populous city in South Africa, and the provincial capital and primate city of the Western Cape. As the seat of the National Parliament, it is also the legislative capital of the country. The city is famous for its harbour as well as its natural setting in the Cape floral kingdom, including such well-known landmarks as Table Mountain and Cape Point. Cape Town is also Africaʹs most popular tourist destination. The city was named the World Design Capital for 2014 by the International Council of Societies of Industrial Design.
.
The city is the economic centre of the Western Cape Province, South Africaʹs second main economic centre and Africaʹs third main economic hub city. It serves as the regional manufacturing centre in the Western Cape. Cape Town is not only the most popular international tourist destination in South Africa, but Africa as a whole. This is due to its good climate, natural setting, and well-developed infrastructure

dotCapeTown presents a great opportunity for the city of Cape Town to differentiate itself from other major cities, and to provide innovative potential socially, economically and politically.

Marketing and Communication Platforms:
The marketing and communication campaign for dotCapeTown will utilise a number of communication platforms to create awareness and communicate with the various stakeholders, including:
- Facebook & Twitter: for instant real time communication with all stakeholders;
o facebook.com⁄dotCapeTown
o twitter.com⁄dotCapeTown
- dotCapeTown website: for information and regular news feeds;

PR platforms:
These platforms will be used to disseminate press releases and publicity information to external stakeholders. Traditional media such as newspapers, and radio will be used to spread the dotCapeTown message, and also digital media platforms.

Registry Operations:

From a technical⁄operational perspective the dotCapeTown 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 dotCapeTown registry platform is wholly developed, maintained and hosted in South 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, including the back and front office support functions. The dotCapeTown registry platform, which has been developed, implemented and maintained on the back of over 17 years registry experience by the Applicant (ZACR), 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.

Being part of the global DNS environment and subscribing to international best practices and procedures, the dotCapeTown 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 dotCapeTown.

External systems and services compliant with industry best practises and ICANN requirements include:
- Data Escrow services.
- Anycast and Unicast services.
- Off-site Hot Standby Failover Hosting.

Apart from providing a platform for growth of the ccTLD and registrar communities, the registry solution (which is more fully described in the technical submissions) allows registrars access to a number of key services including an automated Registrar Accreditation Process, Issue 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 dotCapeTown TLD registry function will be managed in a way that is service driven, secure and stable.

Registration Policy:

The dotCapeTown registration policy will be established, implemented and maintained through the ZACR as an unrestricted gTLD under the ICANN framework. The registration policy will be based on the premise that it 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, including cancellations, transfers, suspensions, revocations, etc. The policy will be informed and guided by the consensus-driven policies and procedures 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 the following:

a. Eligibility

dotCapeTown will be available to all interested parties. A limited opportunity will be given to the Cape Town Municipality to reserve a number of names for its entities and projects during the sunrise phase. A similar opportunity will be given to the South African national government.

b. First-come, first-served

Following the Sunrise and Land Rush periods, registrations will generally be delegated on a “first-come-first-served” basis upon the payment of requisite fees.

c. Renewal

dotCapeTown names shall be renewed on an annual basis on the anniversary of the registration. ZACR may, in consultation with ZADNA and ICANN, decide to allow for multiple year registration and renewal, but this shall not exceed more than 3 years.

d. Registrar services

Domain names will be registered through ICANN-accredited registrars. Each registrar will be required to pay an upfront deposit, which shall not be less than R250.00. Each registrar shall ensure that the minimum deposit available at any given time is not less than R250.

e. Determination of fees

ZADNA, in consultation with ICANN and ZACR, will determine dotCapeTown domain name fees. Any fee changes shall be upon a minimum notice of 3 months.

f. Policy development

ZADNA is responsible for developing and reviewing dotCapeTown policies and shall manage this responsibility in consultation with ZACR and ICANN.

g. IDNs

There is no plan to secure an IDN version of dotCapeTown.

Privacy protection

The establishment, implementation and maintenance of a privacy policy for the dotCapeTown TLD will be based on international best practices as well as local and international standards and requirements. The registry will strive to protect the rights and privacy of all individuals or companies associated with dotCapeTown TLD names. dotCapeTown names will be publicly accessible through a dotCapeTown Whois according to ICANN’s Whois specifications. Registrars will be allowed to provide private registration services.

Financial Aspects:

The ZACR, throughout its 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 ZACR has managed to keep the fees charged to registrars highly competitive and 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 ZACR will, under the scrutiny and oversight of ZADNA apply similar financial disciplines and procedure to the administration of the dotCapeTown TLD. As outlined above, the operating revenues generated through the administration of the dotCapeTown TLD will be accounted for in accordance with national and internationally-accepted accounting practices.

The financial parameters and policies to run the dotCapeTown TLD must still be finalised and approved by the ZADNA in consultation with the ZACR.

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 dotCapeTown 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 dotCapeTown TLD. This is significant as it will provide South African government departments and government organisations, a window of opportunity to compile and submit a list of names that must be reserved or blocked from registration. These names may be of an offensive nature or relate to cultural sensitivities within the South African context.

The Pre-Sunrise process will be administered by ZADNA and 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 ZADNA.

(B) Sunrise:
A phase-based Sunrise procedure, with associated auction processes, will be implemented to allow established South African brands and trademark holders to register their corresponding domains within the dotCapeTown TLD. ZADNA must still approve a Sunrise Policy, which must cater for the following periods:
- 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 with guidance from ZADNA 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 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 ZACR’s Registrar Web Portal. ZADNA must still draft and approve a Land Rush Policy, which caters for the 3 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 R300 - R500) 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 ZADNA, 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 ZADNA.

(E) ZADNA, will play a determining role in defining policy and determining pricing mechanisms within the dotCapeTown TLD. The scope and mandate of ZADNA will include the review and authorisation of various pricing models, including multi-year (1 – 10 years) pricing, bulk discounts and prices changes. ZADNA will consider the input and comments of the Registry Operator, 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.

ZADNA 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, ZADNA 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.

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, registrants, oversight bodies and statutory
bodies such as the judiciary and accredited dispute resolution providers.


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


3    ZA Central Registry Background

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

    * establishing the alternate dispute resolution process for adjudicating
      domain name disputes in the co.za domain.
    * translating the CO.ZA registry web site into all 11 official languages
      of South Africa as far back as 2001.

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

    * sponsoring and participating in the ISPA ʹTrain the Teachersʹ initia-
      tive.

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

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

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

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

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


4    Registry Registrar Services and Operations

This section provides details on the technical operational services critical
for the provisioning of domains, contacts and hosts as well as the services
related to both publishing domain, host and contact information and the
publishing of zone information as provided by the ZA Central Registry and
as intended for use by the dotCapeTown 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 dotCapeTown TLD and the size of
the zone.


4.3   Registry Zone Servers

The dotCapeTown TLD will use nameserver infrastructure supplied by the
ZA Central Registry including 2 anycast instances geographically dispersed
including 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 dot-
CapeTown TLD will be displayed on the Registrar portal and as detailed
under Registrar 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
    dotCapeTown TLD policy, in orange if not, and a message in red in-
    dicating 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 dotCapeTown 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 dotCapeTown TLD will be determined by the
policy oversight committee of the dotCapeTown TLD.
Whois Services offered by the ZA Central Registry for the dotCapeTown
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 dotCapeTown TLD.
Any decision to implement IDNs during the life time of dotCapeTown TLD
will be determined by industry best practises, ICANN recommendations and
the dotCapeTown 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 dotCapeTown TLD zone.
The ZA Central Registry complies with industry best practices for zone
signing and key protection, including security requirements as defined by
the dotCapeTown 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 dot-
CapeTown 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
dotCapeTown 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 dot-
    CapeTown 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 Municipality and the dot-
   CapeTown Policy Oversight Committee with an interface to determine
   registry performance, uptime, registration statistics and other infor-
   mation relating to registry service level agreements.


6     Additional Registry Services

Additional registry services for the dotCapeTown TLD include services pro-
vided 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
    Security (TLS) protocol over TCP with the dotCapeTown EPP based
    domain registration service.

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

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

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

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

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

1    Synopsis

This chapter provides details on the technical and operational capabilities
of the ZA Central Registry, and as will be used for the dotCapeTown TLD.
This covers the operational plans include system and human resourcing to
run the dotCapeTown 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 dotCapeTown 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 dotCapeTown TLD.
The SRS for the dotCapeTown TLD will comply to and keep current with
all relevant IETF RFCs in accordance with specification 6 section 1.2 and
specification 10 of the ICANN registry agreement. These include the follow-
ing

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 dotCapeTown TLD policy oversight committee
   implement policy that require extensions of the default EPP specifi-
   cation 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 dotCapeTown 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 of this document.


4.1.2    MSH System Resources

The ZA Central Registry MSH implementation for the dotCapeTown 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 dotCapeTown 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 dotCapeTown
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 dotCapeTown
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 dotCapeTown TLD, consists of the following

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

Port 43 Whois:- A port 43 whois service providing domain, host and reg-
     istrar and registrant contact details for the dotCapeTown 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 dotCapeTown
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 dotCapeTown 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 dotCapeTown TLD, consists of 8 Nameserver services placed over
a strategic 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 dotCapeTown
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 dotCapeTown TLD 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 dotCapeTown 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 dotCapeTown 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 dotCapeTown
TLD implementation based on several reasons but mainly for the ability
of scalability and synchronous replication allowing flexible remote failover
database replication which is critical in a generic top level domain (gTLD)
implementation 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 its 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 dotCapeTown
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 dotCapeTown 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 dotCapeTown 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 dotCapeTown TLD development, deployment and operational respon-
sibilities for the technical requirements will be staffed by members of the
ZA Central Registry. 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.

General Manager:- 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:- Staff member responsible for the financial system
    implementation and the day to day financial policies and procedures.

Registrar Liaison:- Person responsible for the day to day registrar related
    issues, as well as for building the registrar base.

Public Relations:- Person.

Clerical Staff:- Staff members responsible for the administrative and sup-
     port tasks.

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

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

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO THIS QUESTION IS ATTACHED AS PDF FILES dotCapetown-q25.pdf and dotCapetown-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 dotCapeTown 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 dotCapeTown implementation listens for incoming TCP connection re-
quests. 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 dotCapeTown 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 dotCapeTown 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 dotCapeTown 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 dotCapeTown handling and interpretation of the EPP Data Units con-
forms to RFC 5734 Section 4, whereby the format of any EPP data unit will
contain 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 dotCapeTown 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
associated objects. The dotCapeTown 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 dotCapeTown 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 dotCapeTown implementation of the EPP 〈logout〉 command con-
forms to the requirements outlined in RFC 5730 Section 2.9.1.2 .

4.5 EPP 〈poll〉 Protocol Command

The dotCapeTown 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 dotCapeTown 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
dotCapeTown 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 dotCapeTown 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 dotCapeTown implementation supports validity
periods in months and years, as well as a combination of both.

Authorisation Information:- The dotCapeTown implementation supports
domain 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 dotCapeTown 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 dotCapeTown implementation of the EPP 〈info〉 command conforms
to the requirements outlined in RFC 5731 Section 3.1.2. The 〈info〉 com-
mand 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 dotCapeTown implementation of the EPP 〈transfer〉 command con-
forms to the requirements outlined in RFC 5731.
The dotCapeTown implementation supports the following EPP 〈transfer〉
operations 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 dotCapeTown 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 dotCapeTown implementation of the EPP 〈create〉 command restricts
the use of the 〈period〉 element where the registry defines the registration
period of a domain object.

5.8 EPP 〈delete〉 Command

The dotCapeTown implementation of the EPP 〈delete〉 command con-
forms to the requirements outlined in RFC 5731 Section 3.2.2 . The dot-
CapeTown implementation 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 subordinate host objects are referenced by other domains belonging to
the same registrar.

5.9 EPP 〈renew〉 Command

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

5.10 EPP 〈update〉 Command

The dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5731 . The dotCapeTown imple-
mentation 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 dotCapeTown im-
plementation 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 dotCapeTown 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 dotCapeTown implementation supports IPv4 and IPv6 ad-
dresses, conforming to the requirements outlined in RFC 0791 and
RFC 4291 respectively.

6.3 EPP 〈check〉 Command

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

6.4 EPP 〈info〉 Command

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

6.5 EPP 〈create〉 Command

The dotCapeTown implementation of the EPP 〈create〉 command con-
forms 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 dotCapeTown Policy Oversight Committee .

6.6 EPP 〈delete〉 Command

The dotCapeTown Implementation of the EPP 〈delete〉 command con-
forms to the requirements outlined in RFC 5732.

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

6.7 EPP 〈update〉 Command

The dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5732.
The dotCapeTownimplementation dictates that the changing of a host ob-
ject 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 dotCapeTown Policy Oversight Committee . In the dotCapeTown
implementation the Registrar objects are stored as standard EPP Contact
objects, thus allowing a registrar to adjust contact information such as pass-
words 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 dotCapeTown implementation supports server and
client statuses outlined in RFC 5733. Status combination interactions
conform to RFC 5733 .

Internationalized Postal Info:- The dotCapeTown implementation sup-
ports 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 dotCapeTown implementation.

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

Telephone Numbers:- The dotCapeTown 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 dotCapeTown implementation conforms to the
requirements for e-mail addresses as defined in RFC 5322.

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

Authorisation Information:- The dotCapeTown implementation supports
contact object authorisation through use of passwords, conforming to
outlined requirements in RFC 5733. Passwords are stored in one-way
hash format.

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

7.3 EPP 〈check〉 Command

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

7.4 EPP 〈info〉 Command

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

7.5 EPP 〈transfer〉 Command

The dotCapeTown implementation of the EPP 〈transfer〉 query command
conforms to the requirements outlined in RFC 5733.

7.6 EPP 〈create〉 Command

The dotCapeTown implementation of the EPP 〈create〉 command con-
forms to the requirements outlined in RFC 5733 .
The dotCapeTown 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 dotCapeTown implementation of the EPP 〈update〉 command con-
forms to the requirements outlined in RFC 5733 .
The dotCapeTown implementation supports the updating of a contact ob-
ject 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 dotCapeTown implementation supports the DNSSEC and conforms to
RFC 5910. The ZA Central Registry will be operating as a thick registry.
A thick registry 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 dotCapeTown 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 dotCapeTown 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 SSL Certificate and acquiring live system credentials

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.

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

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

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〉

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

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〉
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

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:

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:

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〉

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

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

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

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

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

〈⁄schema〉
END

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS), WHICH ICANN INFORMS US (CASE ID 11027) CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE FULL ANSWER TO THIS QUESTION IS ATTACHED AS A PDF FILE dotCapetown-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 performance
and high availability by ensuring that the system is scalable, redundant and
geographically dispersed. Diagram DNS-DetailedWhoisVM.pdf provides an
overview of the dotCapeTown TLD initial whois service implementation

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

Domain Name: example.capetown
Domain ID: DOM_1S2XW-CAPETOWN
WHOIS Server: whois.CAPETOWN
Referral URL: http:⁄⁄www.capetown⁄
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 CAPETOWN 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.CAPETOWNRAR.CAPETOWN

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

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*.capetown. 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 dotCapeTown 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.
dotCapeTown 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 dotCapeTown TLD will provide ASCII character set
data. This implies that where EPP contact addresses exist of both local
and international 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 dotCapeTown TLD development, deployment and operational responsi-
bilities for the above will be staffed by members of the ZA Central Registry.

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 mon-
itoring.

7 Bulk Access

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

1     Synopsis

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


2     Registration Life Cycle

2.1     Introductory Life Cycle







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


2.1.1    Sunrise

On introduction of dotCapeTown there will be a Sunrise period as defined
below. Applications for Trademark names will be accepted during the Sun-
rise period. The Sunrise phase will be administered by an external provider
as decided by the dotCapeTown 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 South African Reg-
     istered Trademark holders running a period estimated at 2 weeks to
     4 weeks, and to be ratified by the dotCapeTown policy oversight com-
     mittee with the latter period being used for examination and verifica-
     tion.

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

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 dot-
CapeTown policy oversight committee will be enforced on the introduction
of dotCapeTown.


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 dot-
    CapeTown 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 dotCapeTown 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 dotCapeTown
    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 dotCapeTown 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 dotCapeTown. The do-
main 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 to 4 weeks, and to be ratified by
the dotCapeTown policy oversight committee will begin on the launch of
dotCapeTown. 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 dotCapeTown policy oversight committee will apply. Domain
     names will be offered at a premium fee which will be reduced at se-
     lected intervals until the next Landrush phase begins.

Initiation:- Thereafter a secondary Landrush period estimated at 14 days,
      and to be ratified by the dotCapeTown 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 dotCapeTown
      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 dotCapeTown 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 dotCapeTown policy oversight committee
    during which the domain will remain in the dotCapeTown zone.

Pending Deletion:- A pending deletion period of estimated at 5 days, and
    to be ratified by the dotCapeTown policy oversight committee during
    which the domain will be removed from the dotCapeTown 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 dotCapeTown 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 dotCapeTown 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
dotCapeTownʹ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 dotCapeTown includes software for maintaining and con-
trolling dotCapeTown policy. The policy roles in 4.1 must have access to
the software and understand how the policy is implemented by the Registry.

1     Synopsis

This chapter provides details on the Abuse Prevention and Mitigation pro-
cedures 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 dotCapeTown TLD
on ratification by the dotCapeTown TLD policy committee and in accor-
dance 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 dotCapeTown TLD
name space immediately after delegation. The ZA Central Registry, in
consultation with the dotCapeTown 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 com-
       plaints 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 dotCapeTown domain name
will be drafted and approved by the dotCapeTown Policy Oversight Com-
mittee . 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 com-
plaints relating to registrants, accredited registrars and resellers in the dot-
CapeTown TLD domain name space.


2.2.2   Definitions Clause

In this part of the policy it would be imperative to define terms such as
complainant (a party who has lodged a complaint regarding a dotCapeTown
domain name or a service provided by an accredited registrar or reseller),
domain complainant ( make it subject to the clause that defines what com-
plaints 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 han-
dle complaints that fall exclusively within the dotCapeTown 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 con-
tractual sphere; internet access or email services which again falls outside
the registry function; 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 dotCapeTown published policies; mismanagement of the dotCapeTown
domain name space by an accredited registrar or domain name reseller,
breaches of the registrar agreement or any Codes of Conduct that may ex-
ist. Complaints that fall outside the competence of the Complaints Officer
must also be specifically mentioned. For example, that the Complaints Of-
ficer would not entertain complaints that relate to competing rights in a
domain name or any commercial disputes between registrars and resellers
and⁄or registrars⁄resellers and registrants. The dotCapeTown Policy Over-
sight 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 .capetown domain names, or to place any .capetown
     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 notification
and a reasonable opportunity to ensure that the domain details are complete
and accurate. Within the dotCapeTown gTLD context the dotCapeTown
Policy Oversight Committee will need to endorse this process or adapt it
for implementation in the dotCapeTown gTLD space.

4    Registrar Requirements

Notwithstanding the ICANN Registrar Agreement for accredited registrars
the proposed registrar accreditation agreement for the dotCapeTown TLD
will include the following measures to ensure compliance to address abuse
prevention, 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 dotCapeTown 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 Con-
          trol)
        d Transfer Reimbursements


5.1   Authentication and Notification Mechanisms

The dotCapeTown TLD Registry implementation will support password
based authentication for Contact and Domain Registry objects. These pass-
word based authentication mechanisms may bypass object locks (EPP client
Action Prohibited statuses) depending on usage. One-time passwords may

be utilized to issue emergency transfers or suspensions if deemed necessary
by the dotCapeTown Policy Oversight Committee .

The dotCapeTown TLD Registry implementation employs out-of-band noti-
fication 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 dotCapeTown Registry implementation may prohibit the use of Host
create⁄update commands, thus forcing the requester to create Host associa-
tions via the Domain create⁄update commands. The process ensures that a
host cannot be edited directly and glue cannot be adjusted without knowl-
edge of the superordinate domain. The Zone publication procedures will
not publish 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 will
be staffed by the ZA Central Regtistry.

1    Synopsis

This chapter provides details on the Rights Protection Mechanisms as pro-
posed for the dotCapeTown 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 inSouth Africa; 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 South Africa (such as city names, names of cultural
     sites or groups, etc). Names will be blocked if the names are offensive in
     the South African region. The South African Domain Name Authority
     (ZADNA) in partnership with the South African Governments will
     administer Pre-Sunrise.

   * Sunrise 1 provides priority for eligible owners of trademarks registered
     in South 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 Clear-
          inghouse; 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 REGIS-
    TRATION 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 re-
        quirements;
 4. provision of data conforming to the SUNRISE INFORMATION RE-
    QUIREMENTS 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 ELEC-
TRONIC FORMAT.

The form of the signed declaration will be as follows. I⁄We [name of appli-
cant] 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 ZAR 10000, and will fall by ZAR 2000 at the beginning of each
subsequent period (such as a week) until it reaches ZAR 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 ZAR 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 dotCapeTown Policy Oversight
Committee , 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 adminis-
tered 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 South Africa to apply to be appointed to the board of Examiners
in the present ICANN Dispute Resolution Bodies.


9    Resources:

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

1    Synopsis

This chapter provides a summary of the security policy for the proposed
dotCapeTown 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 above
mentioned key aspects as well as any other criteria identified by the man-
agement.


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:- dotCapeTown 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:

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.

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

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

New gTLD Application Submitted to ICANN by: UniForum SA (NPC) trading as ZA Central Registry

String: capetown

Originally Posted: 13 June 2012

Application ID: 1-1864-98622

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility

Applied-for gTLD string

13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

14(a). If an IDN, provide the A-label (beginning with "xn--").

14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.

14(c). If an IDN, provide the language of the label (in English).

14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).

14(d). If an IDN, provide the script of the label (in English).

14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).

14(e). If an IDN, list all code points contained in the U-label according to Unicode form.

15(a). If an IDN, Attach IDN Tables for the proposed registry.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.

15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.

16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).

Mission/Purpose

18(a). Describe the mission/purpose of your proposed gTLD.

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.