Application number: 1-2131-60793 for Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.

Unit 3, No 9, Omur St, Bahcelievler,
Istanbul N⁄A
TR

+90 212 605 6551

+90 212 603 6550

Mehdi Abbasnia

Managing Director

+90 533 224 7892

agitsys4@nsline.com

Hakan Atalay

The Head of Engineering Dept.

+90 212 605 6551

hakan.atalay@agitsys.com

Limited Company

Trade Registration Office (Ticaret Sicili Memurlugundan)

Not Available

Ali Zarinbakhsh
Member of the board
Mehdi Abbasnia
Managing Director

Fatih Atasoy
CFO
Mehdi Abbasnia
Managing Director

Ali Zarinbakhsh
Member of the board
Mehdi Abbasnia
Managing Director

halal

Not Available

The team behind Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has been involved in the development of various IDN scripts for over ten years. Through this work, we have become aware of some issues that may cause rendering problems for certain new gTLDs. We have reviewed the string that will be used with this application and based upon our expertise, we see no issues with operational or rendering problems concerning the applied for gTLD string.

There are hundreds of millions of Muslims worldwide, practicing their faith in a huge variety of different ways. They are a disparate group, yet they are united through their core beliefs. They are a group whose origins are found some 1400 years in the past, their ethnicity often inextricably linked with their faith. Hitherto, however, there has been no way to easily unify them and their common appreciation of Islam. The .HALAL gTLD will change this.
As Halal is one of the concepts of the Islam religion, the .HALAL gTLD is the perfect way to easily and simply tie together online the peoples of various nations connected religiously to the Muslim community which was first established more that 1400 years ago.
The .HALAL gTLD will be a community application with open to those who embrace the concept and requirements of Halal.
Islam is the monotheistic religion articulated by the Qurʹan, a text considered by its adherents to be the verbatim word of God (Arabic: ‎ Allāh ), and by the teachning and normative example (called the Sunnah and composed of Hadith) of Muhammad, considered by them to be the last prophet of God. An adherent of Islam is called a Muslim.
The majority of Muslims are Sunni, being 75–90% of all Muslims. The second largest sect, Shia, makes up 10–20%. About 13% of Muslims live in Indonesia, the largest Muslim country, 25% in South Asia, 20% in the Middle East, 2% in Central Asia, 4% in the remaining South East Asian countries, and 15% in Sub-Saharan Africa. Sizable communities are also found in China, Russia, and parts of Europe. With over 1.5 billion followers or over 22% of earthʹs population, Islam is the second-largest and one of the fastest-growing religions in the world. 
Halal (Arabic: حلال‎ ḥalāl, ʺlawfulʺ) is a term designating any object or an action which is permissible to use or engage in, according to Islamic law. The term is used to designate food seen as permissible according to Islamic law. 
The terms Halal is also applied to many other facets of life; and one of the most common uses of these term is in reference to meat products, food contact materials, and pharmaceuticals. In Islam there are many things that must clearly be defined as halal. 
The concept of Halal has slowly become accepted as a consumer lifestyle choice encompassing not only religious practices and food, but also finance, non-food products and logistics. Halal provides a set of laws and guiding principles, and separates out those animals that are prohibited (‘haram’) and permitted (‘Halal’). As well as outlining methods of slaughtering, Halal prohibits consuming blood or blood products and intoxicants (e.g. alcohol) etc.The common understanding of Halal is still limited to religious needs and only applicable to Muslims. It is considered a given in Turkey and the Middle East, although consumers in this region generally do not place much importance on specific Halal branding, certification or country of origin.
A robust gTLD has the power to bring together Muslims across national borders in a free-flowing exchange of information and commerce. There is not a .COM or .ORG equivalent of .HALAL--a domain that has universal appeal across a common religion. 
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) was founded in (as is headquartered in) Turkey (an Islamic nation that straddles Europe and the Middle East) by Muslim people with great affinity with their religion, which manifests itself in both pride and honor. Because of this, and their devotion to creating a quality online space for the Muslim faithful amongst others, AGITSys’ founders have gathered together a highly experienced team with a variety of Internet-based expertise, a daunting but critical task. The team behind AGITSys has taken a leading role in working toward dedicated Muslim domain names for more than 8 years. No entity is better suited to manage the .HALAL gTLD, nor more dedicated to providing new online tools and services to facilitate the unification of the .HALAL community online. The .HALAL gTLD will increasingly open up the vast resources of the Internet and the interconnectedness it brings to the Muslims community, while stimulating the introduction of more information and resources among Muslims online. The .HALAL gTLD is designed to accommodate a global community, and AGITSysʹ team’s work with ICANN has always looked not just to serving Muslim people but all users of the internet - thus serving Muslims and those interested in the Muslim faith all around the world – whilst simultaneously achieving ICANN’s goal of creating greater competition in the gTLD space.

