Application number: 1-2104-81541 for Ummah Digital Limited

Ummah Digital Limited

Kairaba Ave. (Next to QuantumNet building)
Serrekunda KSMD KSMD
GM

+220 995 2942

+220 995 2942

Mr. Katim Seringe Touray

CEO

+220 995 2942

kstouray@gmail.com

Mr. Salieu Taal

Lawyer

+220 391 6396

salieu.taal@gmail.com

Limited Liability Company

Gambia

Not Available

Not Applicable

Not Applicable

Katim Seringe Touray
Chairman⁄CEO
Subramanian Subbiah
Director

Salieu Taal
Shareholder

Katim Seringe Touray
CEO
New Enterprises Limited
Company⁄Shareholder

ummah

Not Available

There are no known operational or rendering problems concerning the applied-for gTLD string, it will meet all requirements in the AGB, namely, conformance with technical standards in RFC 1035 (Domain Names: Implementation and Specification), and RFC 2181 (Clarifications to the DNS Specification), and host name requirements specified in the technical standards DOD Internet Host Table Specification (RFC 952), Requirements for Internet Hosts — Application and Support (RFC 1123), and Application Techniques for Checking and Transformation of Names (RFC 3696), Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894) The applied for string is a Latin script, and has a length (5 characters) that is well within the bounds set by the Applicant Guidebook. Specifically, “ummah” is significantly less than the maximum 63 characters permitted, treats both upper and lower case as identical, and consists entirely of letters (alphabetical characters a-z).

A .ummah gTLD will help ICANN meets its important AoC commitment to ensure that the expansion of gTLDs has brings about competition, consumer trust and choice, as well will help mitigate risks involved in the program. In the first place, .ummah will provide the estimated 1.6 billion Muslims who form 20 percent of the world’s population with an identity hitherto unavailable on the Internet. The .ummah gTLD will finally provide Muslims and Islamic organizations a means to translate to the Internet, the Muslim identity that has been used since the birth of Islam about 1,400 years ago. Beyond that, .ummah will also provide a much-needed choice that will help them build their sense of community, and build bridges between the Islamic and non-Islamic world. Internet users will thus be able to find Islamic organizations, institutions, government agencies, businesses much easier with .ummah than without it. In the same vein, non-Islamic entities will find .ummah domain names an effective route to reaching their target audiences in the Islamic world.

The introduction of the .ummah gTLD will also introduce another important aspect of trust, and key AoC commitment in the new gTLD program, and that is the need for ICANN to reach out to developing countries. With only 49.4 million or less than 1 percent of the estimated 1.6 billion Muslims in the world are found in Europe and the Americas, with the rest being in many developing countries in Africa, Asia-Pacific, and the Middle East (http:⁄⁄pewforum.org⁄uploadedFiles⁄Topics⁄Religious_Affiliation⁄Muslim⁄FutureGlobalMuslimPopulation-WebPDF-Feb10.pdf). As such, a .ummah gTLD that will serve Muslims and Islamic organizations will certainly help increase ICANN’s profile in these countries, increase their trust in the organization, and help strengthen relations between ICANN and these countries.

Why Ummah Digital?
Ummah Digital Limited is a startup Gambian company created to apply for the .ummah gTLD and re-position the Islamic world to better participate in and exploit the emerging digital economy, and contribute to the progress of humanity at large. The company was co-founded by Dr. Katim S. Touray, an international development consultant and former ICANN Board member, along with investors from Singapore, and The Gambia.

Ummah Digital was co-founded by Dr. Touray the basis of experience he gained while on the ICANN board, and learning of the need for, and difficulties to get greater participation of developing countries in the Internet economy, and specifically the domain names industry. For this reason, Ummah Digital was incorporated in The Gambia, Dr. Touray’s home-country, and an African developing country with a majority-Muslim population that exists harmoniously with their non-Islamic fellow citizens. The country is also a member of the Organization of Islamic Cooperation, and classified by the UN (http:⁄⁄www.itu.int⁄ITU-D⁄ldc⁄who.htm) as a Least Developing Country (LDC).

The Gambia thus provides a model in building bridges between the Islamic and non-Islamic worlds, as the .ummah gTLD is aimed at being. In the same vein, the country is a developing country with significant technological and infrastructure challenges, and hence, devoid of a company that is a player in the domain names industry. Against, this background, Ummah Digital aims to become one of the first African companies to become a registry operator, through a partnership with investors from Singapore. This approach is especially welcome in the context of a new thinking in international development cooperation based on South-South partnership. For this reason, Ummah Digital is a model of partnership between emerging and developing economies. Although based in The Gambia, Ummah Digital will seek additional investors and partners from other countries, especially Islamic countries to provide better services to the global Islamic world.

.ummah gTLD will benefit registrants, Internet users, and others in various ways, namely:

a) Better value of domain names: The introduction of .ummah is expected to offer registrants a better value for their domain names. In the first place, registrants will become part of a well-defined global community, with very strong ties that bind. Secondly, a .ummah domain name will be much more attractive as a destination to Internet users, and hence, registrants can expect to gain increased traffic and better loyalty with a .ummah domain name, than other domain names. The resultant increase in traffic will undoubtedly help increase revenue for Web sites that are advertising based, and hence, the value of the sites.

b) Increase the domain-name extension inventory: In the top 22 countries with the greatest number of Muslim Internet users, the number of Muslim Internet users increased an average of about 276 percent between 2005, and 2010, according to data from the ITU. If this trend is to continue (and there is no reason to belief the upward increase wonʹt continue given the relatively low Internet penetration rates in many Islamic countries), it can be expected that the .ummah target market will increase, and hence, help expand the domain name extension inventory. This is especially so given that .ummah is flexible, and can be used for sites for purposes ranging from e-commerce, information dissemination, government agencies, as well as non-profit, businesses, and many others.

c) Increase online innovation: It is also expected that .ummah will increase online innovation by providing registrants with a new avenue for reaching Muslims and Islamic organizations, businesses. Presently, Muslims and Islamic organizations are reached via various TLDs ranging from ccTLDs to gTLDs, none of which can be specifically identified as being targeted at these groups of Internet users. With increasing interest in Islamic products and services, the need to provide accurate information, and reach out to Islamic communities, .ummah will be a welcome development. Toward this end, Ummah Digital will provide world class services to registrants and users of .ummah domains.

d) Increase access to online resources: The .ummah gTLD will also help increase, and ease access to online resources in a number of ways. First by providing domain names targeted at Muslims and Islamic organizations and entities, .ummah will make the Internet more attractive to many more people because they would be able to find information and services easier. On other other hand, .ummah will also make it easier for content providers to target Muslims and Islamic organizations, thus encouraging many them that would not have otherwise done so to provide online resources. It is expected that existing registrants will be able to extend their presence to that audience with new .ummah sites, and new registrants will come from the Muslim and Islamic organizations, adding even more value to the Internet.

e) Increased trust and confidence in Islamic content and online services: Another important benefit of .ummah is that it will help increase trust and confidence in Islamic content and online services. Ummah Digital will work with ICANN, its channel partners, as well as governments and the community to ensure that content and online services provided via .ummah domain names conform to Islamic values. For this reason, it is expected that .ummah will help build and increase the trust and confidence that Muslims and Islamic organizations have in the Internet and the services that are provided through it.

18(b)(i) What is the goal of your proposed TLD in terms of areas of specialty, service levels, of reputation?

Many of the gTLDs that will be introduced by ICANN will appeal only to narrow segments of the online population. To the extent that .ummah is aimed at a specific religious and psychoraphic segment of the online population, it is also similar to many of proposed new gTLDs. However, .ummah will stand out from the crowd in one main respect, and that is that it is targets the global Islamic community of of 1.6 billion Muslims, as well as Islamic organizations, businesses and government agencies around the world.

Ummah Digital is poised to work with partners around the world to promote .ummah, and provide quality services to registrants. In this regard, the company will work with registrars, resellers, and other partners to promote the .ummah gTLD, and increase the number of registrants using it. Given that about 60 percent of Muslim Internet users around the world are found in 10 countries, Ummah Digital will focus on developing strong partnerships in these countries, namely, Pakistan, Turkey, Nigeria, Egypt, Indonesia, Morocco, India, and Saudi Arabia.

Although Ummah Digital is a start up company, it is founded by people who are well-known in the community, and who are committed to ensuring that the Internet, and .ummah in particular, serve the interests of the global Internet community. Toward this end, Ummah Digital will build partnerships in various Islamic countries to not achieve a healthy uptake of the .ummah gTLD, but to also promote the responsible use of the Internet in its target countries and communities.

Ummah Digital will also support Internet development in the developing world, and work with ICANN, government agencies, and other partners to achieve this aim. Toward this end, Ummah Digital will use a part of its profits to fund activities and programs aimed at developing the use and growth of the Internet in developing countries. The company will form an international Advisory Panel to ensure the transparent and effective use of funds allocated to this purpose.

The Ummah Digital co-founders are well-known in the ICANN community both for their technical competence and dedication to ensuring that developing countries have a voice in the affairs of ICANN. In addition, we have significant links with government agencies, and other stakeholders in many developing countries and Islamic countries, thereby providing us a solid foundation on which to build the marketing and outreach efforts of Ummah Digital. We have a solid reputation which we intend to maintain as we roll out the .ummah gTLD.

18(b)(ii) What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?
Under the management of Ummah Digital, the .ummah gTLD will add to the current gTLD space with increasing competition, help consumers and Internet users more easily differentiate Islamic products, content, and services, and foster innovation on the Internet.

Competition: The .ummah gTLD will increase competition in almost all sectors of the gTLD space. Thus, registrars will compete to offer .ummah to strengthen their presence and profile in the Islamic world, and tap into hitherto the under-served, but potentially lucrative market. Similarly, .ummah will provide existing and new gTLDs with significant competition, given it is targeted to Muslim users, as well as Islamic organizations, government agencies and businesses. Furthermore, .ummah will be a strong competition because it will be a gTLD to help its registrants join a large global community of Muslims and Islamic organizations, something other gTLDs cannot offer.

The .ummah gTLD will also increase competition because it will help better define the online profile of providers of Islamic products and services such as Islamic finance and banking services. To the extent that many of the target countries are presently under-served by the domain name industry, Ummah Digital will help push the boundaries of the industry, and bring new players online, thereby benefiting Internet users around the world.

Differentiation: The .ummah gTLD also contribute immensely to the differentiation of the gTLD space. Presently, Muslims and Islamic organizations, government agencies, and parties interested in reaching them do not have a clearly defined way of reaching them. Similarly, Muslims and others interested in reaching resources and services targeted at the Islamic community have a hard time finding them because the domain names undifferentiated, and lumped with those providing products and services many of which might indeed be contrary to Islamic values. For this reason, .ummah will be a welcome development because it will help both Islamic content and service providers and Internet users to find each other.

Innovation: As stated above, the .ummah gTLD will help increase competition and differentiation in the gTLD space. A direct consequence of the efforts by the various sites seeking to differentiate themselves from others will be increased innovation. This need for innovation will be felt at many levels of the gTLD space ranging from registrars to registrants and end-users, as well as in various aspects of the services provided in the industry. By virtue of its focus on the Islamic world, Ummah Digital will, through the introduction of the .ummah gTLD, be in a unique position to help spur innovation in the gTLD space in Islamic countries, and the larger Muslim world.

18(b)(iii) What goals does your proposed TLD have in terms of user experience?
Ummah Digital will provide rewarding user experience to three of its main target markets: registrars, registrants, and Internet users.

a) Registrars: Ummah Digital will also provide registrars a positive user experience based on a responsive, customer-oriented service. Toward this end, Ummah Digital will work with CoCCA, its registry backend service provider, to ensure that registrars are provided timely and responsive service, as well as adequate marketing and promotional support to support their .ummah sales campaigns.

b) Registrants: Ummah Digital will work both with existing registrars seeking to enter the market of the Islamic world, and new registrars that might emerge from within the global Islamic community to deliver quality services to registrants around the world. Furthermore, Ummah Digital will encourage competition at the registrar level by providing assistance and encouragement with new registrars, especially those from developing countries and Islamic communities.

c) Internet users: The success of the .ummah gTLD will largely depend on the extent to which it can provide a positive user experience for Internet users. For this reason, Ummah Digital will work with ICANN, registrars, developers, governments, consumer protection agencies and organizations, as well as security experts and the global community to ensure that the .ummah gTLD is one of the safest and trusted gTLDs available.

18(b)(iv) Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.

As mentioned above, the primary goal of the .ummah gTLD is to help build a strong Isamic identity on the Internet, and build bridges between Islamic and non-Islamic worlds. Toward this end, Ummah Digital will require that the content of Web sites under the .ummah gTLD must be sensitive to Islamic values and norms, involve or abet criminal activity, and⁄or promote hatred or violence and terrorism in any form.

Ummah Digital recognizes that it cannot, and is not responsible for determining the faithfulness of registrants to Islam. However, registrants of .ummah domain names will be required to provide identification details, as detailed in the agreement they will need to sign before their domain names are registered.

Additionally, Ummah Digital requires that domain names within the .ummah gTLD should consist of proper characters unique within top-level domain, followed by the characters ‘.ummah’. Domain names shall meet the following technical requirements; they shall:
contain no more than 63 characters;
begin and end with a letter or a digit;
contain no characters different from letters, figures and a hyphen (allowable characters are the letters of the Roman alphabet; capital and lowercase letters do not differ);
contain no hyphens simultaneously in the third and forth positions.
contain no characters different from letters, figures and a hyphen (allowable characters are the letters of the Cyrillic alphabet including letter “ё”; capital and lowercase letters do not differ)

Ummah Digital will also enforce a name selection policy that ensures that all names registered in the gTLD will be in compliance with ICANN mandated technical standards. These include restrictions on 2 character names, tagged names, reserved names for Registry Operations. All names must also be in compliance with all applicable RFCs governing the composition of domain names. Registrations of Country, Geographical and Territory Names will only be allowed in compliance with the restrictions as outlined in the answer to Question 22.

18(b)(v) Will your proposed TLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

Ummah Digital will provide registrants and users with complete privacy that will also within the rules and procedures provided by ICANN.

The .ummah gTLD will be governed by strict guidelines and policies to ensure the privacy of information for registrants as well as users. The policies will be transparent and rigorous, and modeled after policies that have been successfully implemented by existing TLD operators. In addition, the policies will be supplemented by sound technologies that will prevent unauthorized access to information. This is a manifestation of the larger goal of the new gTLD, that of a trusted source of safe online transactions, as stipulated in 18(a).

Privacy and security will be key elements of the .ummah Acceptable Use Policy (AUP). The AUP will govern how a registrant may use its registered .ummah domain name, with a specific focus on protecting Internet users. Specifically, the AUP language will address privacy by prohibiting a registrant from using a domain for any activity that violates the privacy or publicity rights of another person or entity, or breaches any duty of confidentiality owed to any other person or entity.

The AUP also would prohibit spam or other unsolicited bulk email, or computer or network hacking or cracking, as well as the installation of any viruses, worms, bugs, Trojan horses or other code, files or programs designed to, or capable of, disrupting, damaging or limiting the functionality of any software or hardware.

Ummah Digital will maintain complete enforcement rights over the use of the domain name. Furthermore, Ummah Digital will reserve the right to revoke, suspend, terminate, cancel or otherwise modify the rights of registrants to the domain name(s) they have registered, should they breach the AUP.

Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

There is no doubt that the .ummah gTLD will benefit from the momentum generated by the introduction of the new gTLD program, given the global buzz that has been created. However, Ummah Digital recognizes that it has to embark on additional outreach and communications to ensure the successful launch, and sustainability of the .ummah gTLD. Toward this end, Ummah Digital will leverage various channels to ensure the widespread adoption of the .ummah gTLD.

The dot ummah gTLD will be actively promoted in 10 key target countries (Pakistan, Turkey, Nigeria, Egypt, Indonesia, Morocco, India, Saudi Arabia, Iran, and Malaysia) which account for about 65 percent of global Muslim Internet users. Ummah Digital will partner with trade organizations and associations, as well as media outlets, Web site owners, ISPs, Web developers, social networks, and international Islamic organizations to help promote the gTLD. Other important groups Ummah Digital will work with include registrars, and domain name re-sellers.

Ummah Digital will also participate as much as possible in meetings to actively promote the gTLD. It is also expected that over time, the use of the dot ummah gTLD by prominent individuals, organizations, and businesses will help promote it around the world. For this reason, Ummah Digital will provide select organizations with free domain names to encourage them to use the dot ummah gTLD. Examples of target organizations Ummah Digital will work with include the Organization of Islamic Cooperation (OIC-OCI), trade and industry associations such as the Islamic Chamber of Commerce and Industry (ICCI), the Federation of Consultants from Islamic Countries (FCIC), and the Council for Islamic Banks and Financial Institutions (CIBAFI), as well as non-governmental organizations, and their umbrella groups such as the Union of NGOs of the Islamic World (UNIW).

Dot ummah will be promoted as a desirable gTLD because it will help owners have an identity, and a sense of belonging to a large global community. Furthermore, the fact that Ummah Digital will donate some of its profits to the development of the Internet in developing countries will provide additional promotion for dot ummah.

Finally, the growth of the .ummah gTLD will be driven by a network effect, which occurs when a service becomes more popular as more users adopt it. As more sites offer information, services, and opportunities for interconnection using .ummah domain names, more members of the community will navigate to those sites. Many of those will provide their own content, and their activity there will spark further growth of second-level .ummah domains. At some point, information and service providers will see the demand for .ummah content and migrate their offerings to .ummah, thereby further increasing offerings to the community, and driving even more traffic to .ummah sites. The future benefits of interlinking this global community of Muslims and Islamic organizations are incalculable, but huge.

18(c) What operating rules will you adopt to minimize social costs (e.g., time or financial resources costs, as well as various types of consumer vulnerabilities? What other steps will you take to minimize negative consequences⁄costs imposed upon consumers?
Ummah Digital does not anticipate any social cost to registering a .ummah domain name. On the contrary, having a .ummah domain name will provide social benefits to both the domain name owners, the global Islamic Ummah, and the global Internet community at large for reasons already outlined above in 18(b)(ii) and 18(b)(iii) above.

18(c)(i) How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?
Ummah Digital is yet to finalize the details of the approach it will take to resolve the multiple applications for the same domain name. However, the company will use techniques and policies that have been used successfully in the past, with the exception that auctions will not be an option, given that the practice is not acceptable in the Islamic world. Whatever are the specifics of the approach that will be taken, it will be broadly based on the need to provide equitable, transparent, and efficient means of settling these disputes, conform to ICANN policies and objectives, and better serve the global Internet community.

18(c)(ii) Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts). 
Ummah Digital will, as a company serving Muslims and Islamic organizations, as well as entities interested in reaching them, uphold Islamic values in its transactions. For this reason, the .ummah domain names will not be auctioned, since the practice is not-Isamic. Instead, the company will work with the community and various stakeholders to develop a pricing system that will ensure that consumers are offered competitive prices that would also ensure a sufficient revenue stream to ensure that the company and the .ummah gTLD is sustainable over the long term. In addition, Ummah Digital will have a pricing regime that will accommodate disparities in income levels around the various regions by, for example (but not limited to) having different prices for applicants from developing or industrialized economies, as well as for non-profit, and for-profit applicants.

18(c)(iii) Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.
Ummah Digital intends to price its domains competitively to maximize sales, but at the same time ensure that it is a profitable and sustainable concern. Although no specific policies in this regard have been developed, we intend to provide our target market stellar service, and competitive pricing, and will work with ICANN, our channel partners and other stakeholders to achieve a widespread adoption of the .ummah gTLD.

No

Not Available

No

Protection of Geographic Names
Ummah Digital has chosen CoCCA Registry Services (NZ) Limited (CoCCA) as their registry services provider. CoCCA has over 12 years of experience in authoring registry software and providing registry support services. With 35 national TLDs relying on CoCCA’s technology to manage critical infrastructure, the CoCCA EPP Shared Registry System (SRS) is the most widely deployed, field-tested SRS in use today. In many respects new niche market gTLDs are predicted to more closely resemble existing ccTLD name spaces than the current gTLD ones. CoCCAʹs commercial model and technology enables TLD Sponsoring Organizations to focus on operating the front end portion of the registry including sales, marketing and community relations while leaving the operational aspects to the proven team at CoCCA.

In addition to technology CoCCA has a considered and tested set of leading – practice policies designed to address security, stability, rights protection, abuse mitigation, privacy and other issues, CoCCA is a trusted partner for Ummah Digital to operate the .ummah gTLD in a manner that is fully compliant with all ICANN rules and regulations.

CoCCA, on behalf of the Ummah Digital, intends to implement the following measures to protect geographical names at the second and at all other levels within the TLD:

Reservation Measures for Geographical Names
Ummah Digital will adhere to Specification 5 of the proposed Registry Agreement, “Schedule of Reserved Names at the Second Level in gTLD Registries” ⁄ section 5 titled “Country and Territory Names.” The geographic names listed in the following internationally approved documents will be reserved at the second level within the TLD and at all other levels where registrations occur:
(1.i.1) the short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 
(1.i.2) the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
(1.i.3) the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