The benefits of the .HALAL gTLD will be manifold, not just to registrants but also to tens of millions of Muslim internet users, as well as many others with an interest in or curiosity regarding Islam. The presence of a Muslim-specific gTLD will increase the volume of online Islamic resources, as the emergence of .HALAL second-level domains sees a network effect kick in. This network effect will create an additional incentive for the digitization of existing Islamic materials, so as to facilitate their posting online as the demand for such material grows.
Consequently, the new .HALAL gTLD will also increase access to online resources as the tens of millions of people that read Islamic and Islam-related materials are able, for the first time, to find the material they seek within the sites operating under the .HALAL gTLD. Existing website registrants will be able to extend their presence to that audience with new .HALAL sites, while new registrants will emerge from those Muslim populations brought together by the .HALAL gTLD, adding to the value of the Internet in ways not currently possible.
As the global population expands, more people become willing Internet users and seek out second-level domains. The .HALAL gTLD is flexible, and is thus capable of being used for sites focused on ecommerce, information dissemination, charitable endeavors and many more functions among Muslims. A transformation in competition is anticipated for web sites within .HALAL, to depart from conventional methods of attracting new customers in this expanding market. This is because it will encourage competitors, targeting the extensive and diverse collection of global Islamic Internet users. This incentive doesnʹt currently exist in an online space devoid of the .HALAL gTLD, where competition amongst the already saturated existing TLDs is stagnant.
In terms of goals in the areas of specialty, service levels, and reputation for the proposed .HALAL gTLD, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) is committed to offering choice in top level domain extensions among the Islamic community. AGITSys recognizes many new gTLDs will naturally have a relatively narrow appeal and audience. The .HALAL gTLD is different, as it not only targets a distinct online community, but one that spans the globe. AGITSys is prepared to utilize its home market of Turkey as a leading source of registrants and sites, while incorporating the power of the web to connect with myriad other registrants and Internet users beyond Turkey. Further, we intend to adopt and follow the highest standards in registry operations exceeding service levels and expectations thus producing a consistent reputation.
AGITSys has been at the forefront of the ICANN community effort in working to bring the Global Muslim community together through a dedicated gTLD, as well as bringing Muslims in to the larger online community. No organization has a greater understanding both of the opportunities a .HALAL gTLD will afford as well as the challenges that its adoption and spread will bring. AGITSys is prepared to ensure the success of .HALAL, such that it is a shining example of ICANNʹs wisdom in granting the gTLD.
The company is committed to bringing top-level domain registration services to registrants. To this end, AGITSys has contracted CoCCA Registry Services (NZ) Limited (“CoCCA”) to provide hosted Registry Services for the .HALAL gTLD. 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 clients are managers of county code top level domains (ccTLDs) as of 31 March 2012, 33 national country code top level domains (“ccTLDs”) are have selected CoCCA’s SRS technology or services to manage their critical infrastructure. Several other ccTLDs have committed to migration to CoCCA’s “pamoja” EPP Shared Registry System (“SRS”) in 2012 pending the outcome of re-delegations. 
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. 
AGITSys’ team is also well-known in the ICANN community as a selfless champion of the interests of Muslims around the world, including communities tied to the Islamic heritage. We also have a long history of advising the Turkish internet industry. Our reputation is solid, and we have every incentive to maintain that reputation as we roll out the .HALAL gTLD.
Under the shepherding of AGITSys, the .HALAL gTLD will increase competition, provide more online differentiation for customers and consumers, while driving digital innovation. The addition of the .HALAL gTLD will create new competition for names within the domain name space. Not only will the offering of .HALAL domains create competition within content providers for users of Islamic content, but it is expected that competition will be enhanced among the varying service providers that users require to deploy said content. 
As it is rolled out, the .HALAL gTLD will rapidly develop as the gTLD of choice among Muslims in all countries. The demand for Islamic content from this group isn’t and wonʹt be satisfied by .COM or .ORG offerings within the current gTLDs and in fact has hampered collaboration and innovation. The Islamic people demand content that is tailored to their own unique needs and wants, under the umbrella of a dedicated gTLD. As stated in 18(a) above, as Islamic-content sites increasingly seek to differentiate themselves to consumers, and registrants seek to differentiate themselves to acquirers of second-level domains, the power to differentiate will come from innovative approaches to customer service and the creation of a trusted online environment. 
It is AGITSys’ mission that competition and differentiation of the .HALAL gTLD will be coupled with a user experience online that is reliable and predictable. To make this as likely as possible, AGITSys will work both with existing registrars seeking to reach new audiences, as well as new registrars that may emerge from within the global Muslim community, thereby supporting ICANNʹs mission to create more capacity in developing countries. AGITSys feels it can foster more competition at the registrar level by offering assistance and encouragement to new registrars in this way. We also believe that this should and will be coupled with a positive experience for Internet users. Indeed, this is critical to the success of the .HALAL gTLD. By working with the right registrars (who maintain the right, stringent) standards for adoption and use by their own customers, AGITSys can reach its goal of having the .HALAL gTLD become synonymous with a safe and trusted online experience.
As a part of this, since the .HALAL gTLD is community based and designed to serve those of Muslim faith, as well as to protect its good name, AGITSys intends to limit second-level domain registrations to those of Muslim faith, or those with a clear interest in serving the Muslim community and faith beneficially. Such a designation is almost impossible to police, because faith is a highly personal thing requiring no proof beyond belief, and to restrict, for example, registrations to those geographically located in predominantly Muslim nations would alienate the myriad Muslims in other nations. Thus, these limitations will mostly be self-imposed, with registrants agreeing themselves that they are either of Muslim faith, or have a clear interest in ameliorating the community. Equally, AGITSys will not tolerate radical content, nor will it tolerate content that criticizes Islam and the Muslim faith. Immediate and severe action will be taken against registrants promulgating either, and a black list will be created in an attempt to pre-empt any such attempts. Once content is registered, the community will be to an extent self-policing, with facilities to report abusive, irrelevant or anti-Muslim registrations available on the Registry website. 
Because of its dedication to the Muslim community and the .HALAL gTLD which is intended to serve it, AGITSys will implement protection measures for registrations to ensure an abuse free environment whilst maintaining choice. This will be accomplished with Registration safeguards, wildcard alerts, name selection polices, all governed by an Acceptable Use Policy and post registration protections via Uniform Dispute Resolution Policy and Uniform Rapid Suspension. More details on these policies can be found in answer to Questions 28 and 29.
The privacy offered will be total, within the rules and procedures provided by ICANN. These policies will be transparent and rigorous, modeled after successful policies implemented by currently delegated TLDs and accompanied by vigilant processes and technologies to prevent unauthorized access to information. This is a manifestation of the larger goal of the .HALAL gTLD, that of a trusted source of safe online transactions, as stipulated in 18(a).
Privacy and security will be key elements of our Acceptable Use Policy (AUP). The AUP will govern how a registrant may use its registered name, with a specific focus on protecting Internet users. AUP language would specifically 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. We would maintain complete enforcement rights over the use of the domain name. Should a registrant find itself in breach of the AUP, we would reserve the right to revoke, suspend, terminate, cancel or otherwise modify their rights to the domain name.
In terms of community outreach by the .HALAL gTLD, it is expected that the momentum around .HALAL will build quickly, given the pent-up demand that has been building for years within the ranks of the Muslim faithful and associated community. AGITSys, as its champion in gTLD discussions, knows full well how popular this service will be.
As more sites offer information, services, and opportunities for interconnection to the .HALAL community as a whole, 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 .HALAL domains. At some point, Islamic information and service providers currently not offering sites, will see the demand for .HALAL-related content and will migrate their offerings to .HALAL sites as well, furthering the offerings to the community and further driving community members to .HALAL sites. The future benefits of interlinking this diverse and global community are incalculable but immense.
Augmenting this, AGITSys is also active in the business community within Turkey and Middle Eastern countries and interconnected across the spectrum of the Muslim community due to its promotional efforts with ICANN and elsewhere. It will leverage that network to spread the word of the .HALAL gTLD in order to promote adoption. The best steps AGITSys can take to ensure the gTLDʹs adoption and growth, however, are to ensure a system encouraging robust, safe and dynamic second-level domain sites. At that point, the word will spread through the network effect.

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) will endeavor to the utmost in order to minimize the social costs to registrants of a .HALAL second-level domain, not least because AGITSys has every incentive to encourage the adoption and growth of the .HALAL domain. AGITSys has chosen to adopt CoCCA’s tested acceptable use based policy matrix, recommendations for minimizing harm in TLDs, and subject the TLD to the CoCCA Complaint Resolution Service (“CRS”).
The CoCCA Best practice policy matrix has been developed over a decade and has currently been adopted by 16 TLDs. It was developed for (and by) ccTLDs managers that desired to operate an efficient standards–based SRS system complemented by a policy environment that addressed a registrants use of a string as well as the more traditional gTLD emphasis rights to string. 
A key element of CoCCA’s policy matrix is that it provides for registry-level suspensions where there is evidence of AUP violations. The TLD will join other TLDs that utilize the CoCCA’s single-desk CRS. The CRS provides a framework for the public, law enforcement, regulatory bodies and intellectual property owners to swiftly address concerns regarding the use of domains, and the COCCA network. The AUP can be used to address concerns regarding a domain or any other resource record that appears in the zone.
The CRS procedure provides an effective alternative to the court system while allowing for Complaints against domains to be handled in a way treats each complaint in a fair and equal manor and allows for all affected parties to present evidence and arguments in a constructive forum.
AGITSys is also currently developing procedures for competition resolution regarding multiple registrations for the same second-level domain in addition to offering the required Sunrise offerings through general availability. AGITSys will model these procedures after the techniques and approaches that have succeeded best to date. The history of .COM will be of interest here, because .HALAL should grow quickly and face demand as high among the Muslim community as .COM has in the English-language online community.
In terms of cost, benefits, and incentives to registrants of the Islamic community, AGITSys will offer fair and competitive pricing campaigns for tens of millions of people, introducing them to the wonders of the Internet and the Muslim faith therein. Competitive pricing and⁄or discounts will be used and adjusted accordingly to ensure the right incentive matches the phase of operation and business goals. AGITSys’ business plan increases our confidence in offerings that will encourage growing adoption of the .HALAL gTLD.
Each year, AGITSys will review its financial goals versus actual performance of registry operations. Output from the analysis will include the consideration of pricing versus demand for registrations. As with any for-profit entity, adequate cash flow and predictable revenue streams are essential to successful operations. As such, AGITSys may adjust pricing of domain registrations to align with evolving business goals. Adjustments can include not only price increases, but perhaps price decreases, but only current market analysis will dictate change. Therefore, AGITSys will document in the Registrant Agreement domain price change procedures and how they can be expect to learn about changes through our communications platform. In the end, serving the Islamic community through Internet technologies remains our first priority. 

Yes

The word “HALAL”:
HALAL is one of the most fundamental concepts of the Islam religion.
Halal (Arabic: حلال‎ ḥalāl, ʺlawfulʺ) is used to designate any object or an action which is permissible under to Islamic law. The term halal is therefore applied to many facets of Muslim life; one of the most common being in reference to meat products, food contact materials, and pharmaceuticals. The halal concept has slowly become accepted as a consumer lifestyle choice encompassing not only religious practices and food, but also finance, non-food products and logistics and this is a trend has gathered significant momentum recently. However, the common understanding of halal is still limited to religious needs and only applicable to Muslims. It is considered a given in Turkey and the Middle East, although consumers in this region generally do not place much importance on specific halal branding, certification or country of origin.
The HALAL industry service providers Community:
Halal industry service providers are the community that the .Halal gTLD is designated for.
The Halal industry service providers’ community consists of all those who do engage in:
1. Research, Development, Monitoring and Certifying of Halal materials,
2. Production of Halal Materials
3. Distribution of Halal Materials
4. Sales and Marketing of Halal Materials
This will consist of a huge amount of industry role players which basically serve the 1.2 Billion Muslim population in the word, but the community’s services is not just limited to Muslims, rather many non-Muslims nowadays who has accepted the halal concept as a healthy life style. Considering this, we can estimate the size of the community, and also the wide distribution of the community in the world. Since wherever a Muslim lives, there is a place for the Halal service providers to be active. It means that the Halal community is spread all over the world, and itʹs not necessary to describe that the community remains forever.
Now, in the globalization age, the development of Halal standards sponsoring by standing monitoring centers in all aspects of life is a must, so that all products would be presented by special brands to guarantee the consumersʹ tranquility of mind at the global level especially in non-Islamic Countries. This certification brings an identity to the members of the Halal community as described later.
The Halal Food Industry
Halal Food industry can be named as the most important portion of the Halal service providers’ community.
In Muslim countries, the food industry is almost 100 percent based on the Halal food preparation methods, but Halal foods are becoming more and more popular even in non-Islamic countries every day. In South Africa most chicken products have a halal stamp. The South African National Halal Authority issues halal-approved certificates and products bearing this is logo range from meat to water, snacks, and even other meat free products (which may ordinarily contain non-halal ingredients). The South African National Halal Authority (SANHA) also licenses the usage of the Halal logo in restaurants where the food is halal and no alcohol or pork products can be served. Similar movements in the US, UK, China, Malaysia, Singapore and many other non-Muslim majority countries are equally, or ever better, established.
One of the first halal food companies in the USA is Midamar Corporation, established in 1974. It is also one of the first companies in the USA to sell USDA approved and Halal certified US protein products to the Middle East and South East Asia. The Certification Agency Islamic Services of America was established in 2004 and located in Cedar Rapids, Iowa. Islamic Services of America certifications are recognized by some Islamic Countries.
In Dearborn, Michigan, U.S.A (the home of one of the largest Muslim and Arab populations in the United States), and some fast food restaurant chains such as the McDonaldʹs Corporation have introduced halal chicken nuggets and other halal offerings. In a similar light, McDonaldʹs, Pizza Hut, and Kentucky Fried Chicken have been declared to be halal in Sri Lanka by the Jamiyathul Ulama, the only authority able to give out the certification there. In the United Kingdom, China, Malaysia or Singapore, halal fried chicken restaurants having thousands of outlets serve halal foods, such as the Chicking Fried Chicken, Kentucky Fried Chicken, Brownʹs Chicken, and Crown Fried Chicken companies. As of February 2009, Kentucky Fried Chicken restaurants in the U.K. began to sell halal meals in several restaurants.
Also, in New York City there are numerous halal food carts in business which serve gyros, chicken platters, and other halal fast foods, whereas in Europe, there are many of the Muslim-owned Döner kebab shops.
Thailand also has a noticeable population of Muslims and Halal-meat shops country-wide.
Within the Peopleʹs Republic of China, which has a sizable Hui Muslim minority population, halal food is known as ʺQingzhenʺ (pinyin: qīngzhēn; literally ʺpure truthʺ). Halal restaurants run by Hui Chinese resemble typical Chinese food, except that they do not serve pork. Dishes specific to Hui Chinese are known as Chinese Islamic cuisine.
Halal Certificates:
Since the turn of the 21st century, there have been efforts to create organizations that certify food products as halal for Muslim consumers.
Since 1991, mainstream manufacturers of soups, grains, cosmetics, pharmaceuticals, prepared foods, and other products, as well as hotels, restaurants, airlines, hospitals, and other service providers have pursued the halal market. These companies purchase halal-certified products. Halal certification tells Muslims that their ingredients and production methods have been tested and declared permissible by a certification body. It also allows companies to export products to most Middle Eastern countries and South East Asian Countries. The oldest and most well-known halal certifier in the United States is called the ʺIslamic Services of Americaʺ. Something that companies which intend to export halal products must keep in mind, when choosing a certifier, is whether or not the certifier is recognized by foreign governmental bodies.
In 1986, the ʺIslamic Meat & Poultry Companyʺ was founded in Stockton, California. Islamic Meat & Poultry is a halal-only, U.S. Department of Agriculture-inspected, hand-slaughtering and meat-processing facility. This company follows the principles of slaughtering and meat-processing according to the Islamic Shariah.
In 2011, Halal Products Certification Institute was established in California, United States of America and became the first worldwide corporation that Certified Halal Consumer Products such as Cosmetics, Personal Care Products, Perfumes & Fragrances, The institute was established by renowned Islamic intellectual scholars and top Muslim scientists in the world to assure the dissemination of halal consumer products.
Also in Europe, several organizations have been created over the past 20 years in order to certify the halal products. A survey recently published by a French association of Muslim Consumers (ASIDCOM) shows that the market of halal products has been developed in a chaotic way.
Islamic Chamber research & Information Center (ICRIC), affiliated to Islamic Chamber of Commerce & Industry (ICCI) and a member of the family of Organization of Islamic Conference (OIC) has embarked to study and research on the subject to meet the need in Muslim World. ICRIC has also embarked to adopt a monitoring system in ʺHalal Productʺ including ʺHalal Foodʺ and proceeded to research, development, information and support in this ground.
The .HALAL gTLD will allow —the Halal industry service providers community to unite online as a full and robust community, enjoying the connection and exchange of information empowered by faith, and community in beliefs.

 Relations to any community organizations.
AGITSYS is founded, owned and managed by Muslim people. AGITSys uses the expertise of the Muslim technical men, and it is incorporated in Turkey, one of the countries with the majority of Muslim people (98% Muslims).
AGITSys team is all from Middle East where Islam is the major religion, and the heart of Islam. AGITSys’s location in Turkey, thanks to the close communication of Turkey with both Islamic and western courtiers, brings a brilliant opportunity to promote the .HALAL TLD both in the countries where Islam, is the main religion, and countries where Islam is not dominant, but many Muslims leave in to the main consumers of the .HALAL gTLD: the members of the Halal service providers community
• Relations to the community and its constituent parts⁄groups.
As stated above, AGITSYS has come from the heart of the Muslim community as defined both by geography and the nationality of the team members and as a result, the Halal service providers community as the adherent of the Muslim community,
AGITSys has enough technical knowledge and expertise to run the .HALAL TLD and at the same time is supported by important well-known men of the Islam world, meaning that there would be trust and support from the Muslim community.
• Accountability mechanisms of applicant to the community.
AGITSys will oversee the formation of a .HALAL Policy Advisory Committee (PAC) populated by members of the .HALAL industry service providers community. AGITSys intends that the PAC be representative of the entire broad spectrum of the halal industry service providers’ community. It therefore intends to engage religious figures, certification institutes and halal product manufacturers, distributors, retailers and service providers.
The PAC would serve as a conduit for the community to weigh in on any policy matters that impact the operation of the gTLD. These can range from abuse prevention and mitigation to registration policies and the maintenance and structure of the .HALAL community.
This advisory Board will also be critical for our continued outreach across the community as we spread the word about the .HALAL gTLD. It will serve as a key channel of communication with, and anchor to, the community which this effort hopes to serve.

• Intended registrants in the TLD.
A .HALAL registrant maybe of one of manufacturers of soups, grains, cosmetics, pharmaceuticals, prepared foods, and other products, as well as hotels, restaurants, airlines, hospitals, and other service providers, many of whom are not currently represented on the internet but would feel a newfound affiliation with a .HALAL gTLD.
We can foster more competition at the registrar level through assistance and encouragement with new registrars.
• Intended end-users of the TLD.
For a fifth of the worldʹs population, Islam is both a religion and a complete way of life. Muslims follow a religion of peace, mercy, and forgiveness, and the majority have nothing to do with the extremely grave events which have come to be associated with their faith.
Every Muslim or even non-Muslim man or woman in the world can benefit from .HALAL websites to catch the information and services offered by them.
The spread of .HALAL TLD would be wide enough to cover all types of audiences and their needs, considering that all .HALAL websites in any case will be promoting HALAL concept and industry in different ways.
Within all of these populations, the intended end users of the .HALAL gTLD are manifold:
People with ties to the Islamic heritage: This would include a significant percentage of the population of Muslim Community along with other nations.
Individual Muslims: As demonstrated above, this includes hundreds of millions of individuals around the world.
Students: Those learning about different aspects of Islam, its concept, its laws, its culture and heritage, etc… would benefit from increased resources online that would help them learn and grow in their new studying.
Islamic businesses: as like as every community, Muslims has also doing business among themselves as well as doing business with other communities. Muslim business men will the word “HALAL” as a symbol of honor and trust, and the witness of belonging to Muslim community. The word “HALAL” is used widely among Muslims’ websites. A simple search for the word “HALAL” results more than 500 million web pages, showing the popularity of the word “HALAL”.
Halal industry role players: those businesses who serve the Muslim community by providing Halal goods would benefit .HALAL domain names as a symbol of trust and their Halal Certification.
It is hoped that not only will these intended users derive individual benefit from the existence of a .HALAL community, but that they will also contribute in turn. This should create a group benefit, which will in turn feed back in to individual benefits – establishing a beneficial cycle.
• Related activities the applicant has carried out or intends to carry out in service of this purpose.
Anticipating the diversification of TLDs now being realized, and the consequent introduction of a halal-specific online space, AGITSys has been working with a wide variety of related parties for several years in preparation, and will continue to do so going forward. A key element for the success of the .HALAL gTLD is a strong and interactive community, which members of the community would be proud to associate with and keen to contribute to. To ensure this, AGITSys will sponsor community outreach and marketing, in order to raise awareness of the forthcoming possibilities. These possibilities are also highly appealing for Islamic businesses, and as such AGITSys will engage in dialogue with those businesses, and industry chiefs, regarding their ideas for how the .HALAL gTLD will take shape, and what they intend to subsequently give back to it.
As this is a community directed effort, one of the first steps AGITSys would take would be to establish the .HALAL Policy Advisory Committee. AGITSys would recruit representatives from around the globe to ensure that a variety of interests and perspectives are represented. The PAC will not only serve as a key partner in the development of policies governing the operation of the gTLD, but they will be critical out our ongoing community outreach and marketing efforts. One key function for the PAC would be to aid in developing a list of reserved names which for a variety of reasons would be deeming of limits for registration. This list will ensure that key cultural icons, religious organizations and other entities of importance to the community could not be used in a way that is contrary to their wishes and desires.
The PAC will be integral to our launch efforts and much of the initial marketing of the .HALAL gTLD will need to come from community related activities. Outreach would also include religious figures, community leaders, celebrities and any other prominent organizations or individuals who embrace the halal lifestyle.
Quality content will also be fundamental to a thriving .HALAL community, especially because AGITSys is committed to ensuring that .HALAL is populated by quality second-level domain offerings. With this in mind, AGITSys will be talking with those most likely to contribute quality content, from news and media agencies to academics and others about how they can and will contribute, and what AGITSys can do to facilitate this process.
Ultimately, however, religion will always be the most important element for a successful .HALAL community online. The entire gTLD concept is designed as a place of online respect; almost worship, for those who embrace the halal concept. As such, the involvement, blessing and feedback of the Islamic religious community are fundamentally important. Aware of this, AGITSys has been in prolonged and continued contact with important religious figures – asking them what they want to see and how they would like to see it done, whilst also encouraging them to spread the word and prepare themselves.
• Explanation of how the purpose is of a lasting nature.
The community that will be served by .HALAL--growing as it has out of the Muslims community--has thrived and grown for more than a millennium. Remarkably, it has done so largely without the level of connection online found with Islamic cultures. This existing community interconnection speaks to the cultural staying power of the community and the many ways it enriches world culture.
With the adoption of a .HALAL community, this robust group will be further empowered to interconnect and grow, allowing it to take its equal place on the Internet stage. The community thrives now, but will reach new heights with a .HALAL gTLD.
As more sites offer information, services, and opportunities for interconnection to the .HALAL community as a whole, 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 .HALAL domains. At some point, information and service providers currently not offering sites will see the demand for .HALAL-related content and will migrate their offerings to .HALAL sites as well, furthering the offerings to the community and further driving community members to .HALAL sites. The future benefits of interlinking this diverse and global community are incalculable but immense.

• relationship to the established name, if any, of the community.
The word “HALAL” is the core fundamental of the Halal service providers community. Without the philosophy of “Halal”, no such a community would be shaped.
• relationship to the identification of community members.
As stated above, community members will feel an affinity and self-identification with the .HALAL TLD. As adoption of .HALAL grows, use of domains using this community TLD will grow exponentially, helping to cement the obvious connection between the string and the community. Our community members are the producers or service providers of the halal products.
• any connotations the string may have beyond the community.
AGITSYS knows of no other connotations the .HALAL string might have outside of this community.