Potential Release of Geographical Names
Ummah Digital is committed to working with governments and other stakeholders that may have a concern regarding the registration of names with national or geographic significance at the second level. If Ummah Digital decides to release reserved geographical names, Ummah Digital will abide by the process outlined in Specification 5 of the Registry Agreement by seeking agreement from the applicable government(s). Ummah Digital understands that any release of the geographical names may be subject to Governmental Advisory Committee review and approval by ICANN.

Review, Audit, and Updates to Policies
Policy management is dynamic in nature requiring continual management. Ummah Digital, in conjunction with CoCCA’s assistance, will be engaged in policy development efforts in general and with respect to protections of geographical domain names. Ummah Digital will review and consider suggestions or concerns from government, public authorities or IGOʹs regarding this policy. And as with all required policies, Ummah Digital will perform openly and transparent should updates to existing policy or the creation of new policy be required. Further, Ummah Digitalʹs internal processes will continually review and manage its reserve lists as one part of the abuse prevention mechanisms described in greater detail within question 28, “Abuse Prevention and Mitigation.”

UMMAH DIGITAL LIMITED (“UMMAH DIGITAL”) has contracted CoCCA Registry Services (NZ) Limited (ʺCoCCAʺ) to provide hosted Registry Services for the .UMMAH TLD. The .UMMAH TLD will be added to CoCCAʹs existing production Shared Registry System (ʺSRSʺ). CoCCA will ensure redundant geographically diverse DNS resolution through propagation of the .UMMAH zones on the Internet Software Consortium (ʺISCʺ), Packet Clearing House (ʺPCHʺ) anycast networks - and on CoCCA unicast servers.

CoCCA authors the internetʹs most widely used SRS registry system (which has been branded ʺpamojaʺ for gTLD name spaces) ISC authors BIND and pioneered anycast technology, PCH has one of the internetʹs largest and longest running anycast networks. DNSSEC key storage and signature will take place on the PCH DNSSEC platform, a platform developed for cccTLDʹs that mirrors the security and processes used by ICANN to secure the root.

The .UMMAH SRS data will be escrowed with both NCC Group and CoCCA subsidiary CoCCA Data Escrow Services (NZ) Limited. 

23.1 About CoCCA
CoCCA has over nine years experience authoring open source registry software systems and providing TLD registry support services. CoCCA was originally incorporated in Australia in 2003 as CoCCA Registry Services Limited, in January 2009 CoCCA re-located to New Zealand and trades as CoCCA Registry Services (NZ) Limited. CoCCA is a privately held NZ company.

CoCCAʹs existing clients are governments and other managers of county code top level domains (ccTLDs). As of 31 March 2012, 33 national ccTLDs have selected CoCCAʹs SRS technology and⁄or services to help them manage their critical infrastructure. Several additional ccTLDs have committed to migrate to CoCCAʹs ʺpamojaʺ SRS in 2012 (pending the outcome of re-delegations). As many as 40 ccTLDs are thought to be using the pamoja SRS application, while CoCCA has formal relationships and support contracts with 33 TLDs, the exact number of users is hard to determine as the pamoja software is freely available for download from the internet. CoCCAʹs offers ccTLDs a perpetual royalty-free license to use and deploy the SRS software.

CoCCAʹs commercial model is based on delivering significant economies of scale to TLD managers, CoCCAʹs dominant market position in the ccTLD ecosystem - where the TLD string is generally considered critical infrastructure, ensures CoCCAʹs commercial viability and ongoing funding of R&D regardless of the success of a particular gTLD string (or group of gTLD strings) that select CoCCA as the Registry Services provider. CoCCAʹs technology is mature, field tested and their commercial model is solid and not dependent on new gTLDʹs.

The pamoja SRS can be used several ways, the application can be downloaded and installed locally by a TLD Sponsoring Organization (ʺSOʺ), or the SO can contract CoCCA to host either the primary or failover SRS at the CoCCA Network Operations Centre (ʺNOCʺ).

CoCCAʹs pamoja SRS is a freely available gTLD-compliant TLD database application based on the ʺCoCCA Toolsʺ open source ccTLD EPP registry system. The SRS licensing simplifies failover and transition planning as the source, data, and daily virtual machine images are to be placed into escrow enabling them to be migrated or re-deployed by a different entity without any SRS licensing issues. CoCCAʹs SRS is a ʹshrink-wrappedʺ application that can be installed on a single server in minutes or deployed in a High Availability (HA) configuration.

CoCCAʹs pamoja SRS is the most widely deployed, field-tested SRS in use today. CoCCAʹs SRS is a mature product that has grown organically over the past decade as new standards have been developed and published. It is doubtful any other Registry Services provider has accumulated CoCCAʹs level of experience operating multiple small to medium sized TLDs efficiently and securely. 

CoCCAʹs pamoja SRS is currently used to run three (3) Arabic (IDN) TLDs and was selected by the Telecommunications Regulatory Authority in Egypt to launch the Internetʹs first IDN TLD (.masr) in 2010. The flexible package supports ASCII and IDN - including variants and folding where required. 

23.2 Current pamoja SRS deployments
Key - | [P] CoCCA Operated Primary SRS |[F] CoCCA Failover SRS | [E] Escrow | [S] Software Only

.af | Afghanistan | Ministry of Communications and IT | [P] [F] [E]
.bi | Burundi | Centre National de lʹInformatique | [F] [E] [S]
.bw | Botswana | Botswana Telecoms Authority | [S] [F] [E]
.cm | Cameroon | Cameroon Telecommunications (CAMTEL)| [S]
.cx | Christmas Is. | Christmas Island Internet Administration Limited | [P] [F] [E]
.ec | Ecuador | NIC.EC (NICEC) S.A. | [S]
.eg | Egypt | Egyptian Universities Network (EUN) | [S]
xn--wgbh1c | Egypt IDN | National Telecommunication Regulatory Authority | [S]
.ge | Guernsey | Island Networks Ltd. | [S]
.gl | Greenland | TELE Greenland A⁄S | [S]
.gs | S. Georgia | Government of South Georgia | [P] [F] [E]
.gy | Guyana | University of Guyana | [P] [F] [E]
.ht | Haiti | Consortium FDS⁄RDDH | [P] [F] [E]
.hn | Honduras | Red de Desarrollo Sostenible Honduras* | [P] [F] [E]
.iq | Iraq | Communications Media Commission* | [S] [F] [E]
.je | Jersey | Island Networks (Jersey) Ltd. | [S]
.ki | Kiribati | Ministry of Communications | [P] [F] [E]
.ke | Kenya | Kenya Network Information Center (KeNIC) | [S]
.mg | Madagascar | NIC-MG (Network Information Center Madagascar) | [F] [E] [S]
.mu | Mauritius | Internet Direct Ltd | [P] [F] [E]
.ms | Montserrat | MNI Networks Ltd | [F] [E] [S]
.mz | Mozambique | Centro de Informatica de Universidade | [F] [E] [S]
.na | Namibia | Namibian Network Information Center | [F] [S]
.ng | Nigeria |Nigeria Internet Registration Association | [F] [E] [S]
.nf | Norfolk Is. | Norfolk Island Data Services | [P] [F] [E]
.pe | Peru | Red Cientifica Peruana | [S]
.sb | Solomon Is. | Solomon Telekom Company Limited | [P] [F] [E]
.sy | Syria | National Agency for Network Services | [S]
xn--ogbpf8fl ⁄ xn--mgbtf8fl | Syria IDN | National Agency for Network Services | [S]
.tl | Timor-Leste | Ministry of Infrastructure | [P] [F] [E]
.ps | Palestine | Ministry Of Telecommunications | [S]
xn--ygbi2ammx | Palestine IDN | Ministry Of Telecommunications
[S] .zm | Zambia | ZAMNET Communication Systems Ltd. | [F] [E] [S]

* Currently in the process of migrating away from Neustar (.iq) and Afflias (.hn)

23.3 CoCCAʹs Hosted SRS
UMMAH DIGITAL has confirmed with CoCCA their production experience and the availability of the Registry Services described briefly in sections 23.4-23.18 below - and in greater detail in the responses to questions 24-43. UMMAH DIGITAL and CoCCA understand elements of ICANNʹs TLD requirements will most likely be modified in the future. CoCCAʹs Registry Services will comply with future ICANN requirements or mandates.

23.4 Receipt of Data via the SRS EPP interface
Data from Registrars concerning the insertion and maintenance of records in the SRS may be processed either via the CoCCA EPP interface (XML over SSL on port 700) or manually via CoCCAʹs port 443 SSL web interface. CoCCA was an early adopter of the EPP standard and has operated an EPP based SRS for almost seven years.

The .UMMAH TLD will be added to CoCCAʹs existing production SRS, which currently has 203 registrars connected. CoCCAʹs SRS has a single EPP interface for all hosted TLDs allowing registrars to share the same contact and host objects across multiple TLDS. The .UMMAH TLD will only be made accessible to ICANN accredited registrars, many of which are currently connected to CoCCA for ccTLDs and using the EPP and GUI interface that the .UMMAH TLD will be accessed via when launched.

CoCCAʹs pamoja EPP interface currently complies the IETF RFCʹs required by ICANN (5730-5734 and 3735) and is explained in more detail in the response to Question 25.

23.5 Receipt of Data via the SRS Graphical User Interface (ʺGUIʺ)

Registrars may insert and manage domain, contact and host records as well as the SRS accounting functions via a port 443 GUI. Registrars do not have to use the EPP interface on port 700. Records managed via the GUI connect to the SRS EPP engine on port 700 via background processes; this ensures rigorous conformity with the RFCʹs and consistency in auditing and maintenance of historical records.

23.6 Registrar Data Restrictions (Reserved Names)

Restrictions on what domains may be inserted and maintained by registrars is to be controlled by configuration of java regular expressions. In order to comply with the requirements set out in Specification 5 and any UMMAH DIGITAL policy, the .UMMAH TLD will use three of pamojaʹs features as described below.

23.6.1 Prohibited Patterns. Domains that match patterns will be rejected with an EPP 2306 - Parameter Value Policy error, letting the registrar know that these domain names do not fit in with the registry policy for this zone.

23.6.2 Syntax Patterns. Certain strings, such as all-numeric names or single character names may be restricted. An EPP 2005 error - ʺParameter Value Syntax errorʺ will be returned to the EPP client, indicating that the name is invalid.

23.6.3 Approval Patterns. Names that match these patterns will not be rejected, but will be registered pending approval. Until they are approved, the name will not appear in the .UMMAH zone files, and will not be able to be transferred, renewed or modified in any way by the registrar.

23.6.4 Both ASCII and non-ASCII contact details can stored and displayed via web-based WHOIS and command line WHOIS.

23.7 SRS GUI, Role-Based Access
The pamoja SRS GUI has numerous role-based logins described below. Several of these have been recently developed by CoCCA in response to ICANNʹs proposed gTLD requirements and are currently being used numerous ccTLD production environments.

Administrative Roles

* SRS Systems Administrator - Able to administer and configure the entire SRS system
* CERT ⁄ Law Enforcement - Able to view and query the SRS, but not alter records. 
* TLD Administrator - Able to administer a TLD or group of TLDs
* TLD Viewer - Able to view but not alter records for a TLD or group of TLDs
* Zone Administrator - Able to administer a Stub Zone, or group of Stub Zones
* Zone Viewer - Able to view but not alter a Stub Zone, or group of Stub Zones
* Customer Service - Can perform tasks on behalf of a number of registrars
* Name Approver - Can approve names matching the Zone Approval Patterns
* CHIP Approver - Can approve domains registered with CHIP codes or other Trademarks.

Registrar Roles

* Registrar Master Account - Able to perform all registrar functions and create subordinate logins
* Registrar Technical - Able to modify domain details
* Registrar Helpdesk - Able to view domains and make various minor changes
* Registrar Finance - Able to view domains financial transactions and also edit financial data
* Registrar Finance - (Read Only) Same as above but view only.

Other Access Roles

* Premium WHOIS - Able to perform various queries in a SRS GUI and extract and save data to a CSV, also able to connect via the SRS EPP API for read-only query.
* Zone File Only - Able to login and request Zone Files

23.8 Zone File Dissemination ⁄ Resolution 

The .UMMAH will resolved by propagation of zone file data periodically extracted from the SRS, sent to PCH DNSSEC signing servers for signature, returned to CoCCA and then distributed by CoCCAʹs hidden master server to two redundant and independent anycast networks operated by Internet Software Consortium (ʺISCʺ | http:⁄⁄isc.org) and Packet Clearing House (ʺPCHʺ | http:⁄⁄pch.net) - as well as two public unicast TLD servers operated by CoCCA. 

The .UMMAH will be resolved by a minimum of 80 geographically distributed resolvers, all of which run ISCʹs BIND and are configured such that they comply with relevant RFCʹs including 1034,1035, 1982, 2181, 2182, 2671, 3266, 3596, 3597, 3901, 4343 and 4472. 

The PCH and ISC name servers employ IP-anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and give excellent (fast) responses to geographically diverse Internet users. DNSSEC and IPv6 are already fully integrated into the PCH and ISC networks. 

Registrars will able to continuously inspect the availability and status of each TLD server instance via the SRS GUI and other CoCCA WEB Sites. Should a TLD server be unreachable registrars are to be automatically notified (via email) and EPP polling messages. More detailed information is available in the responses to Questions 24-43. 

23.9 Dissemination of Domain Related Information

The SRS public WHOIS server will answer for the .UMMAH TLD on port 43 in accordance with RFC 3912 and the requirements set out Specification Four (4), 1.1-1.7 and Specification Ten (10), Section 4.

The CoCCA SRS features a public port 443, web-based RDDS interface that enables internet users to query and extract information which is at a minimum identical to that which is provided via the port 43 server but using technology that may be more convenient or accessible to many internet users than a port 43 command line query.

The CoCCA SRS also allows any Internet user (or any user with a login to the SRS) to order a complete Historical Abstract delivered in an easy to understand pdf format. 

Individuals may optionally subscribe to CoCCAʹs Premium WHOIS service, which provides them with:

* secure access to the SRS (via both a web-based port 443 GUI and read only EPP on port 700). 
* the ability to perform a variety of boolean queries online in real-time and save the output to a CSV
* the ability to create ʺinterest listsʺ using java regular expressions where they receive EPP polling messages and emails if a domain is registered that contains a string of interest to them.

Established CERTʹs and law enforcement agencies may request, and will generally be granted, read only GUI and EPP access to the CoCCA SRS free of charge. Currently this access is granted to the Australian Government CERT, who under an MOU may share information with other CERTʹs and national and international law enforcement agencies.

23.10 DNS Security Extension (DNSSEC)

CoCCAʹs SRS DNSSEC implementation allows registrars to provision public key material via EPP and the GUI. Under an agreement between CoCCA and PCH, .UMMAH TLD Keys are to be stored offline and signed using PCHʹs DNSSEC platform that replicates the security process, mechanisms and standards employed by ICANN in securing the ROOT of the DNS. 

The CoCCA-PCH key storage implementation deviates from the ICANN model only by diversifying the locations of the secure sites such that two (2) of the three (3) sites are outside the United States. The Singapore facility is hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA). The Swiss facility is hosted in Zurich by SWITCH, the Swiss national research and education network. The U.S. facility is hosted by PCH Equinix in San Jose.

The CoCCA SRS DNSSEC implementation complies with RFCʹs 4033, 4034, 4035, 5910, 4509, 4641 and 5155. Additional information on the DNSSEC implementation is available in the response to question 43.

23.11 Escrow Deposits

CoCCAʹs Registry Services include deposit of escrow data in the format and following the protocols set out in Specification Two. CoCCA currently deposits ccTLD data daily (in both the native CoCCA format and the draft arias-noguchi format) with both NCC group and CoCCA Data Escrow (NZ) Limited. CoCCA Data Escrow (NZ) Limited is a subsidiary and was established in 2009 to provide Failover Registry and escrow services to users of the CoCCA SRS who run the software locally on their own infrastructure. 

As part of CoCCAʹs Registry Services and to ensure continuity of operations, CoCCA deposits all updates to the pamoja SRS source code with NCC, and daily VMware images of the production SRS with CoCCA Data Escrow Services (NZ) Limited. These same practices will be adopted for the .UMMAH TLD when launched. 

.UMMAH SRS data will be deposited with NCC Group, CoCCA Data Escrow and ICANN. Additional information on Escrow is available the response to question 38.

23.12 Document Management
CoCCAʹs Registry Services include maintenance of documents related to intellectual property rights, complaints, identification of contacts, court orders etc. These documents are maintained in the SRS and become part of a domainʹs (or contacts) permanent history.

23.13 Support for Various Zone States

CoCCAʹs Registry Services support Sunrise, Rolling Sunrise, Land-rush and Open Registrations for a given zone. Each ʺStateʺ can be configured to match common policy options.

23.14 Accounting

CoCCAʹs Registry Serviceʹs includes a variety of standardized and add-hoc reports accessible to TLD administrators via the GUI. Standardized reports include one that complies with the requirements set out in Specification Three ʺFormat and Content for Registry Operator Monthly Reportingʺ. 

23.15 Audit Trail 

All SRS activity is logged and permanently archived, and can be easily retrieved via the GUI for law enforcement or complaint resolution. A ʺtime-machineʺ feature allows a user with appropriate rights to view the domain information as it existed on any given date and time. Information is never purged from the SRS, information on deleted domains, hosts, contacts can be easily extracted. 

23.16 Monitoring
CoCCAʹs Registry Serviceʹs include statistics on and real-time monitoring of the primary NOC, CoCCAʹs DNS Servers, Escrow NOC (NZ) and failover NOC in Palo Alto California. Additional information is available in the answers to questions 24-42. Monitoring of the ISC and PCH anycast networks is done internally by those entities, with statistics and notices made available to CoCCA in near-real time. Where applicable and relevant monitoring information is made available to registrars by CoCCA via the SRS.

23.17 Maintenance of Failover Facilities 

CoCCA Registry Services include maintenance of their geographically dispersed Escrow and Failover SRS facilities ( Auckland and Palo Alto, a third is planned for Paris in early 2013).

23.18 Complaint Resolution Service (CRS)

CoCCAʹs Registry Services include operating a ʺsingle deskʺ CRS to help resolve complaints, trigger Critical Issue Suspensions (ʺCISʺ) and enforce a Uniform Rapid Suspension (ʺURSʺ) request. UMMAH DIGITAL will bind all registrants in the .UMMAH TLD to the CoCCA CRS, Acceptable Use Policy and Privacy and RDDS Policy via the .UMMAH Registrant Agreement (ʺRAʺ). CoCCAʹs front-line CRS services are a ʺroleʺ performed by CoCCAʹs 24⁄7⁄365 NOC Support.

23.19 Registrar Support

CoCCA Registry Services provides registrars with 24⁄7⁄365 support via email and their virtual manned Network Operations Center (NOC). The CoCCA NOC Support has staff in Auckland, Sydney, Jonestown (Guyana) and Paris for around the clock coverage. CoCCA NOC Support all have access to the same cloud hosted monitoring and customer service applications as well as the SRS.

23.20 Security and Stability Audit

The pamoja SRS application is used to mange critical TLD infrastructure, each release is tested prior to release or deployment by CoCCA developers, developers and systems administrators at registries that deploy the application locally. Each major release is tested and audited by Yonita (http:⁄⁄yonita.com⁄).

CoCCA constantly reviews its SRS software and sites to ensure they meet or exceed best practices in the industry. Regular external audits of the security policy and CoCCA NOC are planned commencing 2013. The CoCCA NOC and failover facilities will be independently tested twice a year to ensure compliance with the CoCCA security policy, where applicable recommendations included in a security audit will be swiftly implemented. 

23.21 Operational Testing and Evaluation (OT&E) Environment

CoCCAʹs Registry Serviceʹs include the operation of an OT&E SRS that enables registrars to evaluate new versions and features of the SRS software before they are deployed by CoCCA in production. Any ICANN accredited registrar will be granted access to OT&E. Registrars not currently connected to the CoCCA SRS will be required by CoCCA to demonstrate competency in EPP and the .UMMAH policies before being granted EPP or GUI access to CoCCAʹs production SRS.

23.22 Authorization Key Retrieval
CoCCAʹs Registry Serviceʹs include automated public retrieval of domain AuthCodes by the administrative contact via a port 443 web page. The Authorization Key facilitates expedited transfers from one registrar to another.

23.23 Public Drop - List
CoCCAʹs Registry Services include publication of drop-lists of domains that are pending purge via a port 443 web page and email reports to registrars.

23.24 Wildcard Brand Registrations
A mechanism thought to be unique to the CoCCA SRS that allows blocking registration of a domainʹs ʺvariantsʺ using java regular expressions. This requires approval and manual intervention on the part of CoCCA. 

23.25 Co-operation with Law Enforcement and CERTs
CoCCA works with Law Enforcement, CERTs and researchers and will generally grant registry continuous access free of charge to facilitate two-way data exchanges aimed at preventing and mitigating abuse in the DNS. 

There are no known security or stability issues with the CoCCAʹs SRS, PCHʹs DNSSEC platform or ISCʹs and PCHʹs anycast networks at this time. Should any be identified resources are available internally at CoCCA, PCH and ISC to swiftly address and resolve security or stability issues as they arise.

24 Technical and Operational Capability

The .UMMAH TLD will be added to CoCCAʹs existing SRS, which currently has its primary Network Operations Centre (NOC) in Sydney Australia. The Sydney primary SRS is a single SRS instance currently hosting a dozen ccTLDs. CoCCAʹs Sydney SRS runs the latest versions of their ʺpamojaʺ TLD software application in a High Availability (HA) configuration. The Sydney SRS registry that will host .UMMAH currently complies with the requirements Specifications 4, 6 and 10 and will be scaled or modified to meet SLA requirements or any future ICANN gTLD specifications. Because of CoCCAʹs commercial model and technology the primary SRS can be moved from one data center to another with only a few minutes outage.

From an Internet users perspective trusted, secure and responsive DNS implementations are the ultimate ʺend-gameʺ or objective of UMMAH DIGITAL. To ensure this CoCCA will use PCHʹs DNSSEC and anycast infrastructure for offline storage, signing and resolving the .UMMAH TLD, additional DNS resolution will be provided by the ISC SNS anycast platform and two CoCCA unicast DNS servers. Additional information and technical details on the DNSSEC and anycast DNS services can be found in the answers to questions 34, 35 and 43.

24.1 Scale of Operations
A decade of operational experience with TLDs that have implemented polices to discourage tasting or otherwise incentivize add-drop registrations confirms the widely held belief that SRS registry databases are largely static. Once registered, data associated with a domain is not frequently modified. More than 99% of the queries seen by CoCCA on a daily basis are WHOIS, EPP Domain:Info or Domain:Check queries (read queries) and do not tax a SRSʹs resources excessively. Direct experience and anecdotal evidence from other small and mid-sized registries suggest that between 2% and 5% of the records in the register change daily through db ʺwriteʺ operations - new registrations, renewals, name server changes, contact updates automated changes of status, transfers etc.

For a theoretical registry of 1 million domains this equates to roughly 50,000 ʺwriteʺ transactions a day - or an average of 35 a min (50,000 ⁄ 1440 min⁄day ). A recent test of CoCCAʹs SRS software on an single 8GB cloud server revealed that the pamoja software was able to process 4 million unique EPP registrations in a little over 5 hours. Performance tests can be designed in any number of ways, real world performance depends on a variety of factors- the specific policy and account settings for a given zone.

In terms of both transactional capability and storage, todays ʺoff the rackʺ hardware and the open source PostgreSQL database used by CoCCA can easily cope with demands that a small to medium sized registry is ever likely to make on an SRS system. While the CoCCA SRS EPP and WHOIS infrastructure and platform may seem comparatively modest, a decade of experience confirms it is more than capable of meeting the ICANNʹs gTLD SLA requirements and comply with the required RFCʹs.

If future demands require it, CoCCAʹs SRS can easily (and affordably) be scaled by adding additional load balanced application servers and bandwidth.

24.1 SRS | High Level Description

Comprehensive information on and descriptions of the CoCCA SRS and NOC may be found the answers to questions 25-42 that follow.

24.1.1 SRS Infrastructure ⁄ Architecture
The following describes the key features of CoCCAʺs current production SRS that will be utilized for .UMMAH.

* Primary SRS is operated from Global Switch, a tier 3 + facility and one of the largest carrier-neutral data centers in the Southern Hemisphere.
http:⁄⁄www.globalswitch.com⁄en⁄locations⁄sydney-data-center

* Redundant links to the Internet through PIPE networks and Telstra
http:⁄⁄www.pipenetworks.com⁄
http:⁄⁄www.telstra.com.au⁄

* DNSSEC Key storage (offline) in Singapore at a PCH facility hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA). Failover storage at a facility is hosted in Zurich by SWITCH, the Swiss national research and education network and in the U.S. at a facility is hosted by Equinix in San Jose.

* .UMMAH zones signed by PCH in Frankfurt or Palo Alto 

* SRS Escrow at tier three co-location facility (Maxnet ) in Auckland NZ and Failover a tier four facility (Equnix) supported by PCH in Palo Alto, CA US. A fourth SRS ʺinstanceʺ is planned for Paris in early 2013.

* Dedicated, routable CoCCA Critical Infrastructure IPv4 and IPv6 address blocks.

IPv4 resources: 203.119.84.0⁄24 (crit-infra)
IPv6 resources: 2001:dd8:3::⁄48 (crit-infra) 

* Routers, Firewalls, Switches and Load balancers all configured for failover.

* CoCCAʺs pamoja SRS application load balanced and configured for failover.

* PostgesSQL 9.1.3 database replicated synchronously to two secondary DB servers.

* DS Keys lodged by registrars via EPP or the CoCCA SRS GUI

* Servers Virtualized (VMware vsphere v5)

* VM image-based replication for high availability and off-site disaster recovery http:⁄⁄www.veeam.com⁄vmware-esx-backup.html

* Critical Data continuously replicated asynchronously to two off-site SRS instances - PCH, Equinix Palo Alto CA (pch.net) and CoCCA Data Escrow (NZ) Limited, Auckland NZ (maxnet.co.nz)

* OT&E Environment for Registrars

* Primary and Secondary hidden master DNS ( failover masters )

* CoCCA operated unicast DNS in Sydney Australia and Auckland New Zealand.

* Two anycast solutions operated by PCH and ISC - over 80 DNS nodes.

24.1.2 Specification 6, Section 1.2 Compliance.

The .UMMAH TLD will be added to CoCCAʺs production SRS that currently hosts 12 ccTLDs under a single RFC 5730-5743, RFC 5910 and 3915 compliant EPP interface.

A list of the Registrars that currently connect to the CoCCA SRS for one or more ccTLDs follows bellow.

24.2 EPP Interface

The port 700 EPP interface for .UMMAH will listen on the same IP and port as the EPP server for the other TLDs hosted by CoCCA - currently ʺproduction.coccaregistry.net:700ʺ, on launch the production EPP interface for .UMMAH will be branded as epp.nic.UMMAH

24.3 WHOIS Interface (port 43 and 443)

The WHOIS Interface(s) for .UMMAH will listen on the same IP and port as the WHOIS server for the ccTLDs and prospective gTLDs to be hosted by CoCCA - currently ʺwhois.coccaregistry.net:43⁄443ʺ on launch the interface for .UMMAH will be branded as ʺwhois.nic.UMMAHʺ. Each TLD (ccTLD⁄gTLD) in the CoCCA SRS may have different WHOIS disclosure settings based on the TLD policy. The .UMMAH will comply with the ICANN gTLD disclosure requirements.

24.4 GUI Interface (port 443)

The GUI Interface for .UMMAH will listen on the same IP and port as the GUI server for ccTLDs and prospective gTLDs to be hosted by CoCCA - currently ʺhttps:⁄⁄production.coccaregistry.net:443ʺ on launch the interface for .UMMAH will be branded as ʺregistry.nic.UMMAHʺ.

24.5 Hidden Master DNS (s) (port 53)

The there are two hidden master servers. CoCCA will transfer the .UMMAH zone from the ʺsignature masterʺ to PCH for DNSSEC signature using TSIG IXFR ⁄ AXFR and IP restrictions at the OS and firewall level. PCH will sign the Zone and transfers it back to CoCCA using TSIG and IXFER⁄ AXFER, CoCCA will then loads the zone on a second ʺdistribution masterʺ which allows distribution to the PCH and ISC anycast transfer points and the CoCCA unicast DNS servers.

24.6 CoCCA Public Unicast DNS
DNS servers on virtual machines running BIND in the Sydney NOC and NZ SRS will pull and resolve the .UMMAH TLD zones.

24.7 Public anycast DNS

CoCCAʹs distribution master notifies the anycast providers (PCH and ISC) and .UMMAH TLD zones are transferred to the respective providerʹs transfer point IPs (hidden IPS for DNS transfers only) using TSIG IXFER ⁄ AXFR and then propagated by PCH and ISC across their respective anycast networks.

24.8 ftp Server
Server to distribute zone files as per third party access as required under Specification 4 Section 2.

24.9 Escrow Server
Server used to deposit TLD data with NCC and transfer data to CoCCAʺs Failover and Escrow SRS. Uses Secondary IP range.

24.10 Number of Servers 
There are seven physical server appliances in Sydney NOC configured such that they host 17 virtual machines.

24.11 High Availability (HA) Configuration

The Sydney NOCʹs network appliances are configured for failover and HA in either hot or warm standby mode. The PostgreSQL databases are locally replicated using 9.1.3ʹs synchronous replication and asynchronously over the WAN to the Failover facilities. The status of the local and off-site replication is continuously monitored by the CoCCA NOC. CoCCA also ships WAL files so that in the event of an extend WAN outage the offsite SRS can be updated using Point in Time Recovery (PITR). 

RDDS and EPP services are load balanced across between two different application servers at the primary SRS ( more application servers can easily be added ). Public read-only RDDS may also load balanced made HA by simply having the nagios monitoring software automatically modify resource records and send traffic to either of the secondary ⁄ failover SRSʹs for near-real time WHOIS, when the primary becomes available or SLA issues ( DoS etc ) are resolved, RDDS services are automatically switched back to the primary SRS.

The public IPs at the NOC used for EPP, WHOIS and GUI are on routable critical infrastructure ranges assigned to CoCCA by APNIC. In the event of an issue with the primary Internet link at the Sydney NOC (PIPE networks) CoCCA may either modify A and AAA records for GUI ⁄ RDDS and EPP services to the local failover link, or the entire IP range can be re-routed using BGP routing to a COCCA failover SRS. If the entire Sydney NOC suffers an extended outage the traffic can be routed to the the failover SRS (Palo Alto) or Escrow SRS (Auckland) as conditions dictate by either modification of resource records ( A, cname ) or BGP of the AS.

VMware images of are made using Veeam Backup & Replication.

In addition to streaming replication, SRS data is sent to CoCCAʹs failover SRS and Escrow sites every 10 minutes (or sooner depending on activity) via SCP in the form of postgresql PITR files, and daily in the form of compressed database dumps and vm images.

24.12 List of Registrars Connected to the CoCCA SRS in Sydney AU as of March 30, 2012

Name Country
12idn Limited NZ
1API GmbH DE
3w Media GmbH DE
abayard HT
AB NameISP SE
Active24 .CZ CZ
AFGNIC Registrar AF
AGJ Times GB
Alpha Communications Network HT
Ascio Technologies DK
Atlantis North Ltd GB
Automattic Inc US
DomainReg DE
Bamik Network Information AF
BBCWYSE Technology Co. Ltd MU
BB Online UK Limited GB
Beijing Guoxu Network CN
Bizcn.com, Inc. CN
Biz.Vi Networks Ltd. HT
Blacknight Internet Solutions IE
Brights Consulting Inc. JP
Brown Domain Services HT
cctldnames GY
Cogent IPC SE
Com Laude GB
Communigal Communication Ltd IL
Connect-Ireland IE
Core | Council of Registrars CH
CPS-Datensysteme GmbH DE
Cronon AG AF
Corporation Service Company CA
Consortium For Success, Inc. US
Cybernaptics Ltd MU
DA Domains DM
DANILOU.COM HT
Digital Technology GY
Dinahosting SL ES
Dipcon AB SE
documentdata anstalt LI
DomainClub.com US
Domaine.fr FR
Domaininfo AB SE
DomainKeep US
Domain The Net Technologies IL
Dominiando IT IT
Dynamic Network Services US
E-advert Ltd MU
Easy Line Host FI
Easyspace Ltd GB
Encirca US
Enet Corporation JP
enom US
Entorno Digital S.A ES
EPAG Domainservices DE
Euro Billing Grona Verket AB SE
EuroDNS LU
IVX B.V. NL
FBS TR
FING GLOBAL NETWORK Inc JP
Fody Technologies Ltd. MU
FRCI eServices Ltd MU
Gabia, Inc KR
Gandi SAS FR
Gastein IT Services AT
Gauss research Laboratory, Inc. PR
Guyananet GY
Government Online Centre (MU) MU
GoHoto Pty Ltd AU
Golden Internet RU
GRAFIKLIF-WebalaMinute HT
Gransy s.r.o. CZ
GUYANANET GY
HAICOM ( HAITI Communications ) HT
HAINET S.A. HT
Haiti Domain HT
Haqmal ICT Solution Services AF
Hikaru Kitabayashi JP
Holomedia FR
ht_hostmicrofos HT
Hostnet bv NL
Ultraspeed UK GB
FSM II FM
HTG HT
GaMa Consulting S.A. HT
Koborg MU
Indeca GmbH DE
INDOMCO FR
Innovative Systems GY
Innter.Net CY
Instra Corporation AU
IntaServe AU
InterNetworX Ltd. & Co. KG DE
InterNetX GmbH DE
Indian Ocean Territories CX
IP Mirror Pte Ltd SG
Iron Mountain IPM US
Interactivetool.biz MU
Jestina Mesepitu SB
Jms-Networks (TM) GB
J SQUAD SYSTEMS INC. AF
Kawing Chiu US
Keiichi SHIGA (old: Keiichi dot business) JP
Key-Systems DE
Klute-Thiemann GmbH DE
Knipp DE
Larsen Data DK
Legekko Info Ltd MU
Lexsynergy Limited GB
LGLovells FR
MailClub (France) FR
Marcaria.com US
Marcus Cake AU
MARIDAN InterNET GmbH DE
MarkMonitor US
Maudeline Auguste HT
MediaWars CO LTD JP
Melbourne IT CBS AB SE
Domainbox GB
MICROCIS AF
Moniker Online Services, LLC. US
Mauritius Domains MU
Naikbeen_NCP AF
LIVING BY BLUE CO.,LTD JP
NameAction CL
Name.com LLC US
Nameshield FR
NameWeb BVBA BE
NATCOM S.A HT
National Computer Board MU
Nemesys Ltd MU
Nessus GmbH AT
NetAccess ⁄ AccessHaiti S.A. HT
NetNames Ltd GB
Net-Chinese Co., Ltd. TW
NETCOM S.A. HT
NETLINKS AF
Network Solutions, LLC US
Networking4all NL
Mauritius.biz Hosting MU
Nexus GB
NICE S.r.l. d⁄b⁄a niceweb.eu IT
Norfolk Island Data Services NF
Novagroup HT
Novutec Inc. US
OFFICE DE MANAGEMENT ET DE RESSOURCES HUMAINES HT
MB OPTIMAL SYSTEMS LTD GB
Our Telekom SB
OVH FR
OXWELL CC VG
Multilink S.A HT
Peweb Ltda BR
PlanA Corp AI
pointcruz.com SB
pro.vider.de DE
Quick Net HT
Redspider.biz GY
register_com US
Register.it spa IT
Register.mu MU
Register.eu BE
Domain Name Registration Service Reg.Net.Ua UA
101Domain, Inc. US
RWGUSA US
Safenames GB
Solomon Telekom SB
Solutions S.A. HT
SpeedPartner GmbH D
studio28 GY
SunnyNames LLP US
TainoSystems HT
Telecommunications Authority of Kiribati KI
Telecom Plus Ltd MU
TierraNet Inc. US
Timor Hosting TL
TradeMark Unlimited, Inc US
Todaynic.com,Inc. HK
TPP Domains Pty Ltd AU
I.C.S. Trabia-Network S.R.L. MD
TRANSNET S.A HT
TRANSVERSAL HT
Timor Telecom TL
Tucows CA
ugcit GY
UNICART Ltd. BG
united-domains AG DE
Variomedia AG DE
Melbourne IT DBS, Inc. US
V-Trade Ltd MU
Visiant Outsourcing S.r.l. IT
Web Commerce Communications WebCC MY
WEB Development and Hosting Ltd MU
WEB Ltd MU
Web Solutions ApS DK
WebWorkers Internet Consultants cc NA
NamIT cc Namibia NA
WSR Corporation GB
Xcess Interactive GY
Xin Net Technology Corp . CN

CoCCA was among the first registry providers to embrace the EPP standard seven years ago. CoCCAʹs traditional clients have been small to medium sized ccTLD operators un-encumbered by the legal, contractual and governance issues that often result in protracted delays in rolling out new policy, technology or standards in larger ccTLDs or in the gTLD environment. CoCCA and the users of its SRS software have been historically free to trial and introduce innovative technology policy. 

The CoCCA SRS is an ʺall in oneʺ software package ( RDDS⁄ EPP⁄ GUI ⁄ Accounting ) however this does not prevent it from being deployed in a clustered environment where multiple instances answer for a specific protocol under a load balanced, high availability environment. Using a load balance appliance EPP traffic can be sent to one or more servers which are in turn connected to the same database. In all small to medium sized deployments tested to date load balancing the EPP service is not required - the load balancer is simply configured to provide failover and HA. 

An aggressive three-year development program commenced in January 2009 with the objective of ensuring CoCCAʹs software was compliant with ICANNʹs new gTLD requirements - as well as the meeting needs of new and existing users in the ccTLD community. 

25.1 Current EPP RFC Compliance:

RFC 5730 Extensible Provisioning Protocol (EPP)

This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described.

RFC 5730

This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The pamoja SRS fully implements the service discovery, commands, responses, and the extension framework described. 

RFC 5731

This RFC explains the mapping of the primary EPP registry object, the domain object. It reviews associated attributes and states of the domain object as well as child object relationships (hosts). It also details associations with other contact objects. The pamoja SRS complies with the full XML examples and descriptions and applies flexibility where permitted. For example, 5731 allows operators to implement the info command with different responses for a “sponsoring registrar” and a “non-sponsoring registrar” in regards to many domain object attributes. The pamoja SRS implements this as a base protocol document for EPP.

RFC 5732

The pamoja SRS implements this as a base protocol document for EPP. The pamoja SRS notes this RFC describes the mapping of relationships to host objects, which are by definition subordinate to the superordinate domain name object. Host objects that are defined as internal or in the namespace of the registry must be related to a superordinate domain object to be created. Internal hosts, as full child objects, face restrictions associated with the management of their superordinate domain object. External hosts are hosts belonging to another domain namespace and as such are not subordinate in the present namespace. Internal hosts can have a glue or an A record associated with them, external hosts refer to another namespace or zone for the associated A record. 

RFC 5733

Another RFC implemented in the The pamoja SRS server, this RFC describes the contact object mappings in EPP. Contact objects are used to contain related data surrounding the standardized contacts types in TLD registries including attributes such as contact type, country, telephone numbers, email addresses, etc. As a standalone object, a contact object can be created and associated with no domain objects or with any number of domain objects available in the registry. This is used commonly by registrars to update common contact information associated across large numbers of domains in a single transaction. Like the domain object, it can be secured with a passphrase or “authinfo” code. Contact object data represents the definitive data source for authoritative RDDS (WHOIS) in new TLDs. 

RFC 5734

The pamoja SRS implements this RFC as the preferred industry transport and in compliance with ICANNʹs requirements. This RFC describes a standard implementation of TCP incorporating TLS. The transport of choice for the EPP registry community has been TCP. Implementers are encouraged to take precautions against denial of service attacks through the use of standard technologies such as firewall and border router filters.

RFC 5735

The pamoja SRS implements this RFC as applicable to any extensions it utilizes as this RFC provides specific and detailed guidance on EPP extensions. An important principle in creating extensions to, as opposed to modifying, the EPP protocol was to fully preserve the integrity of the existing protocol schema. Additionally, a valid extension itself should be extensible. Another important requirement in the RFC is to include announcements of all available extensions in the EPP server greeting element before establishing an interactive client session. 

RFC 3915

The pamoja SRS supports this extension since this all CoCCA managed TLDs implement the grace period implementation known as the Redemption Grace Period or “RGP”. When RGP is in use, domains are deleted into the RGP where Registrars may request a restoration of the domain. This is a billable event and requires a three-step process: placement of the domain into a pending restore state, submission of a restore report explaining why the domain is being restored, and finally the restoration of the domain. The RFC extends the domain update command, adds related domain statuses, such as ʺredemptionPeriodʺ and ʺpendingRestore,ʺ and extends the responses of domain info and other details. The RFC provides a lifecycle description of the RGP and defines the format and content for client to server submission of the associated restore reports. 

RFC 5910

The pamoja SRS will support DNSSEC and therefore will also support this extension from initiation of the registration process. DNSSEC is a mechanism for cryptographically verifying that each delegate zone in the DNS hierarchy has been referred to or is referring to its genuine parent or child zone respectively. Since TLD zone files are generated from authoritative registry data, this extension specifically provides the ability to add elements to the domain-create and domain-update functions and to the domain-info responses, allowing registrars to submit associated delegated signer (DS) information of the child zone indicating it is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.

SRS General

The pamoja SRS Session Management - pamoja listens on port 700 for client requests. 
The pamoja SRS Message Exchange - pamoja complies with the EPP message exchange rules
The pamoja SRS Data Unit Format - pamoja uses the prescribed packet formats

25.2 EPP Security: 