• Eligibility: who is eligible to register a second-level name in the gTLD, and how will eligibility be determined.
As mentioned above, the primary goal of the .HALAL gTLD is the protection and promulgation of the Halal concept. To this end, In order to register a .HALAL Domain Name, you declare that you are part of the Halal service providers Community.
Registrations in the .HALAL will be restricted to 1) those who can produce a copy of a halal certificate demonstrating that the goods and services they provide meet the generally accepted hahal standard and⁄or 2) all goods and service providers headquartered and operating in Islamic countries as they are deemed halal by their ability to operate in an Islamic country.
Our policies may permit registrations in .HALAL gTLD to the following:
Universities, schools, research institutions and other academic entities performing academic activities or teach⁄promote aspects of halal concept.
Individuals, groups, businesses, organizations, entities or initiatives affirming their belonging to the Community
The .HALAL TLD is intended for people who wish to promote, participate or learn about HALAL and its different aspects, its affect on the daily life of the people around the word, its history, Law and jurisprudence, etc belonging to the Muslim community.
All .HALAL gTLD registrants must comply with AGITSys Acceptable Use Policy (AUP), .HALAL registration policies and with ICANN guidelines.
• Name selection: what types of second-level names may be registered in the gTLD.
AGITSYS will follow ICANN guidelines regarding potential restrictions of second-level domains. The names selected to be registered under .HALAL TLD must not have any conflict with the cultural, traditional and historical values of the Muslim community. This restriction can be controlled by creating the list of prohibited names managed by the .HALAL Policy Advisory Committee described above.
• Content⁄Use: what restrictions, if any, the registry operator will impose on how a registrant may use its registered name.
AGITSYS will have an Acceptable Use Policy (AUP) and registration policies that will govern how a registrant may use its registered name. We will ask all members to honor the Islamic Culture, Heritage and rules.
Registrants must accept and abide by the following:
a. No denigration of The Prophet Mohammad will be propagated within any site content of the .HALAL TLD
b. No denigration of the halal concept will be propagated within any site content of the .HALAL TLD
c. Messaging about Islam or the Quran will not criticize Islam and the Muslim faith
d. Registrants and Users will refrain from activities that runs contrary to general Islamic principles
e. Not use the .HALAL TLD or site content as a communications and coordination vehicle of radical or terrorist activities
f. Will not establish third level DNS management of a second level .HALAL domains
These requirements will be enforced through the AUP and contracts registrants must sign with their registrars prior to the registration of a domain name.
• Enforcement: what investigation practices and mechanisms exist to enforce the policies above, what resources are allocated for enforcement, and what appeal mechanisms are available to registrants?
As part of the AUP and registration polices, AGITSys will have complete enforcement rights over registrants’ use of .HALAL domain names. AGITSys will randomly audit registrants in the ,HALAL gTLD to ensure that they can provide evidence of their halal certificate which ensures the goods and services they are providing have been reviewed by recognized authorities in the halal community as are surely being halal. If a violation is discovered, an investigation will begin immediately to rectify said violation. Penalties for violation range from suspension of a domain, to removal of the domain name from the TLD and blacklisting of the registrant, preventing them from being able to register any other names in the .HALAL TLD. From time to time the .HALAL PAC may need to be engaged to consult on potential enforcement activities.

Not Available

No

Protection of Geographic Names
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. to operate the .halal in a manner that is fully compliant with all ICANN rules and regulations.
CoCCA, on behalf of the Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti., 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
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. decides to release reserved geographical names, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will abide by the process outlined in Specification 5 of the Registry Agreement by seeking agreement from the applicable government(s). Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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. The Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. in conjunction with CoCCA’s assistance will be engaged in policy development efforts in general and with respect to protections of geographical domain names. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will review and consider suggestions or concerns from government, public authorities or IGOʹs regarding this policy. And as with all required policies, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will perform openly and transparent should updates to existing policy or the creation of new policy be required. Further, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.ʹ internal process continually reviews and manages its reserve lists as one part of the abuse prevention mechanisms described in greater detail within question 28, “Abuse Prevention and Mitigation.”

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has contracted CoCCA Registry Services (NZ) Limited (ʺCoCCAʺ) to provide hosted Registry Services for the .halal TLD. The .halal 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 .halal 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 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 .halal TLD 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
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal 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 .halal 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 .halal 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. policy. the .halal 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 .halal 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 .halal 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 (2) public unicast TLD servers operated by CoCCA. 

The .halal 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 .halal 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, .halal 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 .halal TLD when launched. 

.halal 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, it 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. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will bind all registrants in the .halal to the CoCCA CRS, Acceptable Use Policy and Privacy and RDDS Policy via the .halal 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 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 .halal 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.

The .halal 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 .halal 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 objective of Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. To ensure this CoCCA will use PCHʹs DNSSEC and anycast infrastructure for offline storage, signing and resolving the .halal 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 the .halal:

* 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 facility is hosted by Equinix in San Jose.

* .halal 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 .halal 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 .halal 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 .halal will be branded as epp.nic.halal. 

24.3 WHOIS Interface (port 43 and 443)

The WHOIS Interface(s) for .halal 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 .halal will be branded as ʺwhois.nic.halalʺ. Each TLD ( ccTLD⁄ gTLD ) in the CoCCA SRS may have different WHOIS disclosure settings based on the TLD policy. The .halal will comply with the ICANN gTLD disclosure requirements.

24.4 GUI Interface (port 443)

The GUI Interface for .halal 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 .halal will be branded as ʺregistry.nic.halalʺ.

24.5 Hidden Master DNS (s) (port 53)

The there are two hidden master servers. CoCCA will transfer the .halal 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 .halal TLD zones.

24.7 Public anycast DNS

CoCCAʹs distribution master notifies the anycast providers (PCH and ISC) and .halal 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 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 between two different application servers at the primary SRS ( more application servers can easily be added ). Public read-only RDDS may also load balanced by simply having the nagios monitoring software automatically modify the resource records and send WHOIS 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 CoCCA AS. 

VMware images of all virtual machines are made daily using Veeam Backup & Replication software 

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 VMware 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 DE
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. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal 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 .halal 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 .halal 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.halal.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 .halal 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 .halal 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 the Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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.halal 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 .halal thick registry model registrars will not operate their own WHOIS servers. 

Inclusion of this object seems redundant and may cause confusion regarding the authoritative WHOIS server for the .halal. 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 below. 

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.halal and abc.domain.halal does not exist then the SRS would display the information on domain.halal 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.ʹ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 .halal TLD. 

If WHOIS caching is required as the .halal 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 CoCA will also provide fee-based Premium RDDS service described in further detail below. CoCCA and the Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 the .halal 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 being 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)

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti., 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 .halal WHOIS pubic 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal 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 .halal TLD will be added to CoCCAʹs SRS at their primary data center in Sydney which currently supports the features noted above.

The Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will dedicate 2 professionals to coordinate the operation of the .halal TLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .halal TLD.

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will adopt the CoCCA harmonized life cycle currently adopted by a dozen ccTLDs. The .halal 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 .halal TLD builds on the traditional gTLD life-cycle by adding direct Registrant-Registry interaction.

The proposed .halal life-cycle ensures key elements of the .halal 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 .halal 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 .halal 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 .halal 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 .halal TLD policy all registrations are considered provisional by Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. until the Registrant accepts the .halal 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal 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 .halal 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal TLD RA registrants are required to confirm the accuracy of the contact details and accept the .halal 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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

28.1 Policy Matrix
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has chosen to adopt CoCCAʺs tested acceptable use-based policy matrix, recommendations for minimising harm in TLDs, and subject the .halal TLD to the CoCCA Complaint Resolution Service (ʺCRSʺ). Any individual who has a concern regarding abuse involving a .halal domain, glue record, or the CoCCA PCH or ISCʺs network services as they relate to .halal needs to lodge a complaint via the CRS. CoCCAʹs policy regarding glue records is quite simple, Registrars cannot create or use a host if the super-ordinate domain does not exist. When a domain is purged from the SRS CoCCA automatically deletes any glue records. All other glue record related issues can be dealt with via the CRS.

The CoCCA Best practice policy matrix has been developed over a decade and has currently been adopted by 16 TLDs. It was developed for (and by) ccTLDs managers that desired to operate an efficient standards–based SRS system complemented by a policy environment that addressed a registrants use of a string as well as the more traditional gTLD emphasis rights to string. 

A key element of CoCCA’s policy matrix is that it provides for registry-level suspensions where there is evidence of AUP violations. The .halal TLD will join other TLDs that utilize the CoCCA’s single-desk CRS. The CRS provides a framework for the public, law enforcement, regulatory bodies and intellectual property owners to swiftly address concerns regarding the use of .halal domains, and the COCCA network. The AUP can be used to address concerns regarding a domain or any other resource record that appears in the .halal zone.

The CRS procedure provides an effective alternative to the court system while allowing for Complaints against domains to be handled in a way treats each complaint in a fair and equal manor and allows for all affected parties to present evidence and arguments in a constructive forum.

In certain cases, it may be necessary for the CRS to trigger a Critical Issue Suspension, which suspends service of a domain, or removes a host record, when there is a compelling and demonstrable threat to the stability of the Internet, critical infrastructure or public safety. The intent of any CIS is to minimize any abuse that may occur in a timely manor. Any CIS may be appealed through the CoCCA ombudsman’s Amicable Complaint Resolution service. 
28.1 Contractual Framework
Under the proposed framework Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will bind registrants to a .halal TLD Registrant Agreement (“RA”). This RA is a collateral agreement that supersedes any Registrar – Registrant agreement and binds all Registrants to the .halal AUP, Privacy and WHOIS policy, CoCCA CRS and any other requirements or dispute mechanisms mandated by ICANN. 

The draft .halal AUP follows below in sections 28.4. The RA and WHOIS and Privacy Policy may be viewed at http:⁄⁄coccaregistry.net⁄.halal⁄policy
28.2 Minimizing Harm, Pro-active Measures
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will adopt the following five (5) key provisions of CoCCA’s already field - tested policies and technology aimed at preventing and mitigating abuse. 
28.2.1 ʺTrust but Verifyʺ
Applicants for .halal registrations must confirm to the registry that they agree to be bound by the registrant agreement and confirm the accuracy of contact details lodged by the Registrar with the registry. Until the Registrant or Administrative contact confirm their contact details with the Registry directly, and view accept the Registrant Agreement .halal domains are excluded from the zone. See Life-Cycle Policy.