CoCCAʹs SRS performs username⁄clid⁄password⁄ssl certificate checks and also contains application level code to restrict connections to a set of IP addresses for each client and login.

Additional security is provided by firewall IP restrictions that restrict port 700 access to the SRS to trusted IPʹs and the use of stateful firewalls and load balancing devices to mitigate DoS attacks or other malicious activity. 

25.3 EPP - Demonstrating Capability

CoCCA authors the most widely deployed EPP SRS solution and has a long history of both development of and production experience operating an EPP SRS. The CoCCA NOC currently has 12 TLDs on itʹs production EPP SRS, over 20 TLD managers have deployed the CoCCA EPP solution locally for production use. 

In order to demonstrate capability and compliance with the RFCʹs in 24.1 and CoCCAʹs Extensions in 25.3. UMMAH DIGITAL LIMITED has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OTE) EPP interface should they desire to evaluate CoCCAʹs RFC compliance. Alternatively, evaluators may download CoCCAʹs pamoja SRS, install locally and contact CoCCA for configuration advice.

The URL to download pamoja is https:⁄⁄downloads.coccaregistry.net. Installers are available for Linux64x ( Centos ⁄ Ubuntu ), OSX (10.6+) and WIN7+ servers.

25.3 EPP Extensions

The CoCCA SRS currently provides several extensions to EPP, using the practices defined in RFC-3735. The CoCCA greeting currently defines the following four extensions:
...
〈svcMenu〉
...
〈objURI〉urn:ietf:params:xml:ns:host-1.0〈⁄objURI〉
〈svcExtension〉
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-ip-verification-1.1〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-contact-proxy-create-update-1.0〈⁄extURI〉
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
〈⁄svcExtension〉
〈⁄svcMenu〉
...

25.3.1 Registry Grace Period Extension 
〈extURI〉urn:ietf:params:xml:ns:rgp-1.0〈⁄extURI〉
Implemented as defined in RFC-3915 - http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt

25.3.2 Reseller Mapping Extension
〈extURI〉https:⁄⁄..⁄cocca-reseller-1.0〈⁄extURI〉
Extensions for Domain:Create and Domain:Update

This extension tags a domain as being registered via one of registrarsʹ resellers. The reseller reference is provided in the reference section, and is recorded against the domain as it is registered or updated. The reseller list must be maintained by the Registrar through the CoCCA Registry web interface. 

If a registrar decides to load reseller information and map domains, the .UMMAH WHOIS server (port 43 and 443), Historical Abstracts, and Premium WHOIS will display the reseller contact information as well as the Registrar information. If ICANN advises that display of reseller information in the port 43 WHOIS is inconsistent with the response format required in Specification 4, 1.4.2 then CoCCA will disable port 43 and or port 443 display of reseller data for the .UMMAH TLD. Reseller information would still be stored and available for Historical Abstracts and users of the CoCCAʹs Premium WHOIS service.

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺʺ〉

 〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
 xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ
 xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈xs:element name=ʺextensionʺ〉
 〈xs:complexType〉
 〈xs:sequence〉
 〈xs:element name=ʺreferenceʺ type=ʺxs:stringʺ⁄〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉
 〈⁄xs:schema〉 

〈extension〉
 〈reseller:extension xmlns:reseller=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-reseller-1.0ʺ〉
 〈reseller:reference〉XXXXX〈⁄reseller:reference〉
 〈⁄reseller:extension〉
〈⁄extension〉

25.3.3 Clearinghouse for Intellectual Property Extension

Extension to connect to an external database to validate IP rights. 

〈extURI〉https:⁄⁄..⁄coccaregistry.net⁄cocca-ip-verification-1.1〈⁄extURI〉

Extension for Domain:Create

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈xs:schema targetNamespace=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ
 xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-ip-verification-1.1ʺ
 xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈xs:annotation〉
 〈xs:documentation〉
 Extensible Provisioning Protocol v1.0
 Extension for providing IP Verification to CoCCA Registries

 v1.1 adds extra fields for trademark verification
 〈⁄xs:documentation〉
 〈⁄xs:annotation〉

 〈xs:element name=ʺextensionʺ〉
 〈xs:complexType〉
 〈xs:choice〉
 〈xs:element name=ʺchipʺ type=ʺchipTypeʺ⁄〉
 〈xs:element name=ʺtrademarksʺ type=ʺtrademarkTypeʺ⁄〉
 〈⁄xs:choice〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉

 〈xs:complexType name=ʺchipTypeʺ〉
 〈xs:sequence〉
 〈xs:element name=ʺcodeʺ〉
 〈xs:simpleType 〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉

 〈xs:complexType name=ʺtrademarkTypeʺ〉
 〈xs:sequence〉
 〈xs:element name=ʺtrademarkʺ minOccurs=ʺ1ʺ maxOccurs=ʺunboundedʺ〉
 〈xs:complexType〉
 〈xs:sequence〉
 〈xs:element name=ʺregisteredMarkʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺregistrationNumberʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺregistrationLocalityʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺcapacityʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:enumeration value=ʺOWNERʺ⁄〉
 〈xs:enumeration value=ʺASSIGNEEʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺcompanyNumberʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
〈⁄xs:schema〉


This extension allows registrars to provide proof of their Intellectual Property claim for a name, when registering. It can be used to specify Clearing House for IP codes, or Trademarks. A CHIP request XML is as follows:

〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:chip〉
〈coccaip:code〉XXXXXXX〈⁄coccaip:code〉
〈⁄coccaip:chip〉
〈⁄coccaip:extension〉
〈⁄extension〉

An extension containing trademark information is as follows:

〈extension〉
〈coccaip:extension xmlns:coccaip=ʺhttps:⁄⁄..⁄cocca-ip-verification-1.1ʺ〉
〈coccaip:trademarks〉
〈coccaip:trademark〉
〈coccaip:registeredMark〉CoCCA〈⁄coccaip:registeredMark〉
〈coccaip:registrationNumber〉12345〈⁄coccaip:registrationNumber〉
〈coccaip:registrationLocality〉NZ〈⁄coccaip:registrationLocality〉
〈coccaip:capacity〉OWNER〈⁄coccaip:capacity〉
〈coccaip:companyNumber〉1234〈⁄coccaip:companyNumber〉
〈⁄coccaip:trademark〉
〈⁄coccaip:trademarks〉
〈⁄coccaip:extension〉
〈⁄extension〉

At the time of application it is not envisioned that this extension will be used for the .UMMAH TLD. However it demonstrates an existing technical capacity to query and synchronize data with external databases in order to validate IP or other rights.

25.3.4 Contact Proxy Extension

〈extURI〉https:⁄⁄ epp.ote.UMMAH.coccaregistry.net⁄cocca-contact-proxy-1.0〈⁄extURI〉
Extension to allow registrars to lodge several sets of contact details for a given domain and select which one is displayed in the port WHOIS.

https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 and https:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0 - extensions for Contact:Create and Contact:Update.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
 xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ
 xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
 xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ
 xsi:schemaLocation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0 cocca-contact-proxy-1.0.xsdʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈xs:import namespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ schemaLocation=ʺcocca-contact-proxy-1.0.xsdʺ⁄〉

 〈xs:annotation〉
 〈xs:documentation〉
 Extensible Provisioning Protocol v1.0

 Extension for creating or updating a contact, with proxy information. This proxy information
 is provided as a WHOIS response, instead of the contactʹs real information if zone settings
 allow. Proxy information may be specified in full, by providing all the details or by using a
 reference to a previous contact proxy info. If you want to clear a contactʹs proxy info, send
 an existingProxy type request with an empty reference string.
 〈⁄xs:documentation〉
 〈⁄xs:annotation〉

 〈xs:element name=ʺextensionʺ〉
 〈xs:complexType〉
 〈xs:choice〉
 〈xs:element name=ʺnewProxyʺ type=ʺproxyTypeʺ⁄〉
 〈xs:element name=ʺexistingProxyʺ〉
 〈xs:complexType〉
 〈xs:sequence〉
 〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉
 〈⁄xs:choice〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉

 〈xs:complexType name=ʺproxyTypeʺ〉
 〈xs:sequence〉
 〈xs:element name=ʺproxyDetailsʺ〉
 〈xs:complexType〉
 〈xs:sequence〉
 〈xs:element name=ʺreferenceʺ minOccurs=ʺ0ʺ type=ʺproxy:referenceTypeʺ〉
 〈xs:annotation〉
 〈xs:documentation〉
 This is an optional field you can use to give this proxy info a particular reference.
 Each reference must be unique, so if you have an existing contact proxy info record
 with this reference value, you will UPDATE that record, changing the proxy info for
 any existing contact referencing that proxy.

 If you donʹt specify a reference, one will be created for you and returned in the EPP
 response.
 〈⁄xs:documentation〉
 〈⁄xs:annotation〉
 〈⁄xs:element〉
 〈xs:element name=ʺemailʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺvoiceʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
 〈xs:element name=ʺfaxʺ minOccurs=ʺ0ʺ type=ʺproxy:phoneNumberTypeʺ⁄〉
 〈xs:element name=ʺinternationalAddressʺ type=ʺproxy:addressTypeʺ⁄〉
 〈xs:element name=ʺlocalAddressʺ type=ʺproxy:addressTypeʺ minOccurs=ʺ0ʺ⁄〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉

 〈xs:element name=ʺresDataʺ〉
 〈xs:annotation〉
 〈xs:documentation〉
 If a contact is created or updated with contact proxy information specified, or if the registrar
 creating the contact has a default proxy specified, then the reference value identifying the proxy
 is returned in the response, in the extension⁄resData field described here. If the contact was updated to
 clear the reference field (i.e. setting the contactʹs proxy using the existingProxy type, but leaving
 the reference field empty) then the reference value will be empty, confirming the update.
 〈⁄xs:documentation〉
 〈⁄xs:annotation〉
 〈xs:complexType〉
 〈xs:sequence〉
 〈xs:element name=ʺreferenceʺ type=ʺproxy:referenceTypeʺ⁄〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
 〈⁄xs:element〉
〈⁄xs:schema〉


〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈xs:schema targetNamespace=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
 xmlns=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ
 xmlns:xs=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈xs:simpleType name=ʺreferenceTypeʺ〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ40ʺ⁄〉
 〈xs:minLength value=ʺ0ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉

 〈xs:complexType name=ʺphoneNumberTypeʺ〉
 〈xs:sequence〉
 〈xs:element name=ʺnumberʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ64ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺextensionʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ64ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉

 〈xs:complexType name=ʺaddressTypeʺ〉
 〈xs:sequence〉
 〈xs:element name=ʺstreet1ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺstreet2ʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ0ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺstreet3ʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ0ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺcityʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ1ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺstateProvinceʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ0ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺpostcodeʺ minOccurs=ʺ0ʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:maxLength value=ʺ255ʺ⁄〉
 〈xs:minLength value=ʺ0ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈xs:element name=ʺcountryCodeʺ〉
 〈xs:simpleType〉
 〈xs:restriction base=ʺxs:tokenʺ〉
 〈xs:pattern value=ʺ[A-Z]{2}ʺ⁄〉
 〈⁄xs:restriction〉
 〈⁄xs:simpleType〉
 〈⁄xs:element〉
 〈⁄xs:sequence〉
 〈⁄xs:complexType〉
〈⁄xs:schema〉

This extension allows the association of a contact proxy with a contact.

The contact:create and contact:update extensions can specify an existing proxy contact by ID. or create a new proxy contact. To associate a contact with an existing contact proxy, use this form:

〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ〉
〈proxyupdate:existingProxy〉
〈proxy:reference xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉XXXXX〈⁄proxy:reference〉 
〈⁄proxyupdate:existingProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉

where XXXXX is the ID of the proxy contact you wish to use. To create a new contact and associate it with a contact, use this form of the create or update extension:

〈extension〉
〈proxyupdate:extension xmlns:proxyupdate=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-create-update-1.0ʺ xmlns:proxy=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-contact-proxy-1.0ʺ〉
〈proxyupdate:newProxy〉
〈proxyupdate:proxyDetails〉
〈proxy:reference〉XXXXX〈⁄proxy:reference〉
〈proxy:email〉XXXXX〈⁄proxy:email〉
〈proxy:voice〉
〈proxy:number〉XXXXX〈⁄proxy:number〉
〈proxy:extension〉XXXXX〈⁄proxy:extension〉
〈⁄proxy:voice〉
〈proxy:internationalAddress〉
〈proxy:street1〉XXXXX〈⁄proxy:street1〉
〈proxy:street2〉XXXXX〈⁄proxy:street2〉
〈proxy:city〉XXXXX〈⁄proxy:city〉
〈proxy:stateProvince〉XXXXX〈⁄proxy:stateProvince〉
〈proxy:postcode〉XXXXX〈⁄proxy:postcode〉
〈proxy:countryCode〉XXXXX〈⁄proxy:countryCode〉
〈⁄proxy:internationalAddress〉
〈⁄proxyupdate:proxyDetails〉
〈⁄proxyupdate:newProxy〉
〈⁄proxyupdate:extension〉
〈⁄extension〉

At the time of application it is not envisioned that this extension will be used for the .UMMAH TLD.

Other:

In addition to the above statuses, the CoCCA Registry provides additional lifecycle statuses over and above those defined in RFC-5731. The CoCCA Activation statuses are provided using namespaced status elements in the Domain:Create and Domain:Info responses, and are accompanied by an RFC-3735 compliant extension section. A Domain:Create response for a newly registered domain would appear as follows:

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ?〉

〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ229ʺ id=ʺ21192ʺ⁄〉
 〈resData〉
 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:name〉info.confirm.test〈⁄domain:name〉
 〈domain:roid〉234511-CoCCA〈⁄domain:roid〉
 〈domain:status s=ʺinactiveʺ〉Delegation information has not been supplied〈⁄domain:status〉
 〈activation:status xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ s=ʺpendingActivationʺ〉
 This domain requires acceptance of AUP and registrant agreement by 2012-02-29 10:19
 〈⁄activation:status〉
 〈domain:registrant〉regis-80ESBqGtje〈⁄domain:registrant〉
 〈domain:clID〉registrar〈⁄domain:clID〉
 〈domain:crID〉registrar〈⁄domain:crID〉
 〈domain:crDate〉2012-02-21T21:19:32.887Z〈⁄domain:crDate〉
 〈domain:exDate〉2013-02-21T21:19:33.006Z〈⁄domain:exDate〉
 〈domain:authInfo〉
 〈domain:pw〉Hh7Wz3c9dC〈⁄domain:pw〉
 〈⁄domain:authInfo〉
 〈⁄domain:infData〉
 〈⁄resData〉
 〈extension〉
 〈rgp:infData xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsdʺ⁄〉
 〈activation:extension xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ〉
 〈activation:url〉https:⁄⁄registry-adam⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:url〉
 〈activation:link〉⁄activate.jsp?activationCode=ITIhi1kma8SmbCsYefY18uEaJikwOXKNL0MLu0HHXkXjZUynrDZZUh6SB2h8h1D8〈⁄activation:link〉
 〈⁄activation:extension〉
 〈⁄extension〉
 〈trID〉
 〈clTRID〉CR-4〈⁄clTRID〉
 〈svTRID〉1329859182069〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

25.4 EPP Access Requirements

1. IP Address white listing ( firewall and application layer )
2. Signed registry issued SSL certificates
3. Username⁄Password

Authentication requires that the IP address the connection is made from be white listed IP, that the entity connecting use a CoCCA-issued SSL certificate and that correct clientID and passwords be used. By default registrars have only GUI access to the SRS, EPP is enabled by request and only after a Registrar has been certified on CoCCAʹs OT&E platform. 

25.5 CoCCA GUI Environment
In addition to providing the standard implementation of EPP that runs on Port 700, CoCCA also provides a secure web based Graphical User Interface running on Port 443 that allows Registrars to register and manage domains in their portfolio without connecting by EPP.

25.6 EPP Via the GUI
In cases where a registrar uses the SRS GUI, all domain, host and contact operations supported by the RFCʹs are executed by pamojaʹs internal EPP engine to ensure that GUI and port 700 EPP interfaces behave identically. 

These methods of authentication include:
1. IP Address white listing
2. Using a one-time password (ʺOTPʺ) delivered via hardware token, soft token or SMS is issued by CoCCA.
3. The use of a Username⁄Password

25.7 Registrars 
A list of registrars that have already successfully integrated and connected to CoCCAʹs SYD SRS is attached. CoCCAʹs SYD SRS is used by 200+ Registrars, many of which currently utilize the XML based EPP protocol for the purpose of providing automated services to their clients. 
 
25.8 Resourcing and Continuous Development

CoCCAʹs software development team and systems administrators support both their own in-house SRS and that of over 23 other TLD managers who have deployed the pamoja SRS software locally on their own infrastructure. Development is on-going and active. The CoCCA SRS has been developed over the past 9 years, the bulk of the development on the EPP platform has been completed, however two full time developers are employed by CoCCA to customize, maintain and improve the software for the TLDʹs that use it. 

Because of the co-operative nature of the development process CoCCA works closely with over a dozen developers and network engineers employed by users of CoCCAʹs TLD software to resolve bugs, continuously improve pamojaʹs performance and add new features.

CoCCA currently delivers proven, innovative WHOIS and Registration Data Directory Services (ʺRDDSʺ) technology to the TLDs hosted by CoCCA and to the TLDs that deploy the pamoja SRS on their own infrastructure. CoCCAʹs Specification Four compliant WHOIS and RDDS technology will be utilized by CoCCA for the UMMAH TLD. Under CoCCAʹs SRS Architecture one WHOIS server will answer for all the TLDs in the SRS. Each TLD Sponsor can configure the WHOIS such that it serves different results depending on the wishes of UMMAH DIGITAL LIMITED (“UMMAH DIGITAL”) and applicable ICANN requirements.

26.1 WHOIS Architecture and Infrastructure Overview

CoCCAʺs flexible WHOIS architecture is designed for high availability, complies with RFC 3912 and surpasses the requirements in Specifications 4 and 10. The flexible pamoja WHOIS server may be configured to provide a variety of information, and in a variety of formats that supplements ICANNʹs proposed gTLD requirements.

As registrations appear (or are modified) in the registration database, changes are committed to a replicated read only secondary database utilized by CoCCAʹs WHOIS server. Because the replication is synchronous WHOIS data is presented in real time. If at a future date WHOIS query response times becomes an SLA issue, WHOIS responses may be cached using ʺinfinite cacheʺ horizontal caching technology, which has been tested and can readily scale to meet future demand, alternatively RDDS services may be answered by a SRS instance off-site ( one of the CoCCA secondary⁄failover SRSʹs) for near real-time WHOIS and RDDS.

26.2 Port 43 WHOIS (command line)

CoCCA has confirmed that the format of the domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses can and will be configured to conform to the mappings specified in EPP RFCʺs 5730-5734. The originating IP address and date time of all WHOIS queries are logged and will be stored for a minimum of 28 days in the production SRS.

GUI configuration and command line flags allow a client to request output in ASCII, Unicode, ASCII and Unicode or HTML output (with tables). For IDN TLDs, a variety of command line WHOIS options have been tested in conjunction with the Arabic TLDs that use the CoCCA SRS. CoCCA supports all the current IETF standards and several developed for current IDN users. CoCCAʹs SRS can be readily modified should ICANN mandate a particular technology in the future. 

26.2.1 Domain Name Data:
* Proposed Production Query format: whois ʺh -whois.nic.〈TLD〉 domain
* Response format: Currently compliant with Specification 4, Section 1.4.2 (pages 40-41). 

26.2.2 Registrar Data:
* Proposed Production query format: whois ʺh -whois.nic.UMMAH registrar
* Response format: Currently compliant with Specification 4, Section 1.5.2 (pages 41-42) -- with the exception of the registrar ʺWHOIS Serverʺ object (p. 42), under the proposed .UMMAH thick registry model registrars will not operate their own WHOIS servers. 

Inclusion of this object seems redundant and may cause confusion regarding the authorative WHOIS server for .UMMAH. If required by ICANN the registrar WHOIS object data will be collected and displayed by CoCCA. 

26.2.3 Name Server Data:
* Proposed Production Query format: whois ʺh -whois.nic.〈TLD〉 (Host or IP)
* Response format: Currently compliant with Specification 4, Section 1.6.2 (p. 42) 

26.3 Public WHOIS service via a secure port 443 web-based interface:
CoCCAʺs pamoja software has a publicly accessible port 443 GUI service that allows individuals to query the SRS for registration data for individual domain, registrar or host records. 

CoCCA has confirmed that the format of the domain status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses can and will be configured to conform to the mappings specified in EPP RFCʺs 5730-5734.

To prevent abuse, CoCCA implements rate limiting via CAPTCHA for each individual transaction. The procedure would follow as per bellow. 

1) An individual would navigate in a browser to https:⁄⁄whois.nic.〈TLD〉
2) Click on the appropriate button (Domain, Registrar, or Name Server)
3) Enter the applicable parameter:
----Domain name, including the TLD (e.g., EXAMPLE.TLD)
----Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
----Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)
4) Enter the CAPTCHA phrase or symbols
5) Click on the Submit button

Possible Outcomes from the query:
* If an exact match for the domain, host, or registrar exists in the SRS, the Port 443 WHOIS will display the same information and with the same formatting, as the port 43 WHOIS (see above and Specification 4, Sections 1.4 ʺ 1.6 ).

* If there is no exact match but a super-ordinate domain exists the SRS data for the super- ordinate name is to be displayed. By way of example if an individual searches for abc.domain.UMMAH and abc.domain.UMMAH does not exist then the SRS would display the information on domain.UMMAH and advise the individual accordingly.

26.4 WHOIS and RDDS | Demonstrating Capability

CoCCA has almost a decade of experience running multiple TLDs and providing WHOIS services. WHOIS and RDDS are integrated into CoCCAʺs pamoja software. In order to demonstrate capability and compliance with the Specification Four, Section One, UMMAH DIGITAL has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OTE) WHOIS and RDDS interface on request. Alternatively, evaluators may download CoCCAʹs pamoja SRS, install locally and contact CoCCA for configuration advice.

The URL to download pamoja is https:⁄⁄downloads.coccaregistry.net. Installers are available for Linux64x ( Centos ⁄ Ubuntu ), OSX (10.6+) and WIN7+ servers.

26.5 Network Diagrams

CoCCAʹs RDDS services serve data directly from the SRS, there is no separate WHOIS database. If performance becomes and issue pamojaʹs RDDS read-only services can be configured to extract data from a replicated copy of the SRS. 

Individuals or entities that desire to run multiple queries against the SRS for law enforcement purposes, IP protection or to mitigate cyber-crimes need simply subscribe to CoCCAʹs Premium RDDS Service and may query the SRS via EPP as well as port 43 and the 443 GUI. Premium RDDS users are granted EPP read-only access (on request) and need not be ICANN Accredited registrars. In many cases EPP may be a better tool for automation of multiple queries than port 43 WHOIS.

The systems supporting WHOIS are fully redundant with hardware and software that can easily scale to meet the UMMAH DIGITALʹs growth projections of the TLD. For comprehensive description of the SYD NOC see questions 31 and 32. 

The WHOIS server at the CoCCA Data Centre in Sydney currently answers for 12 TLDs and processes on average fewer than 8000 WHOIS requests per hour. The current WHOIS server and database has been tested and can answer in excess of 9,000 TPS as currently configured - network latency may impact real world results depending on the origin of the query.
 
26.6 Synchronization Frequency Between Servers

CoCCAʹs WHOIS architecture is designed to ensure WHOIS data is current, accurate and reliable. CoCCAʹs RDDS services serve data directly from the SRS, in the default configuration there is no separate WHOIS database. CoCCA uses PostgreSQL and synchronous replication data is committed to the production SRS master database and a secondary database (read only) server configured to serve WHOIS data, so that at all times the SRS and CoCCAs WHOIS servers serve the same data. 

CoCCA streams SRS data off-site asynchronously (and by log file shipping as a failover) to their SRS servers in Palo Alto and Auckland to enable those SRSʹs to serve near-real time WHOIS data if the primary SRS experiences an issue that negatively impacts CoCCAʹs ability to meet SLAʹs for the .UMMAH TLD.

If WHOIS caching is required as the .UMMAH TLD grows, compliance with the SLA requirements in the ICANN agreement may necessitate that Failover SRS or Escrow SRS answer RDDS queries or that cache servers be deployed, in such a circumstance, the WHOIS response would be near real-time ( accurate to within a min or two of the primary SRS ).

26.7 Compliance with Specification 4

CoCCA will provide free RDDS Services via both port 43 and a web-based port 443 site in accordance with RFC 3912.

Additionally, the CoCCA will also provide fee-based Premium RDDS service described in further detail below. CoCCA and the UMMAH DIGITAL acknowledge that ICANN reserves the right to specify alternative formats and protocols and if such change were to occur; CoCCA will implement specification changes as soon as practical.

CoCCA and the UMMAH DIGITAL will provide bulk access of thin RDDS data to ICANN to verify and ensure operational stability of registry services, as well as to facilitate compliance checks on accredited registrars. Access will be provided to ICANN on a weekly basis and the format will be based on section 3 of Specification 4. Further, exceptional access to thick RDDS will be provided to ICANN per Specification 2.

Should ICANN request it CoCCA will provide ICANN with a Premium RDDS login at no charge which will provide them with continuous access to the SRS to extract thick SRS data for .UMMAH at its leisure.

The proposed format of the data objects for domains, name servers , and the registrar output are provided below:

1.4. Domain Name Data:
1.4.1. Query format: whois EXAMPLE.TLD 
1.4.2. Response format:
Domain Name: EXAMPLE.TLD
Domain ID: D1234567-TLD
WHOIS Server: whois.example.tld
Referral URL: http:⁄⁄www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555
Domain Status: clientDeleteProhibited Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Domain Status: serverUpdateProhibited Registrant ID: 5372808-ERL
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
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
〉〉〉 Last update of WHOIS database: 2009-05-29T20:15:00Z 〈〈〈

1.5. Registrar Data:
1.5.1. Query format: whois ʺregistrar Example Registrar, Inc.ʺ 1.5.2. Response format:
Registrar Name: Example Registrar, Inc. Street: 1234 Admiralty Way
City: Marina del Rey
State⁄Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212 Fax Number: +1.3105551213
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http:⁄⁄www. example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
〉〉〉 Last update of WHOIS database: 2009-05-29T20:15:00Z 〈〈〈

1.6. Nameserver Data:
1.6.1. Query format: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺnameserver (IP Address)ʺ 1.6.2. Response format:
Server Name: NS1.EXAMPLE.TLD
IP Address: 192.0.2.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
WHOIS Server: whois.example-registrar.tld
Referral URL: http:⁄⁄www. example-registrar.tld
〉〉〉 Last update of WHOIS database: 2009-05-29T20:15:00Z 〈〈〈

26.8 Supplemental Data
Subject to ICANN Approval, UMMAH DIGITAL will ensure the SRS is configured to display of the following Supplemental RDDS data (objects only displayed if applicable).

Activation Expiry Date: 2011-12-31T11:11:11Z
Activation Date: 2011-12-31T11:11:11Z
Contact Confirmation Expiry Date: 2011-12-31T11:11:11Z
Contact Confirmation Date: 2011-12-31T11:11:11Z
Registration Grace Expiry Date: 2011-12-31
Registration MIN Expiry Date: 2011-12-31
Redemption Expiry Date: 2011-12-31
Purge Date: 2011-12-31
Renewal Grace Expiry Date: 2011-12-31
Transfer Grace Expiry Date: 2011-12-31

Reseller ID: 4261797-ERL
Reseller Name: ACME Reseller A
Reseller Street: 123 RESELLER STREET
Reseller City: RESELLER VILLE
Reseller State⁄Province: RS
Reseller Postal Code: 12345
Reseller Country: US
Reseller Phone: +1.5555551219
Reseller Phone Ext: 1239
Reseller Fax: +1.5555551219
Reseller Fax Ext: 4329
Reseller Support Email: helpdesk@reseller.〈TLD〉

26.9 Compliance with Specification 10

CoCCAʹs WHOIS service will comply and⁄or exceed the Registration Data Directory Service (RDDS) performance specifications outlined in Specification 10 of the proposed Registry agreement. For the existing TLDs supported by CoCCA, all service levels already exceed the Specification 10 Requirements:

* RDDS Availability 〉 98%
* RDDS Query 〉 95%
* RDDS Update 〉 95%

CoCCAʺs current RDDS availability statistics are available online at http:⁄⁄stats.coccaregistry.net

RDDS Services that are near real time can be provided from the failover or escrow SRSʹs by simply changing the IP⁄ CNAME for the whos.nic.[TLD] if there are SLA related or loading issues. This has been tested and is be done automatically at any time by CoCCAʹs monitoring software with near immediate effect 〈 30 seconds. 

26.10 Historical Abstracts 
In addition to CoCCAʹs RDDS services, detailed Historical Abstracts for individual domains are also made readily available to the general public, law enforcement and rights owners. 

Historical Abstracts are a compilation of all information available on a domain (including deleted ⁄ archived domains) that are held in the registry. This includes the time and date of all changes in contacts, hosts, registrars, resellers, statusʹs as well as all registration, activation, confirmation, renewal, restore or commercial transactions related to the maintenance of domain in the SRS. 

A representative sample of a Historical Abstract detailing the full history of a domain is attached.

26.11 Premium RDDS (port 443 and port 700 EPP)

UMMAH DIGITAL, with the service support of CoCCA, intends to offer Boolean partial and exact match search capability of all Domain, Contact, Host, Registrar data in the SRS within the Directory Service via a web interface. This Premium service will be billed at a monthly rate depending on the number of queries. 

ICANNʹs requirement that thin SRS data be made available in bulk makes it trivial for any entity who has thin data provided by the Centralized Zone Data Access Provider to run automated queries against the .UMMAH WHOIS public WHOIS server and extract thick SRS data - for all the domains in a zone. CoCCAʹs Premium RDDS makes access to registration data by IP Owners, Law Enforcement and CERTʹs efficient (EPP and GUI ) and timely (real-time), Premium RDDS does not expose any information that ICANNʹs gTLD policy does not effectively require [REGISTRY OPERATOR] to otherwise make publicly available to the public via WHOIS and the services of CZDA Provider.

Because experience has demonstrated that entities often attempt to use the WHOIS for a variety of purposes, rights protection, research etc., and because WHOIS is a rather blunt instrument which does not provide always provide the most useful advice on reserved domains, wildcard string registrations etc. entities with a Premium RDDS Service will, on request, be granted read-only EPP access to retrieve domain information. 

In order to make it unnecessary for IP owners or others to continuously query the SRS via EPP or command line WHOIS subscribers to the Premium RDDS may create lists that use regular java expressions and boolean operations that will notify them by email and if applicable EPP polling messages when a domain that matches a given string is registered.

To mitigate abuse of this feature, UMMAH DIGITAL will implement the following measures to ensure legitimate authorized users and ensure the feature is in compliance with any applicable privacy laws or policies:

* Premium RDDS subscribers must agree, as a condition of access to comply with Section 2.1.5 of Specification 4.To monitor that RDDS services are not being abused and used to ʺsupport the transmission by e- mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than user’s own existing customers, or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrarʺ CoCCA will seed the SRS with unique records and that enable them to track reported abuse back to an individual RDDS subscriber. 

* Because this is only offered as a premium and paid service, the request must follow the CoCCA application process to confirm the user identification and process the financial transaction. Thus, the typical end-user will not have access to this service.

* All GUI searches are conducted via authenticated user access using a combination of username and password and OTP tokens.

* CoCCA will monitor for out of band usage patterns of the Premium RDDS service and take appropriate action if policy thresholds are exceeded.

26.12 Zone File Access

Subscribers to the Premium RDDS may download .UMMAH zone files via the port 43 GUI up to six (6) times in any 24 hour period. 

CoCCA will comply all the requirements set out in Specification 4, Sections 2.1-2.1.7. Specifically, CoCCA will operate a dedicated server supporting FTP, and or other data transport access protocols in a manner specified by ICANN and the Centralized Zone Data Access Provider. 

26.13 Resource Plans

The .UMMAH TLD will be added to CoCCAʹs SRS at their primary data center in Sydney which currently supports the features noted above.

The UMMAH DIGITAL will dedicate [12] full-time professionals to coordinate the operation of the .UMMAH TLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .UMMAH TLD.

UMMAH DIGITAL will adopt the CoCCA harmonized life cycle currently adopted by a dozen ccTLDs. The .UMMAH life-cycle described bellow builds on the CoCCA technology and policy launched in November 2011 that sought to increase the accuracy of WHOIS data, minimize harm and increase consumer trust in TLDs. The life-cycle for the .UMMAH TLD builds on the traditional gTLD life-cycle by adding direct Registrant-Registry interaction.

The proposed .UMMAH life-cycle ensures key elements of the .UMMAH TLD abuse prevention and mitigation framework are adhered to by delaying mapping of the Registrantʹs desired NS delegation information until the registrant has Activated a domain. All .UMMAH registrations are provisional until Activated. Activation requires that the registrant confirm ( with CoCCA ) the accuracy of the contact information lodged by the registrar and reads agrees to the .UMMAH Registrant Agreement (RA), AUP and Privacy RDDS Policy. 

Activation takes place via automated processes that store the time : date and IP address of the Activation as part of the domains history.

Registrants will also be required to confirm (with CoCCA) the accuracy of the contact details and agreement with the .UMMAH RA, AUP and Privacy RDDS Policy at a) the time of renewal, b) on transfer and c) on the anniversary of registration. The following Life-Cycle describes the CoCCA SRS EPP and WHOIS behavior at various stages in the Life-Cyle.

27.1 Registration | Initial Registration

Not Registered
SRS EPP domain:check response

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ309ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:chkData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:cd〉
 〈domain:name avail=ʺ1ʺ〉no-exist.example〈⁄domain:name〉
 〈⁄domain:cd〉
 〈⁄domain:chkData〉
 〈⁄resData〉
 〈trID〉
 〈clTRID〉1333577979408〈⁄clTRID〉
 〈svTRID〉1333577979414〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉
 
SRS WHOIS response 
$ whois no-exist.example
Domain Name: no-exist.example
Domain Status: Available

TERMS OF USE: 〈Legal Notice〉

〉〉〉 Last update of WHOIS database: 2012-04-04T10:55:27.634Z 〈〈〈

Note if a string cannot be registered for policy reasons the following the SRS will return the following. EPP domain:check Status 

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ309ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:chkData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:cd〉
 〈domain:name avail=ʺ0ʺ〉profanity.example〈⁄domain:name〉
 〈domain:reason〉Registry policy〈⁄domain:reason〉
 〈⁄domain:cd〉
 〈⁄domain:chkData〉
 〈⁄resData〉
 〈trID〉
 〈clTRID〉1333579251148〈⁄clTRID〉
 〈svTRID〉1333579251168〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

WHOIS Status Display 

$ whois profanity.example
Domain Name: profanity.example
Domain Status: Not Registered
Notes: This name is not allowed by the policy of this registry, and cannot be registered

〉〉〉 Last update of WHOIS database: 2012-04-04T10:55:27.634Z 〈〈〈

----------------------------------------

Registered | Status ʺPending Activationʺ

The Activation and Confirmation requirements run in parallel to Grace, MIN, Pending Delete, Pending Purge and other SRS states. As soon the application is lodged via the SRS EPP and WHOIS servers will return the following.
 
EPP domain:info Status 

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ309ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:name〉pending.example〈⁄domain:name〉
 〈domain:roid〉1234-CoCCA〈⁄domain:roid〉
 〈domain:status s=ʺinactiveʺ〉Delegation information has not been mapped〈⁄domain:status〉
 〈activation:status xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ s=ʺpendingActivationʺ〉This domain requires acceptance of AUP and registrant agreement by 2012-04-09 15:39〈⁄activation:status〉
 〈domain:registrant〉example〈⁄domain:registrant〉
 〈domain:clID〉adam〈⁄domain:clID〉
 〈domain:crID〉adam〈⁄domain:crID〉
 〈domain:crDate〉2012-04-02T03:39:55.925Z〈⁄domain:crDate〉
 〈domain:exDate〉2013-04-02T03:39:55.942Z〈⁄domain:exDate〉
 〈domain:authInfo〉
 〈domain:pw〉example〈⁄domain:pw〉
 〈⁄domain:authInfo〉
 〈⁄domain:infData〉
 〈⁄resData〉
 〈extension〉
 〈activation:extension xmlns:activation=ʺhttps:⁄⁄production.coccaregistry.net⁄cocca-activation-1.0ʺ〉
 〈activation:url〉
 https:⁄⁄registry.example⁄activate.jspʺactivationCode=Q7DCanzCN1REmVnB1gjVIasJnLLMa4pacVRLn6ev9kc6sFppcs7FHLfX3PLPM3x0
 〈⁄activation:url〉
 〈activation:link〉
 ⁄activate.jspʺactivationCode=Q7DCanzCN1REmVnB1gjVIasJnLLMa4pacVRL n6ev9kc6sFppcs7FHLfX3PLPM3x0
 〈⁄activation:link〉
 〈⁄activation:extension〉
 〈⁄extension〉
 〈trID〉
 〈clTRID〉TR-2〈⁄clTRID〉
 〈svTRID〉1333581885177〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

WHOIS Status Display Example

$ whois pending.example
Domain Name: pending.example
Domain ID: 12345-CoCCA
WHOIS Server: whois.example
Referral URL: 
Updated Date: 2012-02-07T03:51:17.543Z
Creation Date: 2010-03-04T04:15:10.423Z
Registry Expiry Date: 2015-07-04T04:15:10.434Z
Sponsoring Registrar: Example Registrar
Sponsoring Registrar IANA ID: 1234
Domain Status: pendingActivation

Registrant ID: 12345-CoCCA
Registrant Name: Example Registrant
Registrant Organization: Example Org
Registrant Street: 1 Example Rd
Registrant City: Exampleville
Registrant State⁄Province: EX
Registrant Postal Code: 1234
Registrant Country: EX

Name Server: ns1.example.com
Name Server: ns2.example.com

DNSSEC: unsigned

Unless ICANN objects, the WHOIS server (port 43 and 443) and an EPP Domain:info query will also display the following values - after display of the values required in the EPP RFCʹs and in Specification 4 Section 1.4.

Activation Expiry Date: 2011-12-31T11:11:11Z
Contact Confirmation Expiry Date: 2011-12-31T11:11:11Z
Registration Grace Expiry Date: 2011-12-31T11:11:11Z 
Registration MIN Expiry Date: 2011-12-31T11:11:11Z

27.1.1 Contractual Considerations: 

Under the .UMMAH TLD policy all registrations are considered provisional by UMMAH DIGITAL until the Registrant accepts the .UMMAH RA and confirms the accuracy of the contact details lodged by the Registrar.

27.1.2 Behavior: 

Until such time as the domain is Activated it is parked on a UMMAH DIGITAL controlled website that displays the domains port 43 WHOIS information. The SRS ignores the registrar-submitted Name Server (ʺNSʺ) delegation information for all domains with a status of ʺPending Activationʺ and replaces them with the CoCCA parking servers. 

27.1.3 Duration: 

A provisional application may be Activated by the Registrant or Administrative Contact at any time during the first 28 days after the Registration request is lodged in the SRS. On the 29th day after registration if a domain has not already been deleted by the Registrar, UMMAH DIGITAL deems the application to have been withdrawn by the registrant and the Status is changed to ʺPending Purge ʺ Restore Not Possibleʺ.

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ2303ʺ〉
 〈msg〉Object does not exist〈⁄msg〉
 〈⁄result〉
 〈trID〉
 〈clTRID〉TR-2〈⁄clTRID〉
 〈svTRID〉1333583795929〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

EPP domain:check Status

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉〈msgQ count=ʺ309ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:chkData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:cd〉
 〈domain:name avail=ʺ0ʺ〉purge.example〈⁄domain:name〉
 〈domain:reason〉The domain exists〈⁄domain:reason〉
 〈⁄domain:cd〉
 〈⁄domain:chkData〉
 〈⁄resData〉
 〈trID〉
 〈clTRID〉1333584255405〈⁄clTRID〉
 〈svTRID〉1333584255410〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

WHOIS Status Display ( Domain Status: Excluded - Pending Purge). The Registrant and their Registrar are sent an email and EPP Polling message indicating the Status change.

On the 31st day after Registration, a domain that has not been Activated is purged from the SRS and instantly available for registration. Registrars are sent a polling message and email informing them that the domain application has been rejected and the domain has been deleted. 

27.1.4 Commercial Considerations: 

Funds are debited from the Registrars account instantly and refunded in full after 31 days if a domain is not activated and where UMMAH DIGITAL has deemed the application to register to have been withdrawn. Names that are not Activated are not delegated in accordance with the Registrants wishes and cannot be used for tasting.

27.2 Registered Activated 
Once Activated the EPP Domain:info Status is automatically changed to ʺActive - Delegatedʺ and the WHOIS display to ʺActive - Delegatedʺ.

Unless ICANN objects, the WHOIS server (port 43 and 443) and EPP Domain:info query will also display the following values - after display of the values required in the EPP RFCʹs and in Specification 4 Section 1.4.

〉Activation Date: 2011-12-31T11:11:11Z 
〉Contact Confirmation Date: 2011-12-31T11:11:11Z
〉Registration Grace Expiry Date: [Activation Date: 2011-12-31T11:11:11Z]
Note : [Grace Period expires as soon as a name is activated]
〉Registration MIN Expiry Date: 2011-12-31

27.3 Registration Grace
 A one (1) day Grace period applies to all registrations, Provisional (pending activation) registrations. If a name is Activated the Grace Period is instantly expired. This policy effectively mitigates the prospect of abuse of the .UMMAH TLD or CoCCAʹs SRS for domain tasting, kiting or other similar activity, while allowing a registrar 24 hours to reverse a registration that included a typographical error or was found to be fraudulent without incurring a commercial penalty. 