Automated Activation processes are already in place for 12 TLD currently using the CoCCA SRS. The process involves direct registry – registrant communication using email details provided to the registry by the Registrar. An automated email is sent to the Registrant and Admin contact that contains a link. The recipient must click on the link where they are directed to a web page that 1) displays the contact information the Registrar provided, 2) displays the .halal RA and AUP policy.

All responses (positive or negative) are lodged against the domains permanent history in the SRS and the time: date ⁄ IP address stored. 

The process also allows the registry the opportunity to independently verify the accuracy of contact data supplied by the registrar, or at least that there is a functioning email - improving WHOIS accuracy. The SRS uses dynamically generated images as a challenge-response verification to prevent automated processes activating domains and to directly collect and store additional identifying information about individuals Activating a domain, which can be utilised to control fraud or investigate cyber crimes.

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.

The registrant or administrative contact must confirm the accuracy of the WHOIS data on not only on Registration but also the anniversary of Registration and Renewal. On any change of Registrant or Transfer the new Registrant must also agree to the RA and AUP directly with the Registry before the changes to the contacts are committed in the registry.

These procedures and the underlying technology are in use now and undergoing constant refinement in response to Registrar and Registrant suggestions.
28.2.2 Registrants’ rights to a limited license
The .halal RA and AUP limit a registrants’ rights to a limited license to use but not to sub-license the use of any portion of the allocated SLD, subject to continuing compliance with all policies in place during that time. Registrants must warrant they will not assign the licence or sub-license any sub-domain without:

(a) securing the sub-licenseeʹs agreement to the RA, AUP and all other applicable policies; and
(b) obtaining the registryʹs consent in writing.

Rationale: It has occurred that registrants have registered 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. Most abuse seems to occur in lower level domains created by Registrants or third parties. 

The .halal TLD policy is recursive, however combating abusive activity in a TLD is complicated if the registry has no information as to the user of the subordinate domain or any way to suspend a single domain created by a registrant at a subordinate level. 
28.2.3 Fast flux mitigation
Fast flux mitigation - queue for manual intervention by SRS admins 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 redelegate a domain, in order to overcome service limitations imposed by Internet service providers. Frequent redelegation may also assist a malicious user to obscure their identity. Limiting frequent redelegations enhances the effectiveness of service termination as a sanction by an Internet service provider. 
28.2.4 Anycast Resiliency 
A denial of service attack from, say, 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 is therefore only affecting the local neighborhood. Distributed denial of service attacks usually affects 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+ noes and two Anycast networks, the .halal TLD is well protected against abuse targeting the .halal DNS resolvers.
28.2.5 High Risk Strings
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will require manual intervention by the registry operator before domains that contain various strings such as ʺbankʺ, ʺsecureʺ, ʺPayPal” etc., go into the zone. A comprehensive list of high-risk strings 
28.2.6 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. CERT Law Enforcement Collaboration
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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. The CoCCA already provides direct access to the Australian Government CERT. 

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.
28.3 COCCA Complaint Resolution Service 
The Complaint Resolution Service (“CRS”) 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 managers network or 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 lead by an independent Ombudsman, and where applicable, adjudication by an Expert. The CRS provides an efficient and swift alternative to the Courts.

All complaints made against a domain to CoCCA are referred through the CRS protocol. 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 may be referred to an Ombudsman for Amicable Complaint Resolution (ACR). If ACR does not achieve acceptable resolution, binding arbitration by an Expert be requested by the Complainant.

In some cases, a Critical Issue Suspension (CIS) may become necessary. If a CIS has been determined to be necessary, the domain, or other resource record in a zone will be disabled until a resolution is found using the CRS protocol. A CIS is triggered in cases where there is a compelling and demonstrable threat to the stability of the Internet, critical infrastructure or public safety. A CIS does not terminate the license to a domain, and cannot be used to trigger the transfer a domain - it simply suspends resolution. 
CRS Overview Diagram – cocca-crs1.pdf

28.4 .HALAL Acceptable Use Policy