EPP domain:info Status

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ309ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:name〉pending.example〈⁄domain:name〉
 〈domain:roid〉1234-CoCCA〈⁄domain:roid〉
 〈domain:status s=ʺinactiveʺ〉Delegation information has not been supplied〈⁄domain:status〉
 〈domain:registrant〉example〈⁄domain:registrant〉
 〈domain:clID〉adam〈⁄domain:clID〉
 〈domain:crID〉adam〈⁄domain:crID〉
 〈domain:crDate〉2012-04-02T03:39:55.925Z〈⁄domain:crDate〉
 〈domain:exDate〉2013-04-02T03:39:55.942Z〈⁄domain:exDate〉
 〈domain:authInfo〉
 〈domain:pw〉example〈⁄domain:pw〉
 〈⁄domain:authInfo〉
 〈⁄domain:infData〉
 〈⁄resData〉
 〈extension〉
 〈rgp:infData xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsdʺ〉
 〈rgp:rgpStatus s=ʺaddPeriodʺ⁄〉
 〈⁄rgp:infData〉
 〈⁄extension〉
 〈trID〉
 〈clTRID〉TR-2〈⁄clTRID〉
 〈svTRID〉1333581885177〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

WHOIS Status Display 

Unless ICANN objects, the WHOIS server (port 43 and 443) and EPP Domain:info query will also display the following values - after display of the values required in the EPP RFCʹs and in Specification 4 Section 1.4.

〉Activation Expiry Date: 2011-12-31T11:11:11Z
〉Contact Confirmation Expiry Date: 2011-12-31T11:11:11Z
〉Registration Grace Expiry Date: 2011-12-31T11:11:11Z 
〉Registration MIN Expiry Date: 2011-12-31T11:11:11Z

27.3.1 Registration Grace | Behavior 
Domains deleted during Grace do NOT go into redemption and are instantly available. Domains may NOT be transferred during GRACE. The Domain Status shown in a WHOIS and EPP query during grace is ʺclientTransferProhibitedʺ.

27.3.2 Registration Grace |Commercial Considerations
A full refund equal to 100% of the registration value is applied to a registrars account for domains that are not activated in the first 24 hours. If a domain is Activated in the first 24 hours then deleted it is considered to have been deleted during the ʺMINʺ period as Grace expires on Activation. See Section 28 bellow for explanation of ʺMINʺ.

27.4 MIN Period
The MIN period is a life-cycle element that is probably unique to the CoCCA SRS - and mostly commercial in nature. The MIN period for the .UMMAH is 14 days, the MIN period starts when a name is registered.

Unless ICANN objects, the WHOIS server (port 43 and 443) and EPP Domain:info query will also display the following value - after display of the values required in the EPP RFCʹs and in Specification 4 Section 1.4.

〉Registration MIN Expiry Date: 2011-12-31T11:11:11Z

27.4.1 Registration MIN | Behavior
Domains deleted by a registrar during the MIN period do NOT go into redemption. Domains may not be transferred during MIN. (the Domain Status shown in a WHOIS and EPP query is ʺclientTransferProhibitedʺ). An EPP polling message is sent when the MIN period expires.

27.4.2 Registration MIN | Commercial Considerations
Since the Grace period is only one day - and only for domains that are not activated, UMMAH DIGITAL will give registrars a partial refund (80% of the annual registration fee) for Activated names that are deleted in the first 14 days after registration.

27.5 Renewals
Under the .UMMAH TLD RA registrants are required to confirm the accuracy of the contact details and accept the .UMMAH TLD RA, AUP and Privacy Policy with the registry within 28 days of renewal or the domain is suspended until such time as the RA is accepted and contact details confirmed.

27.6 Expiry
The SRS supports ʺregistrar configurable auto renewʺ, registrars may custom configure the auto-renew behavior via CoCCAʹs GUI. Some registrars may wish to auto renew domains on expiry while others may not. If a registrar has configured auto renew the SRS, and they have available credit, the SRS will renew the domain for the period selected by the registrar ( up to the maximum allowable ) on the day it expires. If a name expires the following would apply.

Unless ICANN objects, the SRS will automatically update the domain record so that a query of the WHOIS server (port 43 and 443) or EPP Domain:info query will also display the following value - after display of the values required in the EPP RFCʹs and in Specification 4 Section 1.4.

 〉Contact Confirmation Expiry Date: 2011-12-31T11:11:11Z
 〉Renewal Grace Expiry Date: 2011-12-31:T11:11:Z

27.6.1 Expiry Grace | Suspension
On Expiry a domain automatically enters a seven day Expiry Grace period in which the domain is Suspended by the SRS and parked on a UMMAH DIGITAL parking page. 

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺʺ〉
〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:xsi=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchema-instanceʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdʺ〉
 〈response〉
 〈result code=ʺ1000ʺ〉
 〈msg〉Command completed successfully〈⁄msg〉
 〈⁄result〉
 〈msgQ count=ʺ354ʺ id=ʺ21153ʺ⁄〉
 〈resData〉
 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xsi:schemaLocation=ʺurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdʺ〉
 〈domain:name〉suspended-expired.example〈⁄domain:name〉
 〈domain:roid〉1234-CoCCA〈⁄domain:roid〉
 〈domain:status s=ʹserverHoldʺ〉Suspended automatically〈⁄domain:status〉
 〈domain:registrant〉MI8JPiQP〈⁄domain:registrant〉
 〈domain:ns〉
 〈domain:hostObj〉ns2.example〈⁄domain:hostObj〉
 〈domain:hostObj〉ns1.example〈⁄domain:hostObj〉
 〈⁄domain:ns〉
 〈domain:clID〉example〈⁄domain:clID〉
 〈domain:crID〉example〈⁄domain:crID〉
 〈domain:crDate〉2009-05-17T21:49:34.649Z〈⁄domain:crDate〉
 〈domain:upID〉example〈⁄domain:upID〉
 〈domain:upDate〉2012-04-05T01:38:12.649Z〈⁄domain:upDate〉
 〈domain:exDate〉2011-11-17T20:49:34.644Z〈⁄domain:exDate〉
 〈domain:trDate〉2009-05-17T21:49:34.728Z〈⁄domain:trDate〉
 〈domain:authInfo〉
 〈domain:pw〉example〈⁄domain:pw〉
 〈⁄domain:authInfo〉
 〈⁄domain:infData〉
 〈⁄resData〉
 〈extension〉
 〈⁄extension〉
 〈trID〉
 〈clTRID〉TR-2〈⁄clTRID〉
 〈svTRID〉1333590323304〈⁄svTRID〉
 〈⁄trID〉
 〈⁄response〉
〈⁄epp〉

An expired and suspended name is not locked and may be renewed without a restore fee in the first seven (7) days after expiration. Suspended domains may NOT be transferred.

27.6.2 Expiry | Pending Delete - Restorable (Redemption)

On the eighth day after expiration the SRS will change the domainʹs Status to ʺPending Delete Restorableʺ for a period of 28 days. Suspended and Pending Delete domains may NOT be transferred. At any point between after day seven (7) and before day 29 a registrar may Restore a domain via EPP (RFC-3915) after restoration a domain must be renewed.

The SRS will automatically update the domain record so that a query of the WHOIS or EPP will also display the following values.

〉Redemption Expiry Date: 2011-12-31
〉Purge Date: 2011-12-31

27.6.3 Expiry | Pending Purge (No longer Restorable)

On the 29th day after expiry the SRS will change the status of the domain to ʺPending - Purgeʺ and apply a registry lock. The WHOIS status and EPP Domain:info query would be displayed as Pending Purge. The domain would stay in this state for seven (7) days until purged from the SRS 35 days after Expiry. Once purged it is available - subject to any restrictions or polices in effect at the time.

See Attached Life - Cycle Diagram

CoCCA and UMMAH DIGITAL will address abuse in the .UMMAH using policy and technology that is currently used in several dozen production TLD environments. CoCCA’s policy matrix and SRS technology is constantly being fine-tuned in response to emerging threats and best practice recommendations.

28.1 The UMMAH DIGITAL .UMMAH Policy Matrix

UMMAH DIGITAL has chosen to adopt CoCCAʹs tested acceptable use based policy matrix, recommendations for minimizing harm in TLDs, and subject the .UMMAH TLD to the CoCCA Complaint Resolution Service (ʺCRSʺ). UMMAH DIGITALʹs polices for the .UMMAH are subordinate to any ICANN consensus-based polices or requirements for gTLDs. Any individual who has a concern regarding abuse involving a .UMMAH domain, glue record, or CoCCAʹs, PCHʹs or ISCʹs network services as they relate to the .UMMAH TLD may lodge a complaint via the CoCCA CRS. The CoCCA CRS will be modified from time to time to ensure compliance with UMMAH DIGITAL and ICANN consensus policy aimed at prevention and mitigation of abuse of the DNS. 

The CoCCA best practice AUP policy matrix has been developed over the past decade and has been adopted by 16 ccTLDs. It was developed by ccTLD managers that desired to operate an efficient standards-based EPP SRS system complemented by a policy environment that addressed local concerns regarding a registrant’s ʺuseʺ of a string - as well as the more traditional gTLD emphasis on ʺrights to the stringʺ. CoCCA’s proven AUP policy matrix is well suited to the target market for the .UMMAH TLD.

A key element of CoCCA’s policy matrix is that it provides for registry-level suspensions where there is evidence of an AUP violation. The .UMMAH TLD will join other TLDs that utilize CoCCAʹs existing CRS. The CoCCA CRS provides a framework for the public, law enforcement, regulatory bodies and intellectual property owners to swiftly address concerns regarding the use of .UMMAH domains and CoCCAʹs Registry Services. The CRS can be used to address concerns regarding a domain or any resource records (by way of example, glue records) that appear in the .UMMAH zone.

The CRS procedure provides a swift, effective alternative to the court system while allowing for complaints to be handled in in a fair and equal manner and allows for all affected parties to present evidence and arguments in a constructive forum.

Under certain circumstances cases, it may be necessary for a CoCCA Complaints Officer (CCO) to trigger a Critical Issue Suspension (CIS), or a Uniform Rapid Suspension. CoCCA may suspend a domain or remove a glue (or other resource) record when there is a compelling and demonstrable threat to the stability of the Internet, evidence of criminal activity, threat to critical infrastructure or to public safety.

The intent of any CIS is to respond to abuse that may occur in a timely manner; accordingly the CoCCA CRS is a 24⁄7⁄365 service. Unlike controversial “domain seizures”, the CoCCA policy matrix facilitates CIS removal of specific records from the zone to protect the public interest but does not transfer a domain or extinguish a registration. Registrants may appeal a CIS to the CoCCA Ombudsmanʹs Office for Amicable Complaint Resolution (a free service), a CoCCA Expert for binding arbitration or to the courts. 

28.2 Contractual Framework
Under the proposed policy matrix UMMAH DIGITAL will bind registrants to a .UMMAH TLD Registrant Agreement (ʺRAʺ). This RA is a collateral agreement to any Registrar-Registrant agreement and binds all Registrants to the .UMMAH AUP, Privacy and RDDS policy, CoCCA CRS and any other requirements or dispute mechanisms mandated by UMMAH DIGITAL or ICANN. 

The .UMMAH draft Registrant Agreement, AUP Policy and Privacy and RDDS Policy are attached.

28.3 Minimizing Harm, Pro-active Measures

ICANN has expressed a concern regarding glue records for in-zone hosts. CoCCA automatically removes all references to a domain’s glue records from zones when a domain’s status is ʺSuspendedʺ or ʺPending Deleteʺ (in redemption). If a domain that has glue records is deleted by a registrar or purged by an automated process, the glue records are automatically deleted by the SRS. CoCCA does not depend on registrars to delete glue records. 

UMMAH DIGITAL will adopt the following key provisions (28.3.1-28.3.8) of CoCCA’s already field-tested policies and technology aimed at preventing and mitigating abuse. 

28.3.1 ʺTrust but Verifyʺ
Applicants for .UMMAH registrations must confirm to the registry that they agree to be bound by the registrant agreement and confirm the accuracy of contact details logged by the Registrar with the Registry. Until the Registrant or their Administrative Contact confirms the contact details with the Registry directly, views and accepts the Registrant Agreement, .UMMAH domains will be excluded from the zone and parked on a ʺpending activationʺ page. See attached Life-Cycle Policy.

Automated Activation processes are already in place for 11 TLDs currently using the CoCCA SRS. The process involves direct registry-registrant communication using email details provided to the registry by the Registrar. On registration an automated email is sent to the Registrant that contains a link, the recipient must click on the link and is directed to a web page that; 1) displays the contact information the Registrar provided, 2) displays the .UMMAH Registrant Agreement and AUP policy. Registrants must confirm the accuracy of the RDDS (WHOIS) information and agree to the policy before a domain is delegated to their nominated servers and included in the .UMMAH zone.

All responses by the Registrant are lodged against the domain’s permanent history in the SRS; the time, date and IP address are stored. CoCCAʹs Activation process allows the registry the opportunity to independently verify the accuracy of contact data supplied by the registrar, or at minimum, the existence of a functioning email. It also serves as a record of the Registrantʹs acceptance of the .UMMAH Registrant Agreement and policies. 

The SRS uses dynamically generated images as a challenge-response verification to prevent automated processes from activating domains. Although registrars are required to advise registrants of the TLD policies and conditions, with the prevalence of highly automated registration systems and expansive reseller networks it cannot be guaranteed that registrants have reviewed or agreed to the policy. CoCCAʹs Activation technology helps ensure the accuracy of WHOIS data and also that Registrants are made aware of their rights and responsibilities before a name is activated. 

The registrant or administrative contact must confirm the accuracy of the WHOIS data not only on initial registration, but also on the anniversary of registration and⁄or renewal.

On any change of Registrant, the new Registrant must accept the RA before the changes to the contacts are committed in the registry.

On any Registrar Transfer, the Registrant must agree to the Transfer before it is finalized in the SRS. This ensures that domains are not transferred without the consent of the existing registrant. The activation and confirmation technology does not involve EPP Extensions or place a burden on Registrars - if the information in the SRS is accurate and up-to-date. CoCCA activation procedures and technology described above are in use today; the technology undergoes constant refinement in response to Registrar and Registrant suggestions.

28.3.2 Registrants’ rights to a limited license

The .UMMAH Registrant Agreement and AUP limit a registrantʹs rights to a limited license to use - but not to sub-license the use of any portion of the allocated domain, subject to continuing compliance with all .UMMAH policies. 

ʺ7. Registrant Representations and Warranties. The Registrant represents, warrants, and guarantees that:

...(ii) the Registrant will not sub-license, purport to sub-license, delegate sub-domains within or otherwise permit use by persons other than the Registrant of portions of, the .UMMAH Domain name;ʺ

See attached draft Registrant Agreement for more information. 

It is increasingly common for some Registrants to register a second level domain in order to set up what amounts to a third level registry, effectively sub-licensing to third parties the use of portions of their allocated second level domain. There is significant evidence that most abuse of the DNS occurs in lower level domains created by registrants and given away or licensed to third parties. While the .UMMAH TLD policy is recursive, combating abusive activity in a TLD is complicated if the registry has no information about the user of the subordinate (lower level) domain and no way to suspend domains created by a registrant at a subordinate level. The only recourse available to UMMAH DIGITAL (where there is an actionable AUP violation involving a lower level registrant-created domain) is to suspend the super-ordinate (higher level) domain. A suspension may negatively impact third parties if the Registrant has created and sub-licensed lower level domains. The Registrant’s limited license narrows the impact of a suspension to the Registrant and limits and UMMAH DIGITAL’s liability should a higher-level domain suspension be required.

28.3.3 Fast flux mitigation

CoCCA will queue for manual intervention by CoCCAʹs Registrar Support all DNS delegation modifications that exceed four (4) requests in any 28-day period or three (3) in a one-week period. Rationale: This minimizes a registrant’s ability to frequently re-delegate a domain in order to overcome service limitations imposed by Internet service providers. Frequent re-delegation may also assist a malicious user to obscure their identity. Limiting frequent re-delegations enhances the effectiveness of service termination as a sanction by an Internet service provider. The exact thresholds for fast flux may be amended from time to time.

CoCCA also updates the .UMMAH TLD zones no more than 12 times a day, in a small TLD this is sufficient. If there is an urgent need to remove a domain or glue record from a zone, CoCCA Compliant Resolution Officers are available 24⁄7⁄365 and can propagate a zone on demand when a complaint is received that requires immediate action or propagation of a new zone. 
 
28.3.4 Anycast Resiliency 

A denial of service (DoS) on a DNS resolver from a single ISP will usually only affect a single node. All other nodes in the world will not notice anything about the attack and the rest of the Internet will thus not notice it either. A local attack therefore only affects the local neighborhood. Distributed denial of service (DDoS) attacks usually affect a few nodes only, but because the attack is spread out between nodes, so is the amount of traffic flowing to each node. With 80+ nodes and two Anycast networks, the .UMMAH TLD is well protected against abuse targeting the .UMMAH DNS resolvers. PCH and ISC constantly monitor their Anycast networks and will take action to block DoS traffic before it gets to an anycast node or remove the node from the anycast cloud. 

28.3.5 High Risk Strings

UMMAH DIGITAL will require manual intervention by the Registry Services Provider before domains that contain various strings such as ʺbankʺ, ʺsecureʺ, etc. go into the zone. A comprehensive list of high-risk strings will be compiled and advertised prior to launch. CoCCA has technology in place which allows registrars to submit an application to register a domain that may contain a high - risk string but CoCCA’s SRS will not delegate them until they are manually approved by COCCAʹs Registrar Support. CoCCAʹs Registrar Support may ask the Registrar to upload via the CoCCA GUI supporting documents (which become part of the domains permanent public record) before delegating the domain.

This technology is in place and has been field tested over the past several years. It was developed in response to the conficker virus threat and a request by the Egyptian government for tools related to the launch of the .masr IDN TLD.

28.3.6 UMMAH DIGITAL CERT Law Enforcement Collaboration

UMMAH DIGITAL will provide CERT, Law Enforcement and other interested parties direct read-only Access to the SRS on application for research and other activities related to identifying and mitigating abuse. CoCCA already provides direct access to the Australian Government CERT and thesecuredomain.org. The CoCCA SRS contains a variety of login types with various permissions, one such type is ʺCert⁄Law Enforcementʺ which allows GUI - based query as well as EPP and Zone Access. Under the access agreement the information in the SRS can be shared with other CERTS or Law Enforcement entities. CERT or Law Enforcement may under certain situations trigger an automated suspension of a domain, this is provided for in the .UMMAH RA.

ʺUMMAH DIGITAL may delegate authority to: 
(i) investigate any breach or potential breach of .UMMAH TLD Policies; and
(ii) take action to cure or sanction any breach or potential breach of .UMMAH TLD Policies;
including the authority to automatically suspend use of the .UMMAH Domain name upon detection by a service provider or notification from an Internet security agency that the .UMMAH Domain name may contain malicious software or violate the .UMMAH AUP.

In such circumstances neither UMMAH DIGITAL, its employees, delegees, agents, assigns nor the external service provider or Internet security agency triggering the suspension shall be liable to the Registrant or any other person on account of any service disruption or loss, irrespective of the nature of that loss.ʺ

See attached for the RA in entirety. 

CoCCA may provide access to other CERTS free of charge on request. Where an application for free access is rejected, any entity may purchase a Premium RDDS subscription that gives similar level of access. CoCCA will automate checks against third party databases of suspected malicious hosts and domains when suitable APIʹs can be identified and as APIʹs become available. 

28.3.7 Domain Scans

The .UMMAH Registrant Agreement allows the Registry Services provider to scan or contract the scanning of domains for malware or other exploits. Scanning all domains in TLD has been tested by CoCCA but has been of limited use as most malicious use is in the third or lower level domains and cyber criminals have developed technical solutions to avert detection by common malware scanning methods. Where there is a suspicion of malicious code or activity, or if scanning technology improves CoCCA may scan websites ending in .UMMAH. 

From the .UMMAH RA (attached)

ʺ(v) The Registrant grants an irrevocable license to UMMAH DIGITAL, its agents and assignees to access, monitor and scan any content published, including where such processes involve an intrusion or cause modification of data, providing such scanning is for the purpose of identifying internet security vulnerabilities or the presence of malicious software or content capable of causing harm or disruption to the systems of other Internet users.ʺ

28.3.7 Notify Services

Subscribers to CoCCAʹs Premium RDDS service may create lists of domains or strings (including using java regular expressions), when a domain that matches one of these is registered - in any TLD in the CoCCA SRS, the subscriber will be notified by email and⁄or EPP polling message.

28.3.8 Malware ⁄ Malicious Domain Polling

CoCCA will continuously poll against trusted databases for domains or subdomains that have been associated with malicious activity. By way of example; CoCCA will poll thesecuredomain.org for any .UMMAH domain or subordinate “registrant created” domain that matches a domain in the SRS, if a match is found the information will be extracted from the third party database and become part of the domain’s record. If there are multiple independent matches the domain may be automatically suspended. 

28.4 CoCCA Complaint Resolution Service

The Complaint Resolution Service (ʺCRSʺ) has been operational for six years. It is collateral to any ICANN required complaint or dispute Services. It provides a transparent, efficient and cost effective way for the public, law enforcement, regulatory bodies and intellectual property owners to have their concerns addressed regarding use of a TLD manager’s network or CoCCAʹs SRS services. The CRS provides a single framework in which cyber-crime, accessibility of prohibited Internet content and abuse of intellectual property rights are addressed. The framework relies on three tiers of review: immediate action to protect the public interest, amicable complaint resolution led by an independent Ombudsman, and where applicable, adjudication by an Expert. The CRS provides an efficient and swift alternative to the Courts. The COCCA CRS is collateral to any ICANN UDRP, URS or other mandated dispute or complaint resolution services. 

Third party complaints against a registrant’s use of a domain may be addressed through CoCCAʹs CRS protocol - or alternatively depending on the nature of the complaint, UDRP. The .UMMAH AUP generally deals with a broader range of issues than are covered by the ICANN policy and may be more appropriate. When a complaint is filed, a CoCCA Complaints Officer (CCO) ensures that it meets the necessary criteria. If it does, notice is sent to involved parties and CRS Proceedings begin. If a Registrant responds to the complaint, it will be referred to an Ombudsman for Amicable Complaint Resolution (ACR). If ACR does not achieve acceptable resolution, the complainant may request binding arbitration by a CoCCA Expert.

In some cases, a Critical Issue Suspension (CIS) may become necessary. If a CoCCA Complaints Officer deems a CIS to be necessary, the domain, or other resource records in a zone will be disabled (removed from the zone) until a enduring resolution is found using the CRS protocol. A CIS does not terminate the license to a domain, it simply removes it from the zone.
 
A copy of the current CoCCA CRS Policy and Procedures and Overview Diagram is attached. 

Rights Protection is something CoCCA has prioritized by necessity throughout its nine-year history. The policy matrix adopted by UMMAH DIGITAL for the .UMMAH TLD will subject registrants to several layers of complaint and dispute resolution - the CoCCA Complaint Resolution Service, UDRP proceedings and URS proceedings. UMMAH DIGITAL will employ established methods for handling Sunrise and Trademark Claims as outlined below, guided by the Specification requirements of the proposed Registry Agreement.

CoCCA offers a wide range of services including, a wildcard registration program to block variants of a domain for Trademark holders as well as an ʺAlertʺ service included in the Premium RDDS service that any interested party can subscribe to - alerting them if a specific string is registered in any CoCCA managed TLD. CoCCA recognizes that ICANN has not completed the Trademark Clearing House (TMCH) program. CoCCA has in the past integrated it’s SRS with the Clearinghouse for Intellectual Property, while CoCCA cannot fully describe the details of implementation for this application based on incomplete work, CoCCA intends to comply and⁄or exceed the final ICANN program.

In particular, CoCCA offers the following procedures to help protect the rights of trademark owners:

Sunrise Services
Trademark Claims Service
Name Selection Policy
Acceptable Use Policy
Unqualified Registration Safeguards 
Wildcard Registrations⁄Alert services
Clearinghouse of Intellectual Property API
Thick WHOIS
RPM Compliance auditing of Registrars
UDRP, URS, PDDRP and RRDRP and CoCCA CRS
Limited License
Rapid Takedown & Suspension (Critical Issue Suspensions)
Scanning & Malware Mitigation
Phishing Mitigation 
Fast Flux Mitigation
DNSSEC Deployment 
Law Enforcement and Anti-Abuse Community Collaboration

29.1 Registration Abuse Prevention Mechanismʹs Pre Launch

To support UMMAH DIGITALʹs objectives, CoCCA will implement specific measures in compliance with ICANN’s Applicant Guide Book. At a minimum, ICANN states that UMMAH DIGITAL must offer sunrise registration for a period of thirty days during pre-launch in conjunction with the Trademark Clearing House.

CoCCA’s RPM framework and technology contains several levels of safeguards to deter unqualified registration and other malicious behaviors during pre-launch. This not only exceeds requirements, but also provides customers of the TLD predictably in service offerings and protections.

29.1.1 Sunrise & Land-rush

To meet the ICANN requirement of a 30-day Sunrise process for those with verifiable trademark rights or owners of exact matching strings in other TLDs, CoCCA shall implement for UMMAH DIGITAL a Sunrise period for domain registrations. The validations of domains names that are an identical match will occur via the Trademark Clearinghouse via notice by UMMAH DIGITAL or UMMAH DIGITAL approved Registrar. The CoCCA SRS will store and make available via the SRS all documents lodged in support of a Sunrise Application.

During the Sunrise, UMMAH DIGITAL will be responsible for determining eligibility of the registration and it will require the Registrant to affirm that they meet Sunrise Eligibility Requirements (SERs) and incorporate a Sunrise Dispute Resolution Policy (SDRP).

The Sunrise will be followed by a 30 day Registration Land-rush for members of the community⁄business owners⁄non-governmental organizations, etc. The process will end in General Availability or Open Registration. Eligible Trademark holders may continue to register marks on an ongoing basis.

29.1.2 Trademark Claims Service

Per ICANNʹs Applicant Guide Book, UMMAH DIGITAL is required to provide a Trademark Claims service during pre-launch phases and for at least 60 days from the date of open registration. During the Trademark Claims period, UMMAH DIGITAL or the Registrar will provide notice to the prospective registrants where an identical match is identified in the Trademark Clearinghouse. The notice will include warranties that the prospective Registrant must understand and adhere to that the domain will not infringe on the rights of the respective Trademark holder. A notice will also be sent to the designated Trademark holder of marks where an identical match has been identified.

29.1.3 Name Selection Policy

The .UMMAH TLD will enforce a name selection policy that ensures that all names registered in the gTLD will be in compliance with ICANN mandated technical standards. These include restrictions on 2 character names, tagged names, and reserved names for Registry Operations. All names must also be in compliance with all applicable RFCs governing the composition of domain names. Registrations of Country, Geographical and Territory Names will only be allowed in compliance with the restrictions as outlined in the answer to Question 22.

Additionally, UMMAH DIGITAL requires that domain names within the .UMMAH TLD should consist of proper characters unique within top-level domain, followed by the characters
ʺ.UMMAHʺ. Domain names should meet the following technical requirements; They shall:
* contain no more than 63 characters;
* begin and end with a letter or a digit;
* contain no characters different from letters, figures and a hyphen (allowable characters are the letters of the Roman alphabet; capital and lowercase letters do not differ);
* contain no hyphens simultaneously in the third and forth positions.

Acceptable Use Policy

UMMAH DIGITAL has developed an Acceptable Use Policy (AUP) framework that is referenced in the answer to Question 28. This AUP clearly defines what type of behavior is expressly prohibited in conjunction with the use of a .UMMAH domain name. UMMAH DIGITAL will require, through both the Registry Registrar Agreement (RRA), and a Registry Registrant Agreement (RA) that this AUP be accepted by a registrant prior to activation of a domain in the .UMMAH TLD.

29.2 Rights Protection Mechanismʹs Post Launch

CoCCA offers a suite of post-launch Rights Protection Mechanisms. UMMAH DIGITAL, supported by CoCCA services, will promote the security and stability of the TLD with the following:

* Unqualified Registration Safeguards
* Wildcard Registration ⁄ Alert services
* Clearinghouse of Intellectual Property API
* Thick WHOIS
* RPM Compliance auditing of Registrars
* UDRP, URS, CRS
* Limited License
* Rapid Takedown & Suspension (Critical Issue Suspensions)
* Phishing Mitigation
* Scanning Malware Mitigation
* Fast Flux Mitigation
* DNSSEC Deployment
* Law Enforcement and Anti-Abuse Community Collaboration

29.2.1 Unqualified Registration Safeguards

UMMAH DIGITAL plans to adopt the CoCCA Acceptable Use Policy (AUP) and Complaint Resolution Service Policy (CRS) as part of the operation of the .UMMAH gTLD.

The CoCCA model differs from the ʺclassicʺ gTLD shared registry system in that Registrants are bound by a collateral agreement between themselves and the TLD Operator. This collateral agreement binds them to the .UMMAH TLD AUP policy, RDDS policy, CoCCAʹs Complaint Resolution Service and well as UDRP and URS. The .UMMAH AUP policy (attached) contains a variety of provisions aimed at protecting rights:

“1.1. UMMAH DIGITAL’s Network or .UMMAH Registry Services provider and .UMMAH Domain names must be used only for lawful purposes and must comply at all times with this AUP. The creation, transmission, distribution, storage of, or linking to any material in violation of applicable law or regulation or this AUP is prohibited. This may include, but is not limited to, the following:
(1) Communication, publication or distribution of material (including through links or framing) that infringes upon the intellectual and⁄or industrial property rights of another person. Intellectual and⁄or industrial property rights include, but are not limited to: copyrights (including future copyright), design rights, patents, patent applications, trade marks, rights of personality, and trade secret information. 
(2) Registration or use of a .UMMAH Domain name in circumstances in which, in the sole discretion of UMMAH DIGITAL:
(a) The .UMMAH Domain name is identical or confusingly similar to a personal name, company, business or other legal or trading name as registered with the relevant country agency, or a trade or service mark in which a third party complainant has uncontested rights, including without limitation in circumstances in which:
(i) The use deceives or confuses others in relation to goods or services for which a trade mark is registered in Gambia, or in respect of similar goods or closely related services, against the wishes of the registered proprietor of the trade mark; or
(ii) The use deceives or confuses others in relation to goods or services in respect of which an unregistered trade mark or service mark has become distinctive of the goods or services of a third party complainant, and in which the third party complainant has established a sufficient reputation in Gambia, against the wishes of the third party complainant; or
(iii) The use trades on or passes-off a .UMMAH Domain name or a website or other content or services accessed through resolution of a .UMMAH Domain as being the same as or endorsed, authorized, associated or affiliated with the established business, name or reputation of another; or 
(iv) The registration or use may tend to mislead or deceive Internet users or consumers in breach of UMMAH DIGITAL policy, or the laws of Gambia; or
(b) The .UMMAH Domain name has been used in bad faith, including without limitation the following:
(i) The User has used the .UMMAH Domain name primarily for the purpose of unlawfully disrupting the business or activities of another person; or
(ii) By using the .UMMAH Domain name, the User has intentionally created a likelihood of confusion with respect to the third party complainant’s intellectual or industrial property rights and the source, sponsorship, affiliation, or endorsement of website(s), email, or other online locations or services or of a product or service available on or through resolution of a .UMMAH Domain name; or
(iii) For the purpose of selling, renting or otherwise transferring the Domain name to an entity or to a commercial competitor of an entity, for valuable consideration in excess of a User’s documented out-of-pocket costs directly associated with acquiring the Domain Name; or
(iv) As a blocking registration against a name or mark in which a third party has superior intellectual or industrial property rights.
(3) A .UMMAH Domain name registration which is part of a pattern of registrations where the User has registered domain names which correspond to well known names or trade marks in which the User has no apparent rights, and the .UMMAH Domain name is part of that pattern. 
(4) The .UMMAH Domain name was registered arising out of a relationship between two parties, and it was mutually agreed, as evidenced in writing, that the Registrant would be an entity other than that currently in the register.
(5) Unlawful communication, publication or distribution of registered and unregistered know-how, confidential information and trade secrets.
(6) Publication of web content which, in the opinion of the UMMAH DIGITAL:
(a) is capable of disruption of systems in use by other Internet users or service providers (e.g. viruses or malware);
(b) seeks or apparently seeks authentication or login details used by operators of other Internet sites (e.g. phishing); or
(c) may mislead or deceive visitors to the site that the site has an affiliation with the operator of another Internet site (e.g. phishing).
(7) Communication, publication or distribution, either directly or by way of embedded links, of images or materials (including, but not limited to pornographic material and images or materials that a reasonable person as a member of the Internet community of Gambia and⁄or of the Islamic community would consider to be obscene or indecent) where such communication, publication or distribution is prohibited by or constitutes an offence, whether incorporated directly into or linked from a web site, email, posting to a news group, Internet forum, instant messaging notice which makes use of domain name resolution services in the .UMMAH TLD. 
Material that a reasonable member of the community of Gambia and⁄or of the Islamic community would consider pornographic, indecent, and⁄or obscene or which is otherwise prohibited includes, by way of example and without limitation, real or manipulated images depicting pornography, bestiality, excessively violent or sexually violent material, sexual activity, material containing detailed instructions regarding how to commit a crime, an act of violence, or how to prepare and⁄or use illegal drugs, material that promotes violence or hatred against individuals or groups on the basis of age, gender, race, ethnic origin, sexual orientation, religion, disability or veteran status, and material that promotes war, acts of terrorism, bullying or social discord. ʺ

Although registrars are required to advise registrants of the TLD policies and conditions, with the prevalence of highly automated registration systems and expansive reseller networks it cannot be guaranteed that registrants have reviewed or agreed to the policy. An email reiterating these policies will be sent to each registrant to ensure that new applicants are made aware of and confirm their agreement to the RA and .UMMAH TLD policies before a domain is delegated with the Registrants nominated hosts.

The same Activation process allows CoCCA the opportunity to verify the accuracy of customer data supplied by the registrar, the use of dynamically generated images as challenge-response verification prevents automated processes from activating domains.

29.2.2 Wildcard Registrations

CoCCAʹs SRS currently supports a Wildcard Registration option, which it will extend to all new gTLDs in which a brand owner⁄trademark holder may register a domain and then upload evidence of the trademark or other asserted rights via PDF in the SRS GUI. 

The Registrant may then they apply online to request a *.name or other wildcard block using java regular expressions for that text string. CoCCA will manually review the request for potential conflicts with other strings or generic words. CoCCA and the brand owner (or their agents) will work jointly to develop Wildcard logic which best achieves the desired result without negatively impacting other SRS users.

If approval is granted, an attempt to register any domain that triggers the wildcard string returns ʺnot available for policy reasonsʺ via EPP or GUI. A WHOIS query would return the information on the Primary domain. The CoCCA SRS treats any match as a variant of the Primary. Updating the WHOIS contact information, transfer of the Primary to another registrar etc. are automatically reflected in the variants.

The domain must be kept current and WHOIS details up to date in order for the Wildcard Registration to remain in effect. If the Primary registration lapses or is subject to a CoCCA CRS ruling, UDRP, or URS that results in a transfer of the domain to another entity, the Wildcard is removed.

29.2.3 Alert Services

Subscribers to the Premium RDDS service may request email and⁄or EPP polling alerts if a domain matching a given string is registered.

29.2.4 Clearing House for Intellectual Property (CHIP)

CHIP is a new technology that is designed to allow trademark owners to efficiently and effectively safeguard and enforce their rights on the Internet, and in particular in the domain name space. CoCCA and IP Clearinghouse, the company that operates CHIP, have collaborated in the past to allow trademark owners to retroactively (or proactively) associate trademark information with specific domain names. This technology is available but may or may not be used depending on the outcome of developments with ICANNʹs gTLD Trademark Clearinghouse.

As a result of the project with the CHIP, CoCCA has already gained valuable experience integrating with an external database to validate and confirm rights to a domain.

29.2.5 Thick WHOIS

CoCCA will provide Thick WHOIS to enhance accessibility and stability and reduce malicious behavior thereby promoting increased rights protection mechanisms and investigations, where applicable. All WHOIS services meet Specification 4 of the Registry Agreement in support of Thick WHOIS. The agreement between UMMAH DIGITAL and its Registrants specifies that Registrant information should be true, complete and accurate. Given the current state of WHOIS, CoCCA will adapt to new formats and protocols as ICANN or its agents enact them.

CoCCAʹs validation⁄activation technology helps ensure the accuracy of contact information prior to activation, renewal and transfer of a domain.

29.2.6 Registrar Relationship

UMMAH DIGITAL views the protection of legal rights of a user’s domain name and that of trademark owners as a strategic imperative to operating a successful TLD. Therefore, only ICANN accredited Registrars will be used and be bound to the registry-registrar agreement. Certain components of the RPM framework will be administered on behalf of UMMAH DIGITAL. To ensure compliance with designated RPMs, CoCCA will conduct annual reviews and enforce non-compliance where necessary. In cases where Registrars fail to meet UMMAH DIGITAL standards, the Registrar will lose its certification to register domains in the .UMMAH TLD until all issues are resolved.

29.2.7 Uniform Dispute Resolution Policy (UDRP)

The UDRP is a proven rights protection mechanism whereby complainants can object to a domain registration via a UDRP provider. The Registrant in question has the opportunity to respond to the complaint and defend its registration and good-faith use. The UDRP provider and assigned panel provide a decision based on the information submitted by both the complainant and the respondent. Where the complainant is successful in proving a bad faith registration, ownership of the domain will be transferred accordingly and in line with ICANN policy. Conversely, where the complainant is unable to prove bad faith, the domain registration will remain with the assigned Registrant. Registrars of UMMAH DIGITAL must implement and respond to UDRP policy where applicable. Penalties will apply where Registrars are found to be in breach.

29.2.8 Uniform Rapid Suspension (URS)

CoCCA will implement the Uniform Rapid Suspension System (URS) per the Applicant Guidebook. If an infringement is discovered, the complainant may file an objection with a URS provider. The URS provider will investigate compliance via an administrative review. Upon a successful review, the URS provider will notify UMMAH DIGITAL to place the domain in question in lock status within twenty-four (24) hours of receipt of notice, meaning that no changes to registration data will occur, but the domain continues to resolve. Upon lock of the domain, UMMAH DIGITAL will notify the URS Provider and the URS Provider will notify the Registrant who will have an opportunity to respond. If the complainant proves the domain is used in an abusive manner, the domain name will be suspended for the remainder of the registration period and will resolve to an informational site provided by the URS provider. The WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration and will continue to display the original Registrant information except for the redirection of the nameservers. The complainant will have the opportunity to extend the registration for one additional year. Conversely, if the evidence does not result in a successful determination of abuse, the URS Provider will contact CoCCA and controls of the registered domain will be returned to the Registrant.

29.2.9 Post-Delegation Dispute Resolution Procedure (PDDRP)

Per the Applicant Guidebook, UMMAH DIGITAL is required to implement the Post-Delegation Dispute Resolution Procedure (PDDRP) that allows a complainant the right to object to UMMAH DIGITAL’s manner of operation or use of the gTLD. A PDDRP provider will accept objections and perform a threshold review. CoCCA, as UMMAH DIGITAL’s agent, will respond to complaints as necessary to defend the operation and use of UMMAH DIGITAL’s .UMMAH gTLD.

29.2.10 Registration Restriction Dispute Resolution Procedure (RRDRP)

The Registration Restrictions Dispute Resolution Procedure (RRDRP) outlines the resolution proceedings whereby the Complainant determines that UMMAH DIGITAL has failed to comply with its defined registration restrictions. The parties to the dispute will be the gTLD registry operator and the harmed established institution where proper standing has been reviewed and confirmed. A successful complaint proves that the complainant is a defined community and that a strong association exists between it and the gTLD string. Further proof must be submitted that UMMAH DIGITAL violated its community-based restrictions and that measurable harm occurred. Upon administrative review of the complaint, UMMAH DIGITAL will file a response within 10 days of the filing.

If the complainant is determined to be the prevailing party, UMMAH DIGITAL will pay all Panel and Provider fees incurred, including filing fees. If UMMAH DIGITAL is found to have violated its registration restrictions, UMMAH DIGITAL will implement all remedial measures outlined by the Expert Panel, including cases where registration suspension may occur. UMMAH DIGITAL recognizes that this procedure does not preclude entities seeking remedies in courts of laws.

29.2.11 Limited License
The .UMMAH Registrant Agreement grant registrantʹs a right to a limited license to use (but not to sub-license the use of any portion of) the .UMMAH domain, subject to continuing compliance with all policies in place during that time.

29.2.12 Rapid Takedown & Suspension

CoCCA, at UMMAH DIGITAL’s request, will comply with any properly lodged takedown or suspension request. Historically, these types of requests are either based on court orders from a competent jurisdiction, or derived from a request from law enforcement. Under the .UMMAH policy, suspensions are not limited to URS or such requests. The CoCCA CRS has provisions that allow CoCCA Complaints Officers to trigger Critical Issue Suspensions (CIS) based on an AUP complaint lodged by a member of the public, or that arise based on malware scanning or evidence of malicious activity.

Before any suspension, CoCCA CRS officers will follow the auditable, formal CRS procedures. In cases where a registered domain is to be suspended or removed from the zone, CoCCA will follow its audit-able procedure documenting the incident number, date, time, domain name, threat level, description and reason for the take down or suspension.

The Ombudsman, Registrar, and Registrant will be notified at the time of a CIS or execution of an URS order. See attached CoCCA CRS.

29.2.13 Phishing Mitigation
CoCCA will establish and act upon the results of a regular poll against one or more trusted databases for phishing sites operating the domain (in second level or subordinate domains) within the TLD. Phishing activity most often occurs through a subordinate domain, rather than a directly registered second level domain. For this reason the registry should query for any wild-card occurrence of a domain that has been flagged as a phishing site or one that contains malware. CoCCA is currently investigating this technology for use in ccTLDs and will deploy it for the .UMMAH gTLD if it proves effective.