This Acceptable Use Policy (ʺAUPʺ) sets out the actions prohibited to users of the Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) (“applicant”) network. “Users” are defined as anyone who uses or accesses the .HALAL domain SRS, who has responsibility for one or more host records in the .HALAL zone files generated from the .HALAL SRS, registrants of a .HALAL Top Level (“TLD”) Domain name (“.HALAL Domain name”), and⁄or users of hardware, name servers, bandwidth, telecommunications transport, zone files or e-mail routing services or of any other domain name resolution systems and services in the .HALAL SRS and zone. Exceptions for use will be made for sites that denigrate the Islamic Principles, Culture and History.
This AUP policy applies recursively to all Domain names (which end in the suffix .HALAL), including second-level .HALAL Domain names (such as 〈nic.HALAL〉) and sub second-level domains (such as 〈example.nic.HALAL〉) which are maintained in the authoritative .HALAL register (managed by AGITSys); and those that are created outside the AGITSys TLD register and resolve as a result of sub-delegation by a Registrant. 
No reference in this document constitutes a license to sub-delegate or otherwise sub-license any right obtained under the .HALAL Registrant Agreement, this AUP or other applicable .HALAL TLD Policies.
This AUP is in addition to rules governing qualifications for registration. Use of a .HALAL Domain name or the AGITSys Network in a manner that contravenes this AUP, may result in the suspension or revocation of a registrant’s right to use a .HALAL Domain name or to continue to be recognized as the registrant of a .HALAL Domain name. Suspension or revocation may apply to one or more .HALAL Domain names for which User is a registrant in addition to a particular .HALAL Domain name which may have given rise to a particular complaint. 
AGITSys reserves the right to modify or update this AUP at any time and any such modifications or restatements shall be posted on AGITSys’ website at http:⁄⁄registry.HALAL⁄legal⁄aup.htm from time to time. AGITSys will use reasonable commercial efforts to inform designated contacts in the event of changes to this AUP. Such efforts may include posting the revised AUP on AGITSys’ website and⁄or sending email notice that this AUP has been modified or updated.
INTRODUCTION 
AGITSys supports the free flow of information and ideas over the Internet. 
However, AGITSys protects the .HALAL TLD with rigorous acceptable use certification program in addition to a robust enforcement platform.
AGITSys may discontinue, suspend, or modify the services provided to the registrant of an .HALAL Domain name (for example, through modification of .HALAL zone files), to address alleged violations of this AUP (described further below). AGITSys may determine in its sole discretion whether use of the AGITSys network or a .HALAL Domain name is prima facie violation of this AUP. AGITSys or affected parties may utilize the AGITSys AUP CRS and⁄or the courts in the jurisdiction and venue specified in the Registrant Agreement to resolve disputes over interpretation and implementation of this AUP, as described more fully in the AGITSys AUP CRS. 
Users of the AGITSys Network are obliged and required to ensure that their use of a .HALAL Domain name or the AGITSys Network is at all times lawful and in accordance with the requirements of this AUP and applicable laws and regulations of Turkey.
This AUP should be read in conjunction with the AGITSys Registrant Agreement, Complaint Resolution Policy, Privacy Policy, Acceptable Use Policy, and other applicable agreements, policies, laws and regulations. By way of example, and without limitation, the Registrant Agreement sets forth representations and warranties and other terms and conditions, breach of which may constitute non-compliance with this AUP.
PROHIBITED USE
A “Prohibited use” of the AGITSys Network or a .HALAL Domain name is a use which is expressly prohibited by provisions of this AUP. The non-exhaustive list of restrictions pertaining to use of the AGITSys Network and .HALAL Domain names in relation to various purposes and activities are as follows. Registration of one or more .HALAL Domain names or access to services provided by AGITSys may be cancelled or suspended for any breach of, or non-compliance with this AUP:
1. COMPLIANCE WITH AGITSys AUP
1.1 The AGITSys Network and .HALAL Domain names must be used for lawful purposes and comply 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.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, trademarks, rights of personality, and trade secret information. 
(1.2) Communication, publication or distribution of material (including through links or framing) that denigrates the Islamic Principles, Culture and History.
(1.3) Registration or use of a .HALAL Domain name in circumstances in which, in the sole discretion of the AGITSys:
(1.3.a) The .HALAL Domain name is identical or confusingly similar to a personal name, company, business or other legal or trading name as registered with the relevant Turkish agency, or a trade or service mark in which a third party complainant has uncontested rights, including without limitation in circumstances in which:
(1.3.a.i) The use deceives or confuses others in relation to goods or services for which a trade mark is registered in Turkey, or in respect of similar goods or closely related services, against the wishes of the registered proprietor of the trade mark; or
(1.3.a.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 Turkey, against the wishes of the third party complainant; or
(1.3.a.iii) The use trades on or passes-off a .HALAL Domain name or a website or other content or services accessed through resolution of a .HALAL Domain as being the same as or endorsed, authorized, associated or affiliated with the established business, name or reputation of another; or 
(1.3.a.iv) The use constitutes intentionally misleading or deceptive conduct in breach of AGITSys policy, or the laws of Turkey; or
(1.3.b) The .HALAL Domain name has been used in bad faith, including without limitation the following:
(1.3.b.i) The User has used the .HALAL Domain name primarily for the purpose of unlawfully disrupting the business or activities of another person; or
(1.3.b.ii) By using the .HALAL 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 .HALAL Domain name; 
(1.3.b.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; 
(1.3.b.iv) As a blocking registration against a name or mark in which a third party has superior intellectual or industrial property rights.
(1.4) A .HALAL 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 trademarks in which the User has no apparent rights, and the .HALAL Domain name is part of that pattern;
(1.5) The .HALAL 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.
(1.6) Unlawful communication, publication or distribution of registered and unregistered know-how, confidential information and trade secrets. 
(1.7) Publication or distribution of content which, in the opinion of the AGITSys:
(1.7.a) is capable of disruption of systems in use by other Internet users or service providers (e.g. viruses or malware);
(1.7.b) seeks or apparently seeks authentication or login details used by operators of other Internet sites (e.g. phishing); or
(1.7.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).
(1.8) 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 Muslim community would consider to be obscene or indecent) where such communication, publication or distribution is prohibited by or constitutes an offence under the laws of Turkey, 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 .HALAL TLD. 
Material that a reasonable member of the Muslim 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 child pornography, bestiality, excessively violent or sexually violent material, sexual activity, and material containing detailed instructions regarding how to commit a crime, an act of violence, or how to prepare and⁄or use illegal drugs
(1.9) Communication, publication or distribution of defamatory material or material that constitutes racial vilification.
(1.10) Communication, publication or distribution of material that constitutes an illegal threat or encourages conduct that may constitute a criminal offence. 
(1.11) Communication, publication or distribution of material that is in contempt of the orders of a court or another authoritative government actor within Turkey. 
(1.12) Use, communication, publication or distribution of software, technical information or other data that violates Turkey’s export control laws. 
(1.13) Use, communication, publication or distribution of confidential or personal information or data including confidential or personal information about persons that collected without their knowledge or consent. 
1.2 Acceptable Use Certification Program
Use being deemed “Acceptable” begins with certifications in the registration and renewal process. Certification constitutes a series of acknowledgements that the Registrant is either of Muslim faith, or has a clear interest in ameliorating the community. Acceptable Use Certification contains the following:
1. Registrants must electronically accept that they have pronounced the Shahadah (declaration of faith) which states, “I testify that there is no god except for the God [Allah], and I testify that Muhammad is the Messenger of the God.”, as a Muslim.
2. Registrants must accept and abide by the following:
a. No denegation of The Prophet Mohammad will be propagated within any site content of the .HALAL TLD
b. Messaging about HALAL or the Quran will not criticize HALAL and the Muslim faith
c. Registrants and Users will refrain from activities that runs contrary to Islamic principles
d. Not use the .HALAL TLD or site content as a communications and coordination vehicle of radical or terrorist activities
e. Will not establish third level DNS management of a second level .HALAL domains

2. ELECTRONIC MAIL 
2.1 AGITSys expressly prohibits Users of the AGITSys Network from engaging in the following activities: 
(1.1) Communicating, transmitting or sending unsolicited bulk e-mail messages or other electronic communications (ʺjunk mailʺ or ʺSpamʺ) of any kind including, but not limited to, unsolicited commercial advertising, informational announcements, and political or religious tracts. Such messages or material may be sent only to those who have expressly requested it. If a recipient asks a User to stop sending such e-mails, then any further e-mail messages or other electronic communications would in such event constitute Spam and violate the provisions and requirements of this AUP. 
(1.2) Communicating, transmitting or sending any material by e-mail or otherwise that harasses, or has the effect of harassing, another person or that threatens or encourages bodily harm or destruction of property including, but not limited to, malicious e-mail and flooding a User, site, or server with very large or numerous pieces of e-mail or illegitimate service requests. 
(1.3) Communicating, transmitting, sending, creating, or forwarding fraudulent offers to sell or buy products, unsolicited offers of employment, messages about ʺMake-Money Fastʺ, ʺPyramidʺ or ʺPonziʺ type schemes or similar schemes, and ʺchain lettersʺ whether or not the recipient wishes to receive such messages. 
(1.4) Adding, removing, modifying or forging AGITSys Network or other network header information with the effect of misleading or deceiving another person or attempting to impersonate another person by using forged headers or other identifying information (ʺSpoofingʺ). 
(1.5) Causing or permitting the advertisement of a .HALAL Domain name in an unsolicited email communication.
3. DISRUPTION OF AGITSys NETWORK 
3.1 No-one may use the AGITSys Network or a .HALAL Domain name for the purpose of:
(1.1) Restricting or inhibiting any person in their use or enjoyment of the AGITSys Network or a .HALAL Domain name or any service or product of AGITSys.
(1.2) Actually or purportedly reselling AGITSys services and products without the prior written consent of AGITSys. 
(1.3) Transmitting any communications or activity, which may involve deceptive marketing practices such as the fraudulent offering of products, items, or services to any other party. 
(1.4) Providing false or misleading information to AGITSys or to any other party through the AGITSys Network. 
(1.5) Facilitating or aiding the transmission of confidential information, private, or stolen data such as credit card information (without the owner’s or cardholderʹs consent). 
4. NETWORK INTEGRITY AND SECURITY 
4.1 Users are prohibited from circumventing or attempting to circumvent the security of any host, network or accounts (ʺcrackingʺ or ʺhackingʺ) on, related to, or accessed through the AGITSys Network. This includes, but is not limited to: 
(1.1) accessing data not intended for such user; 
(1.2) logging into a server or account which such user is not expressly authorized to access; 
(1.3) using, attempting to use, or attempting to ascertain a username or password without the express written consent of the operator of the service in relation to which the username or password is intended to function; 
(1.4) probing the security of other networks; 
(1.5) executing any form of network monitoring which is likely to intercept data not intended for such user. 
4.2 Users are prohibited from effecting any network security breach or disruption of any Internet communications including, but not limited to: 
(2.1) accessing data of which such User is not an intended recipient; or 
(2.2) logging onto a server or account, which such User is not expressly authorized to access. 
For the purposes of this section 4.2, ʺdisruptionʺ includes, but is not limited to: 
port scans, TCP⁄UDP floods, packet spoofing;
forged routing information;
deliberate attempts to overload or disrupt a service or host;
using the AGITSys Network in connection with the use of any program, script, command, or sending messages with the intention or likelihood of interfering with another userʹs terminal session by any means, locally or by the Internet.
4.3 Users who compromise or disrupt AGITSys Network systems or security may incur criminal or civil liability. AGITSys will investigate any such incidents and will cooperate with law enforcement agencies if a crime is suspected to have taken place.
5. NON-EXCLUSIVE, NON-EXHAUSTIVE 
This AUP is intended to provide guidance as to what constitutes acceptable use of the AGITSys Network and of .HALAL Domain names. However, the AUP is neither exhaustive nor exclusive. 
6. COMPLAINTS
Persons who wish to notify AGITSys of abusive conduct in violation of this AUP may report the same pursuant to the AGITSys Acceptable Use Policy Enforcement Procedure, which is instituted by submitting to AGITSys a completed AGITSys Acceptable Use Policy Violation Complaint Form. 
7. ENFORCEMENT 
AGITSys may, in its sole discretion, suspend or terminate a Userʹs service for violation of any of the requirements or provisions of the AUP on receipt of a complaint if AGITSys believes:
(1.1.a) a violation of the AUP has or may have occurred; or
(1.1.b) suspension and⁄or termination may be in the public interest. 
AGITSys may delegate its right to take any action to an Internet security agency or may act upon any report from an Internet security agency without prior notification to the User.
If AGITSys elects not to take immediate action, AGITSys may require Registrants and a complainant to utilise the AUP Complaint Resolution Service and Policy to ensure compliance with this AUP and remedy any violation or suspected violation within a reasonable time prior to suspension or terminating service. 
Enforcement Techniques:
Scan of Zone for Content
Scan of Zone for Registered names that fail to meet registration requirements
Scan of zone for third level DNS and domain registration activity
Acceptable Use Recertification at registration and renewal via online registration systems
Review of Registrant contact information against international terrorist watch lists, and collaboration with counter-terrorism organizations
User and⁄or Registrant self-policing and notification of abusive content or activity

8. LIMITATION OF LIABILITY 
In no event shall AGITSys be liable to any User of the AGITSys Network, any customer, nor any third party for any direct, indirect, special or consequential damages for actions taken pursuant to this AUP, including, but not limited to, any lost profits, business interruption, loss of programs or other data, or otherwise, even if AGITSys was advised of the possibility of such damages. AGITSys’ liability for any breach of a condition or warranty implied by the Registrant Agreement or this AUP shall be limited to the maximum extent possible to one of the following (as AGITSys may determine):
(i) supplying the services again; or 
(ii) paying the cost of having the services supplied again. 
9. REMOVAL OF CONTENT RESPONSIBILITY 
At its sole discretion, AGITSys reserves the right to: 
(i) Remove or alter content, zone file data or other material from its servers provided by any person that violates the provisions or requirements of this AUP; 
(ii) re-delegate, redirect or otherwise divert traffic intended for any service; 
(iii) notify operators of Internet security monitoring, virus scanning services and⁄or law enforcement authorities of any apparent breach of this AUP or .HALAL TLD Policies; and⁄or 
(iv) terminate access to the AGITSys Network by any person that AGITSys determines has violated the provisions or requirements of this AUP. 
In any regard, AGITSys is not responsible for the content or message of any newsgroup posting, e-mail message, or web site regardless of whether access to such content or message was facilitated by the AGITSys Network. AGITSys does not have any duty to take any action with respect to such content or message by creating this AUP, and Users of the AGITSys Network are obliged and required to ensure that their use of a .HALAL Domain name or the AGITSys Network is at all times in accordance with the requirements of this AUP and any applicable laws and⁄or regulation.

28.5 CoCCA CRS - Policies and Procedures

1. Statement of Purpose

1.1. This Complaint Resolution Service (ʺCRSʺ) 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 Managers network or services.

1.2. The Service provides a single framework in which cyber-crime, accessibility of prohibited Internet content via a memberʺs network or services 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 lead by an independent Ombudsman, and where applicable, adjudication by an Expert. The CRS provides an efficient and swift alternative to the Courts.

This document should be read in conjunction with the Acceptable Use Policy (ʺAUPʺ) applicable to the domain ⁄ TLD you are considering lodging a complaint against. If after having reviewed the applicable AUP Policy it is determined a violation has occurred, a complaint may be lodged by completing the CoCCA CRS Complaint form.

NOTE: IF YOU DO NOT LODGE THE SIGNED COMPLAINT FORM THAT FOLLOWS BELLOW ON PAGES 8- 13 OF THIS DOCUMENT, YOUR COMPLAINT WILL NOT BE REVIEWED.

Complaints will be reviewed in accordance with the following Steps:

Step One | Confirmation ⁄ Communication

A CoCCA Complaints Officer (ʺCCOʺ) will review all formally lodged complaints for compliance with the CRS and the applicable AUP. If the CCO considers that the Complaint does not address the matter covered by the AUP, or is unsigned or otherwise violates this Procedure, theComplainant will be promptly notified of the deficiencies identified.

The Complainant shall have five (5) Days from the receipt of notification within which to correct the deficiencies and return the Complaint, failing which the CCO will deem the Complaint to bewithdrawn. This will not prevent the Complainant from submitting a different Complaint.

On receipt of the Complaint the CCO will lock domain and associated records until a period of ten (10) Days after the COO and Parties are notified of a Decision by the Ombudsman or and Expert, at which time the domain name may be unlocked.

Step Two | Immediate Review of Request for Suspension in the Public Interest

On receipt of a properly lodged Complaint, the CCO will initiate a review. When specifically requested by the Complainant the CCO may initiate a Critical Issue Suspension (ʺCISʺ).

A request for a CIS may be granted in cases where there is a compelling and demonstrable threat to the stability of the Internet, critical infrastructure or public safety. A ʺcritical issue suspensionʺ does not terminate the registrantʺs rights or their domain license; it simply modifies the NS records in the zone temporarily disabling resolution. All suspensions under the CRS, including a CIS, may be appealed to the Ombudsmanʺs office for amicable resolution, an
Expert Panelist for binding arbitration or a court of competent jurisdiction.

Where the CCO has triggered a CIS, notice will be sent to the Registrant, Administrative Contact, Registrar and Ombudsman within 24 hours of triggering the CIS.

Step Three | Formal Notification

The CCO will send a copy of the Complaint to the Respondent (normally the Registrant and⁄or Administrative Contact) and the TLD Sponsors designated contact with an explanatory note within 5 days by:

a) Sending the Complaint by post, fax or e-mail to the Respondent at the contact details shown as the Registrant or any other contacts in the TLD Register for the Domain Name that is the subject of the Complaint.