29.2.14 Malware Mitigation
Where commercially sensible, or a risk factor has been identified, CoCCA will perform automated and regular scanning for malware for all domains (or a subset of domains) in the registry. Often, Registrants are unaware and compromised by malware deployments. Scanning for malware may reduce occurrences of this type of abusive behavior for registered domain names in the .UMMAH TLD.

29.2.15 DNSSEC Deployment
As part of UMMAH DIGITALʹs mission to maintain a highly secure and stable TLD, CoCCA will implement DNSSEC as part of its backend registry services. DNSSEC helps mitigate, for example, pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. DNSSEC protects the DNS system from abuse threats in the following aspects:

29.2.16 Security of Domain Resolution
DNSKEY⁄RRSIG provide authentication and integrity verification to ensure data will not be compromised during transmission. The CoCCA name server trust anchor is signed by the public key and then delivered to the Interim Trust Anchor Repository (ITAR) for TLD verification. NSEC resource records will also be used to verify negative response messages of queried resource records to ensure deletion does not occur during transmission.

29.2.17 Security of Zone File Distribution
TSIG allows communication among authentication servers to ensure that it is the correct server and that data is not compromised during transmission.

29.2.18 Law Enforcement and Anti-Abuse Community Collaboration

CoCCA does and will continue to cooperate closely with anti-abuse communities, experts, and law enforcement in the mitigation and prevention of abuse behavior. Not only will best practice be shared, but also collaboration on the latest issues will remain a priority. In addition to collaboration, instances may take the form of early notification by a security agency of malicious content. Another form of cooperation may be the provision of user information (including historical and non-publicly available information, where available) to the security agency, to assist in identification of wrongdoers. Ongoing cooperation between security agencies and the registry operator facilitates the ability for both the registry and law enforcement to react promptly to threats, potentially minimizing harm. With respect to suspensions, the registrant will be given an opportunity to provide a remedy for the issue via automated processes but given the time sensitive nature of criminal activity, automated suspension based on triggers⁄flags, or at the request of law enforcement may be enabled.

29.2.19 Super-Locks
Critical or High Value domains can be manually ʺSuper Lockedʺ in the registry to ensure they are not removed from the zone, become a victim of social engineering or are suspended inadvertently by automated suspension technology. CoCCA’s super-lock technology requires domains to be locked and unlocked by designated staff at a Registrar using OTP tokens.

29.3 Resource Plans
UMMAH DIGITAL will dedicate 2 full time professionals to coordinate the operation of the .UMMAH gTLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .UMMAH gTLD, including operation of the CRS and URS response on a 24⁄7⁄365 basis.

As the .UMMAH gTLD will also heavily rely on community support, it is also expected that members of the community will help UMMAH DIGITAL modify the policies and procedures that govern the operation of the gTLD. The following CoCCA team members will be used to support the rights protection plan: CoCCA CRS Officers, the CoCCA Ombudsman and CoCCA Expert Panelists.

CoCCA acting as registry services provider maintains a resource model to meet the demands of RPM implementation and on-going operation of the protection mechanisms.

The CoCCA workforce-staffing model is sized to provide the appropriate services for each managed TLD. Given the dynamic nature of technologies and innovation, the CoCCA staffing model is constantly reviewed and adjusted to achieve optimization without sacrifice to customer satisfaction and service level requirements. In cases where growth dictates an increase in staff, CoCCA maintains a proven staffing process for acquiring qualified candidates. Details of staffing resource plans for UMMAH DIGITAL can be found in response to questions of the Financial Projections section of the application.

There are eight CoCCA CRS Officers⁄COCCA NOC Support Officers whose role is to monitor Registry Services, review Complaints and liaise with Law Enforcement CERTʹs as required.

The complaints are dealt with in accordance with the CRS and AUP⁄Registrant Agreement, which allows the CRS officers discretion to suspend a domain instantly or send the complaint to the Ombudsman for amicable complaint resolution. CRS officers are available twenty-four hours a day, seven days a week, and three hundred and sixty five days a year.

Given the estimated registration volumes of 9,000 in Year 1, 10,800 in Year 2 and 12,960 in Year 3, respectively, in UMMAH DIGITAL’s Template 1: Most Likely Financial Projections attached to Question 46, CoCCA estimates it will require the following personnel to support the RPM implementation and operations for UMMAH DIGITAL:

* Complaint Resolution Service Officers: 8
* Complaint Resolution Expert - Minimum of Eight
* Ombudsman - One

UMMAH DIGITAL and CoCCA desire to ensure the highest levels of security are applied and maintained for all elements in the chain that ultimately result in the resolution of a .UMMAH TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .UMMAH TLD as described below.

30.1 DNSSEC - Facility for Key Storage
For reasons of economies of scale and because CoCCA has a nearly decade long relationship with PCH, the .UMMAH key is to be stored offline at a Singapore facility hosted by the National University of Singapore, on behalf of the Singaporean Infocomm Development Agency (IDA), other DNSSEC key-store facilities that are part of PCHʹs project are hosted in Zurich by SWITCH, the Swiss national research and education network and at a U.S. facility hosted by Equinix in San Jose California. The PCH DNSSEC project facilities mirror the security and processes used by ICANN for maintenance of the root. 

See Attachment PCH_SG_Backgrounder.pdf

30.1.1 Signature of the .UMMAH

The .UMMAH zones generated by the CoCCA SRS will include the DS records submitted by registrars, zones will be transferred from CoCCA’s hidden signing master DNS to four PCH inbound masters using AXFER ⁄ IXFER and TSIG. PCH will transfer the zones using IXFR ⁄ AXFRE and TSIG to their signer servers in Frankfurt and Palo Alto. The signed zone is then exported to PCH’s two outbound DNSSEC DNS for secure ASXFR ⁄ IXFR TSIG transfer back to CoCCA’s inbound DNSSEC master in Sydney. Key signing keys and zone signing keys are to be rolled out in accordance with best practices and ICANN requirements. CoCCA and PCHʹs DNSSEC implementation fully adheres to applicable RFCʹs and to the requirements of Specification 6, section 1.3.

30.1.2 Secure Distribution of the Signed Zones

CoCCA has employed the use of a double Anycast and Unicast network for the purpose of distributing signed zones across the DNS. Due to CoCCA’s desire to ensure that this process is not compromised, CoCCA logs and monitors the zone signing and distribution process, and also ensures that the management of signed zones is performed by CoCCA.

On receipt of the signed zones from PCH, CoCCA will perform some basic validation against the zones sent to PCH, and then transfer these zones onto a hidden distribution master DNS which will transfer zones via TSIG and IXAFR⁄ AXFR to ISCʹs SNC platform, PCHʹs Anycast platform and CoCCA’s Unicast DNS servers. If a critical issue was found that was impacting both the primary and secondary SRS, and if instructed by CoCCA, PCH may distribute the zones to their own Anycast network, the ISC SNS Anycast network and the CoCCA Unicast nodes.

The procedures above have been tested by ccTLDs on CoCCA’s SRS platform.

30.2 Securing the .UMMAH DNS infrastructure and Nodes

The .UMMAH TLD will rely on ISC’s and PCH’s Anycast networks and CoCCA’s Unicast for resolution. ISC authors BIND and pioneered the use of DNSSEC and Anycast technology, PCH manages what is arguably the largest, most geographically dispersed Anycast network, CoCCA currently operates Unicast TLD servers for 12 TLDs. All three entities utilize best of class technology and have rigorous security policies in place to secure, monitor and respond to threats that may compromise the resolution of the .UMMAH TLD. 
 
Both PCH and ISC are members of NSP-Sec and have BGP sinkhole capabilities. Both organizations are well positioned and able to coordinate with ISPs that may be transiting or sourcing Denial of Service attacks (DoS) or other attack traffic to mitigate it closer to its source. The geographically diverse PCH and ISC Anycast services are extremely resilient against DoS attacks, if a node fails or is otherwise compromised, it will swiftly be taken out of the PCH or ISC Anycast cloud, causing traffic to flow to other nodes with minimal or no service disruption. The two independently operated and managed Anycast networkʹs total distributed capacity will allow the .UMMAH to absorb even a coordinated DoS attack originating from multiple locations at once. 

The geographically diverse Anycast network proposed for .UMMAH necessitates locating dozens of nodes in a variety of co-location facilities varying from Tier 4 to Tier 2 - and each facility has different security policies for physical access. From a security and stability perspective, the critical issue is that all nodes be monitored in real time by PCH, ISC and CoCCA and any node that experiences SLA issues (or is otherwise compromised) is swiftly taken offline or out of the Anycast network. Under CoCCAʹs agreements with PCH and ISC, any SLA or security issues with any node in their respective Anycast networks is to be reported immediately so that CoCCA may advise registrars or take any other appropriate action.

30.3 CoCCA’s Sydney SRS Security Policy 

30.3.1 CoCCA SYD NOC | SRS Physical Access
CoCCA’s primary NOC is located at Global Switch in the Sydney CBD, an enhanced Tier-3 facility and one of the largest carrier neutral data centers in the southern hemisphere. CoCCA’s SRS servers are housed in a dedicated, caged rack provided by PIPE networks, PIPE also provides CoCCA with the primary bandwidth used by the Sydney SRS.

In order to gain physical access to CoCCA’s servers, an individual must be pre-authorised by CoCCA, pipe and Global Switch - and have formally been inducted by Global Switch. Once approved to enter the facility, an individual must be inspected and be granted access by the Global Switch Security Operations Centre - which is manned 24x7 by security personnel. After passing security, physical access requires passing through a mantrap. Access to the floor, pipe co-location room and master cage is controlled by key-cards with strict access control lists. 

Access to CoCCA’s cage and rack require a combination of key-cards and physical keys both of which are distributed by, and only available to, CoCCA staff. All spaces are under constant CCTV surveillance by global switch security and the PIPE Network’s NOC. 

CoCCA’s policy is to severely restrict physical access to network appliances, currently only six individuals have physical access to the CoCCA SRS in Sydney and all access is logged. CoCCA’s security policy for physical access is collateral to the Global Switch and PIPE Networks.

30.3.2 CoCCA SYD NOC | SRS Admin Remote Access

The number of individuals with the ability to directly access and administer network appliances is very small - currently six, a number not expected to grow with additional gTLDs. Remote access is only accessible through VPN with the mandatory requirement to use one time passwords (OTP) for authentication purposes. SRS server command line logins use both OTP as well as traditional username and password authentication methods - enabling each login to be traced to an individual. 

CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and UMMAH DIGITAL staff may only access the SRS via port 443 with OTP from trusted IP addresses. CoCCA NOC Support Staff, Registrar Support and Complaint ⁄ Abuse Officers and UMMAH DIGITAL staff have no physical or remote administrative access to servers or network appliances. 

30.3.3 CoCCA’s ʺpamojaʺ SRS Software Testing

In designing any security regime it is important to clearly identity potential threats and design the policy to address them. The SRS data is a compilation of publicly available data, and all information on Registrants, Registrars, and Resellers is available via WHOIS, RDDS services or Historical Abstracts. CoCCA does not store credit card or other commercially sensitive confidential information on registrants or registrars in the SRS (or elsewhere). The security threat is not theft of SRS data, it is loss of data or tampering with data. 

Information relating to the management of the Data Escrow processes performed by NCC and CoCCA Data Escrow (NZ) Limited, including information in relation to the backup policies are explained in response to question 38. The Data Escrow process ensures that data is protected against security breaches that result in the loss or unauthorized modification of SRS data, especially as the data can be recovered from several sources. The CoCCA security policy is designed to protect against un-authorized modification of production SRS data.

The only information stored in the SRS that could present a risk should the entire SRS be compromised, stolen and released ʺinto the wildʺ are SRS credentials and AuthCodes. The credentials and AuthCodes are Hashed (MD5) and Encrypted in the DB. GUI access to CoCCAʹs production systems is only granted from trusted IPʹs with a requirement for OTP use. For EPP access to the production SRS, the registrarʹs IP must be white-listed and they must connect with a CoCCA issued SSL certificate. Even if one were able to steal the SRS DB and de-crypt the login credentials or AuthCodes, other security measures such as IP address locking, OTP and CoCCA issued certificates ensure potential data thieves would not be able to use them to access CoCCAʹs production SRS or modify data. 

Securing the SRS largely requires ensuring the SRS software cannot be exploited by users. The SRS has four public facing websites, the WHOIS, RDDS, Historical Abstracts and Key Retrieval. The GUI login is not public facing. 

CoCCA uses the same ʺpamojaʺ SRS database application that it distributes to over 20+ other TLD managers. While the application is tested internally by CoCCA and other TLD manager’s, developers and systems administrators, CoCCA has a policy that each major release also be tested by an independent software testing laboratory. Currently we have contracted with Yonita (http:⁄⁄yonita.com). Yonita tests ⁄ audits the pamoja SRS application (not CoCCAʹs NOC) for:

* Security vulnerabilities 
* Standard quality defects 
* Performance anti-patterns 
* Database and transaction misuses 
* Concurrency issues 
* Architectural bad practices

30.3.4 Monitoring and Detecting Threats

CoCCA monitors network traffic and activity through automated processes and seeks to detect threats that impact the SRS and more broadly CoCCA’s Registry Services. 

PCH and ISC directly monitor and attempt to detect threats that impact the DNSSEC signing and storage facilities as well as PCHʹs and ISCʹs respective Anycast networks. Any incident that impacts the security and stability of the .UMMAH TLD in either the PCH DNSSEC facilities or nodes on the ISC or PCH Anycast networks is logged and reported to the CoCCA NOC immediately. ISC and PCH have near-real time reporting for all the Anycast nodes in their clouds and make this information available to CoCCA.

30.3.5 CoCCA SRS NOC | Essential Services Policy

CoCCA’s Security Policy mandates that only essential SRS services (production EPP, WHOIS, RDDS, and SRS GUI with limited access) are to be hosted at the Sydney NOC. 

Public facing policy websites, email servers, help-desk software, svn, GIT, team sites, OTE environments, and software development servers are all hosted externally using various commercial cloud - based services. None of these cloud-based servers are configured in such a way that they have access to any SRS services that are not normally available to the public.

30.3.6 CoCCA SRS NOC | Public Access Restrictions Policy

CoCCA’s security policy dictates that only the port 43 WHOIS server, port 443 web-based WHOIS, port 443 AuthCode retrieval site, and port 443 Historical Abstract Site and a single unicast DNS server for the .UMMAH TLD are to be publicly accessible. 

Registrars, CoCCA’s registrar support staff, law enforcement or CERTs may access the port 443 GUI interface only if their IP addresses have been white listed in advance and they authenticate using clientID, login and an OTP. CoCCA’s use of OTP tokens allows CoCCA to track activity in the SRS by individual not just loginID (username). 
30.3.7 CoCCA SRS NOC | Intrusion Detection

CoCCA Security Policy requires that all SRS traffic originating from outside the NOC be subjected to automated intrusion detection. CoCCA’s firewalls (Watchgaurd XTM) are configured for intrusion detection and are able to inspect encrypted HTTPS traffic. CoCCA’s Barracuda load balancers provide an additional layer of firewall protection, DoS and automated intrusion detection. CoCCAʹs NOC firewalls are configured in accordance with best practices with both port and application layer filtering. The load balancers are configured for NAT and are also configured for intrusion detection and DoS attacks. 

30.3.8 CoCCA SRS NOC | Auditing an Logging 

CoCCA’s Security Policy requires that all access to the SRS via the port 443 GUI is logged with originating IP, clientID, OTP (generated by security token), and that the sessions are time and date stamped. All EPP and WHIOS access logs are to be stored for seven days in the production SRS where they can be readily accessed before being archived. Firewall and VPN access is also logged.

30.3.9 CoCCA SRS NOC | Incident Response

CoCCA NOC Support staff are on hand 24⁄7⁄365 to monitor the Registry Services offered at the primary SRS in Sydney and the availability of the Failover and Escrow SRS facilities. NOC Staff perform three ʺrolesʺ:

1) monitoring the CoCCA Sydney NOC and failover SRSʹs - and a dozen or so other SRS’s that CoCCA supports;
2) registrar support for the CoCCA NOC and four other locally hosted ccTLDs; and 
3) serve as front-line Complaint Resolution Service Officers able to trigger a CoCCA Critical Issue Suspension (CIS) or Uniform Rapid Suspension on a 24⁄7⁄365 basis.

The level of SRS access and skills required to perform all three roles are similar. CoCCA NOC support staff have no VPN access or other access to appliances at the CoCCA SRS. The GUI access they have is limited to Customer Service functions, and all the applications they use (helpdesk, monitoring, accounting, email) are hosted outside the primary NOC. 

CoCCAʹs NOC support is a virtual ʺfunctionʺ performed by individuals in New Zealand, Guyana and France (additional NOC staff will be trained and other centers incorporated into the service in Q4 2012). If there is a failure in any of CoCCA’s Registry Services functions, the role of the NOC Support is to: 

1) raise the alarm with CoCCA systems administrators or developers as conditions and events dictate;
2) liaise with PIPE Networks, PCH, ISC, IANA ⁄ ICANN and registrars as required.

30.3.10 Provisioning against DNS Denial of Service attacks 

A Denial of Service (DoS) attack on a network service floods it with fraudulent requests so that there is no capacity left for legitimate requests. CoCCAʹs Anycast DNS service is outsourced to PCH and ISCʹs Anycast networks, CoCCA’s managed Unicast DNS ensures UMMAH DIGITAL has at least two ʺlast resortʺ DNS nodes under direct management. Both PCH and ISC networks provide the .UMMAH with substantial protection against DoS attacks, including Anycasting, over provisioning, and network traffic shaping. 

Both PCH and ISC utilize traffic shaping methods that rate limit the number of queries per IP address to help prevent abuse and to trigger an investigation of elevated traffic levels to see whether an attacker is testing resource limits or whether ISC or PCH should provision additional bandwidth⁄servers or remove the node temporarily. In cases of an active DoS against ISC, CoCCA or PCH each will make every effort to identify the offending traffic and its sources to squelch offending traffic at ISP borders before reaching the servers as well as augmenting capacity to handle any legitimate elevated traffic levels.
 
30.3.11 Provisioning against WHOIS and EPP Denial of Service attacks 

CoCCA actively monitors all Registry Services to ensure they meet any required SLA. In the event of a DoS attack that threatens to lower the SLA for WHOIS or EPP services required in the ICANN Agreement, CoCCA will work with our upstream providers (who also monitor the traffic) and attempt to squelch offending traffic at the ISP borders before it reaches the CoCCA RDDS servers. In the event the traffic is found to be legitimate, the bandwidth can be swiftly increased as required. 

30.3.12 Failover Routing

CoCCA currently has multiple links to the Internet but does not load balance across them all. The secondary (failover) link is used to replicate and transfer backup WAL and VM image data files to CoCCAʹs Failover SRS infrastructure (currently located in Palo Alto) and Escrow NOC. If there is a critical infrastructure issue at PIPE Networks, BGP routing will be used to move our critical infrastructure on our IPV4 and IPV6 address blocks to the failover Telstra link or to one of the two SRS instances outside of Australia. A forth node will be added in Paris (France) in early 2013. 

If the issue relates to an SLA problem, changing the A record and CNAME for RDDS services may be sufficient to resolve such an issue in a timely manner. If required by a pro-longed outage BGP routing may be used to re-rout the entire ranges to a failover facility. 

30.3.13 Commitments to Registrants

Taken from the .UMMAH WHOIS and Privacy Policy

ʺ6. DATA SECURITY

6.1 CoCCA shall take reasonable steps to protect the Personal Information it holds from misuse and loss and from unauthorized access, modification or disclosure.

7. OPENNESS
7.1 This Policy sets out CoCCAʹs policies on its management of Personal Information. CoCCA shall make this document available to anyone who asks for it.

7.2 On request by any person, CoCCA shall take reasonable steps to let the person know, generally, what sort of Personal Information CoCCA holds, for what purposes, and how it collects, holds, uses and discloses that information.

8. ACCESS AND CORRECTION
8.1 All Registrant information lodged by a registrar that is maintained in the CoCCA SRS is publicly available from CoCCAʹs RDDS services - WHOIS, Premium WHOIS, and Historical Abstracts. 

See the .UMMAH RDDS Policy (Attached) for more information.

8.2 If CoCCA holds Personal Information about a Registrant and the Registrant is able to establish that the information is not true, accurate, and complete and⁄or up-to-date, CoCCA shall take reasonable steps to facilitate corrections to the information so that current information is accurate, complete and up-to-date - except where the data is contained in an historical record or archive.ʺ

30.3.14 Independent Security Assessments

In addition to software and source security Audits, CoCCA has engaged the services of Connell Wagner Pty Ltd (now known as Aurecon Group Brand (Pte) Ltd) for the purpose of performing independent security audits of the primary data center. 

On the condition that a gTLD is approved, CoCCA will engage the services of Aurecon to perform independent security audits to ensure the CoCCA system fully complies with all published security requirements set forth by ICANN. Such reports will be provided to ICANN on request. With new IT infrastructure planned for deployment in 2012 and early 2013, CoCCA will contract further independent assessments with third parties.