b) The CCO may also, at their discretion send the complaint to any addresses provided to the CCO by the Complainant so far as this is practicable.

c) Except as set forth otherwise, all written communication to a Party or a partyʺs representative under the Policy or this Procedure shallbe made by fax, post or e-mail.

d) Communication shall be made in English, E-mail communications (other than attachments) should be sent in plain text or PDF format so far as this is practicable.

During the course of the proceedings under the CRS, if either Party wishes to change its contact details it must notify the CCO of all changes. However, no change shall be made in the Registrant Information for the Domain Name without mutual agreement of the parties or unless a settlement is reached. Except as otherwise provided in this Procedure or as otherwise decided by the CCO or if appointed, the Expert, all communications provided for under this procedure shall be deemed to have been received:

a) if sent by courier, when singed for by the recipient;
b) if sent via the Internet, on the date that the communication was transmitted

Unless otherwise provided in this Procedure, the time periods provided for under the Policy and this Procedure shall be calculated based on the time zone of the CCO.

Any communication between:

a) the CCO and any Party shall be copied by the CCO to the other Party and if appointed, the Ombudsman or Expert;

b) a Party to another Party shall be copied by the sender to the CCO. The CCO will copy such correspondence to the Ombudsman or Expert, if appointed.

Commencement of Complaint Resolution Service proceedings

The CCO will promptly notify the Parties by email of the date of the Commencement of Complaint Resolution Service proceedings. The date
and time of transmission of such email in the time zone of the CCO according to the email header generated by the CCOʺs transmitting emails system will be the date of Commencement of CRS proceedings.

The Response

Within fifteen (15) Days of the date of Commencement of Complaint Resolution Service proceedings, the Respondent may submit a Response.

The Respondent must send the Response to the CCO signed in electronic form at the addresses set out in the explanatory coversheet. In determining whether a Response was submitted in a timely manner, the date and time of receipt (as determined by the CCOʺs receiving email server) shall be considered by the CCO as the date and time of submission, provided that such email i) contains a scanned copy of documents which include signatures, ii) contains all attachments, iii) is of a form and format which may be opened by the CCO. The Response shall:

a) include any grounds that the Respondent wishes to rely upon to rebut the Complainantʺs assertions;

b) specify whether the Respondent wishes to be contacted directly or through an authorized representative, and set out the e-mail address, telephone number, fax number, and postal address which should be used in communications with the Respondent;

c) disclose to the CCO whether any legal proceedings have been commenced or terminated in connection with the Domain Name(s) which is the subject of the Complaint;

d) conclude with the following statement followed by the signature of the Respondent or its authorized representative:

ʺThe information contained in the response is to the best of the respondentʺs knowledge true and complete and the matters stated in this response comply with the Policy and Procedure and applicable law.ʺ

Within (3) Days following the receipt of a signed copy of the Response, the CCO will forward the Response to the Complainant. If the Respondent does not submit a Response, the Domain will be suspended 15 days after the CRS proceedings commence.

Reply by the Complainant

Within five (5) Days of receiving the Respondentʺs Response from the CCO, the Complainant may submit a Reply to the Respondentʺs Response, which shall not exceed 2000 words (not including annexes). The Reply should be confined to answering any new points raised in the Response not previously dealt with in the Complaint.

Step Four | Amicable Complaint Resolution | Ombudsman

No Amicable Complaint Resolution (ʺACRʺ) will occur if the Respondent does not file a Response. Within three (3) Days of the receipt of the Complainantʺs Reply (or the expiry of the deadline to do so), the CCO will arrange with the Ombudsmanʺs office for Amicable Complaint Resolution to be conducted. ACR will be conducted in a manner that the Ombudsman, at his or her sole discretion, considers appropriate.

Negotiations conducted between the Parties during ACR (including any information obtained from or in connection to negotiations) shall be confidential as between the Parties. Any such information will not be shown to an Expert, should one latter be appointed. Neither the Ombudsman nor any Party may reveal details of such negotiations to any third parties unless a decision-making body of competent jurisdiction orders disclosure. Neither Party shall use any information gained during mediation for any ulterior or collateral purpose or include it in any submission likely to be seen by any court or decision-making body of competent jurisdiction or an arbitral tribunal of competent jurisdiction in this Complaint or any later Complaint or litigation.

If the Parties reach a settlement during the ACR, then the existence, nature and terms of the settlement shall be confidential as between the Parties unless the Parties specifically agree otherwise, a court or decision-making body of competent jurisdiction orders otherwise, or applicable laws or regulations require it.

No binding verbal agreements can be reached as part of the ACR: any
settlement reached by the Parties must be in writing to be
enforceable.

If the Parties did not achieve an acceptable resolution through ACR within ten (10) Days, the Ombudsman will send notice to the Parties that the Complainant has the option to request appointment of an Expert. The Complainant will have ten (10) Days upon receipt of the notice from the Ombudsman to pay the applicable fees to CoCCA if he or she wants to move forward with binding arbitration by an Expert.

Step Five | Appointment of the Expert and Timing of Decision (Optional)

If the Ombudsman does not receive the Complainantʺs request to refer the matter to an Expert together with the applicable fees within ten (10) Days, the Complaint will be deemed to have been withdrawn. This will not prevent the Complainant submitting a different Complaint.

Within five (5) Days of the receipt of the applicable fees from the Complainant, the Ombudsman will appoint an Expert on a rotational basis from a list of Experts. An Expert may only be a person named in the CoCCA list of Experts, which the Ombudsman will maintain and publish along with the Expertsʺ qualifications. No Expertʺs appointment will be challenged on the grounds that they are insufficiently qualified. Once the Expert has been appointed, the
Parties will be notified of the name of the Expert appointed and the date by which the Expert will forward, except in the case of exceptional circumstances, his or her decision to the CCO and copy the Ombudsman.

The Expert shall be both impartial and independent before accepting the appointment. During the proceedings the Expert will disclose to the Ombudsman any circumstances giving rise to the justifiable doubt as to their impartiality or independence. The Ombudsman will have the discretion to appoint a substitute Expert if necessary, in which case the timetable will be adjusted accordingly.

In addition to the Complaint, and if applicable the Response, the Reply, any appeal notice and appeal notice response, the Expert may request further statements or documents from the Parties. However, the Expert will not be obliged to consider any statements or documents from the Parties which he or she has not received according to the Policy or this Procedure or which he or she has not requested. The Expert may request a further statement that will be limited to a defined topic but will not be obliged to consider any material beyond that requested.

Step Six | Expert Decision

The Expert will decide a Complaint on the basis of the Policy, the Procedure and the submissions made by the Party. If, in the absence of exceptional circumstances, a Party does not comply with any provision in the Policy, Procedure or any request by the Ombudsman or the Expert, the Expert may draw such inferences from the Partyʺs non-compliance, as he or she deems appropriate.

Unless exceptional circumstances apply, an Expert shall forward his or her Decision to the Ombudsman within ten (10) Days of his or her appointment. The Decision shall be in writing and signed by the Expert. It will provide the reasons on which the decision is based, indicate the date on which it was made, the place the Decision was made and identify the name of the Expert. Within three (3) Days of the receipt of a Decision from the Expert, the Ombudsman will communicate the full text of the Decision to each Party via email with the date for the implementation of the Decision in accordance with the Policy.

Effect of Court Proceedings

If, before or during the course of proceedings under the Complaint Resolution Service, the Ombudsman is made aware that legal proceedings have begun in or before an applicable court or decision-making body of competent jurisdiction or an arbitral tribunal of competent jurisdiction, and that such legal proceedings relate to a Domain Name which is the subject of a Complaint, he or she will suspend the Complaint Resolution Service proceedings pending the outcome of the
legal proceedings.

A Party must promptly notify the Ombudsman if it initiates or becomes aware of legal proceedings in a court or decision-making body of competent jurisdiction, or arbitral tribunal of competent jurisdiction relating to a Domain Name that is the subject of a Complaint under the proceedings of the Complaint Resolution Service.

Either party may request, before or during the Complaint Resolution Service Proceedings, an interim measure of protection from a court.

Expert Fees

The applicable fees in respect of the referral of proceedings under the Complaint Resolution Service to an Expert are (in United States Dollars), for Complaints involving 1-5 Domain Names and only one Complainant, $2500 plus applicable taxes, such as goods and services taxes (ʺGSTʺ). For Complaints involving 6 or more Domain Names, and ⁄ or more than one Complainant, the Ombudsman will set a fee in consultation with the Complainant. Fees are calculated on a cost-recovery basis, and are passed on in their entirety to the
Expert(s). CoCCA does not charge for its mediation or administration services in respect of the Complaint Resolution Service.

Exclusion of Liability

Neither CoCCA nor its councilors, officers, members, employees or servants nor any Expert, Mediator or any employee of any Expert or Mediator shall be liable to a Party for anything done or omitted, whether negligently or otherwise, in connection with any proceedings under the Complaint Resolution Service unless the act or omission is shown to have been in bad faith.

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. is fully aware of the importance of protecting the rights of others in the .halal gTLD and has made rights projections a core objective. The .halal TLD Rights Protection is something CoCCA has prioritized by necessity throughout its nine-year history. CoCCA currently complies with UDRP proceedings and will comply with URS proceedings as well with methods for handling Sunrise and Trademark Claims outlined below and guided by Specification requirements of the proposed Registry Agreement. 

CoCCA also 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 that any interested party can subscribe to, alerting them if a specific string is registered in any CoCCA TLD. CoCCA recognizes that ICANN has not completed the Trademark Clearing House (TMCH) program. 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 CRS
Limited License
Rapid Takedown & Suspension
Malware Mitigation
Fast Flux Mitigation
Phishing Mitigation
DNSSEC Deployment 
Law Enforcement and Anti-Abuse Community Collaboration
29.1 Registration Abuse Prevention Mechanisms – Pre Launch
To support Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ s objectives, CoCCA will implement specific measures in compliance with ICANN’s Applicant Guide Book. At a minimum, ICANN states that Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. must offer sunrise registration for a period of thirty days during pre-launch in conjunction with the Trademark Clearing House. 

CoCCA’s RPM framework 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. or Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ approved Registrar. 
 
During the Sunrise, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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⁄residents⁄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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 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 .halal 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, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. requires that domain names within the .halal TLD should consist of proper characters unique within top-level domain, followed by the characters ‘.halal’. 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
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has developed an Acceptable Use Policy (AUP) 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 .halal domain name. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal TLD. See Life-Cyle and 
29.2 Rights Protection Mechanisms – Post Launch
CoCCA offers a suite of post-launch Rights Protection Mechanisms. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti., 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, PDDRP and RRDRP
Limited License
Rapid Takedown & Suspension
Malware Mitigation
Fast Flux Mitigation
Phishing Mitigation
DNSSEC Deployment 
Law Enforcement and Anti-Abuse Community Collaboration
29.2.1 Unqualified Registration Safeguards
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. plans to adopt the CoCCA Acceptable Use Policy (AUP) and Complaint Resolution Service Policy (CRS) as part of the operation of the .halal gTLD. See 28.X

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 TLD AUP policy, WHOIS policy and Complaint Resolution Service.

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 these policies.

The same process therefore allows the registry the opportunity to verify the accuracy of customer data supplied by the registrar, use dynamically generated images as a challenge-response verification to prevent automated processes activating domains and to directly collect and store additional identifying information about registrants, which can be utilized to control fraud.
29.2.2 Wildcard Defensive Registrations
CoCCA currently supports a Wildcard option, which will extend to all new gTLDs in which a brand owner⁄ trademark holder may register a Primary domain and then can upload evidence of the trademark or other rights via PDF in the 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 approval, collisions with other strings etc. If approval is granted, any attempt to register any domain that triggers that string returns ʺnot available for policy reasonsʺ via EPP or GUI.

The domain must be kept current and up to date in order for the Wildcard Registration to be active if the Primary registration lapses, or is subject to a dispute or UDRP ruling and is transferred the Wildcard is removed.
29.2.3 Alert
Subscribers to the Premium WHOIS service may request email alerts if a domain matching a given string, or containing a specified string, is Registered. 
29.2.3 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 in with gTLD clearinghouse.
29.2.4 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. and its Registrars specifies that Registrant information should be complete and accurate and instances where incomplete information occurs will be investigated to prevent reoccurrence. Given the current state nature of WHOIS, CoCCA intends to adapt to new formats and protocols as they go into effect.
29.2.5 Registrar Relationship
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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, ICANN accredited Registrars will only be used and be bound to the registry-registrar agreement. Certain components of the RPM framework will be administered on behalf of Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.. To ensure compliance with designated RPMs, CoCCA will conduct annual reviews and enforce non-compliance where necessary. In cases where Registrars fail to meet Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ standards, the Registrar will lose its certification to register domains of the TLD until all issues are resolved.
29.2.6 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 use as good faith. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ must implement and respond to UDRP policy where applicable. Penalties will apply where Registrars are found to be in breach.
29.2.7 Uniform Rapid Suspension (URS)
CoCCA is required to implement the Uniform Rapid Suspension (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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. to place the domain in question in lock status within NEED A TIMEFRAME, meaning that no changes to registration data will occur, but the domain continues to resolve. Upon lock of the domain, the Registrant will be notified and 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 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.8 Post-Delegation Dispute Resolution Procedure (PDDRP)
Per the Applicant Guidebook, CoCCA is required to implement the Post-Delegation Dispute Resolution Procedure (PDDRP) that allows a complainant the right to object to Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ manner of operation or use of the gTLD. A PDDRP provider will accept objections and perform a threshold review. CoCCA will respond to the complaint as necessary to defend the operation and use Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ .halal gTLD.
29.2.9 Registration Restriction Dispute Resolution Procedure (RRDRP)
The Registration Restrictions Dispute Resolution Procedure (RRDRP) outlines the resolution proceedings whereby the Complainant determines that Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. violated its community-based restrictions and that measurable harm occurred. Upon administrative review of the complaint, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will file a response within 10 days of the filing.
If the complainant is determined to be the prevailing party, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will pay all Panel and Provider fees incurred, including filing fees. If Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. is found to have violated its registration restrictions, Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will implement all remedial measures outlined by the Expert Panel, including cases where registration suspension may occur. Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. recognizes that this procedure does not preclude entities seeking remedies in courts of laws.
29.2.10 Limited License
Limited License- Registration policies and terms and conditions limit registrants’ rights to a limited license to use (but not to sub-license the use of any portion of) the allocated TLD, subject to continuing compliance with all policies in place during that time.
29.2.11 Rapid Takedown & Suspension
CoCCA, at Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ request, will comply with any takedown or suspension. Usually, these types of requests are based on court orders of competent jurisdiction, but not limited to such. Before any domain take down, CoCCA maintains an internal checklist that will be followed to ensure validation of the request. If for any reason the validation procedure fails, the CoCCA Ombudsman will be notified. Upon confirmation that the registered domain is to be suspended or removed from the zone, CoCCA will execute its auditable procedure documenting the incident number, date, time, domain name, threat level, description and reason for the take down, and any other evidence that may be necessary to properly document the take down. The Ombudsman, Registrar, and Registrant will be notified before and at the time of take down execution.
29.2.13 Malware Mitigation
Where commercially sensible, or a risk factor has been identified, CoCCA will perform automated and regular scanning for malware of all domains (or a subset of domains) in the registry. Often, Registrants are unaware and compromised by malware deployments. Scanning for malware reduces occurrences for this type of abusive behavior for registered domain names in the TLD. 
29.2.14 Phishing Mitigation
CoCCA will establish and act upon the results of a regular poll against one or more trusted databases for phishing sites operating (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.
29.2.15 DNSSEC Deployment
As part of Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ 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:
Security of Domain Resolution – DNSKEY⁄RRSIG provide authentication and integrity verification to ensure data will be compromised during transmission. The CoCCA credit 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.
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.16 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 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 identification of wrongdoers. The existence of existing arrangements for dealings between security agencies and the registry operator facilitates the ability for both registry and law enforcement to react promptly to threats, promptly minimizing harm. With respect to suspensions, the registrant will be given an opportunity to remedy via automated processes, given the time sensitive nature of criminal activity automated suspension based on triggers ⁄ flags, or at the request of law enforcement should be enabled. Critical domains can be manually ʺSuper Lockedʺ in the registry to ensure they are not removed from the zone or suspended inadvertently by automated suspension technology. Automated suspensions will only be initiated when required to protect the public interest or network integrity. They should not be initiated to simply protect an entity’s or individuals intellectual or other property rights - those sorts of disputes should be dealt with via a formal complaint resolution service.
29.3 Resource Plans
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. will dedicate 2 professionals to coordinate the operation of the .halal gTLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .halal gTLD. 
As the .halal gTLD is a community-supported effort, it is also expected that members of the community will help Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. develop policies and procedures that govern the operation of the gTLD. 

The following Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. team members will be used to support the rights protection plan; CoCCA NOC Support, Ombudsman. 

CoCCA acting as Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.’ registry services provider maintains a resource model to meet the demands of RPM implementation and on-going operation of the protection mechanisms. CoCCA maintains a qualified and experienced technical staff to support registry services that meet or exceed defined service levels. 
 
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 staff 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 can be found in response to questions of the Financial Projections section of the application.

There are eight CoCCA CRS Officers whose Role is to monitor registry services and review Complaints lodged online or from Law Enforcement ⁄ CERTs CoCCA has an established formal relationship with.

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.
CoCCA estimates it will require the following personnel to support the RPM implementation and operations for Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.:

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

Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .halal 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 .halal 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 .halal

The .halal 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 .halal DNS infrastructure and Nodes

The .halal 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 .halal 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 .halal to absorb even a coordinated DoS attack originating from multiple locations at once. 

The geographically diverse Anycast network proposed for .halal 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. 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 .halal 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 .halal 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 Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has at least two ʺlast resortʺ DNS nodes under direct management. Both PCH and ISC networks provide the .halal 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 .halal 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 .halal 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.