ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti.

String: همراه

Originally Posted: 13 June 2012

Application ID: 1-2134-95773


Applicant Information


1. Full legal name

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

2. Address of the principal place of business

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

3. Phone number

 
+90 212 605 6551

4. Fax number

 
+90 212 603 6550

5. If applicable, website or URL

 








Primary Contact
 





6(a). Name



Mehdi Abbasnia






6(b). Title



Managing Director






6(c). Address






6(d). Phone Number



+90 533 224 7892






6(e). Fax Number









6(f). Email Address



agitsys7@nsline.com








Secondary Contact
 





7(a). Name



Hakan Atalay






7(b). Title



The Head of Engineering Dept.






7(c). Address






7(d). Phone Number



+90 212 605 6551






7(e). Fax Number









7(f). Email Address



hakan.atalay@agitsys.com








Proof of Legal Establishment
 





8(a). Legal form of the Applicant



Limited Company






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



Trade Registration Office (Ticaret Sicili Memurlugundan)






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



Attachments are not displayed on this form.






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









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









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











Applicant Background
 





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



Ali ZarinbakhshMember of the board
Mehdi AbbasniaManaging Director






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



Fatih AtasoyCFO
Mehdi AbbasniaManaging Director






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



Ali ZarinbakhshMember of the board
Mehdi AbbasniaManaging Director






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











Applied-for gTLD string
 





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



همراه






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



xn--mgbt3dhd






14(b). If an IDN, provide the meaning or restatement of the string 

in English, that is, a description of the literal meaning of the string in the 

opinion of the applicant.



Compeer, comrade, concomitant, along with, together with each other.






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



Persian






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



FA






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



Arabic






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



Arab 160






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



U+0647, U+0645, U+0631, U+0627, U+0647






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



Attachments are not displayed on this form.






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



The process used for development of the IDN tables submitted is the following:
- Conducting talks with the .ir ccTLD registry, which has successfully developed a table for .iran as well as successfully and run a successful test bed.  
- Reading the ICANN VIP working group report regarding Arabic script.
- Reading the ASIWG (Arabic Script Working Group) materials, documents and list archive.
- Consulting with language professors at several Universities.
- Contacting and coordinating with other communities working in this area.

AGITSys has partnered with CoCCA for Registry Services.  CoCCA is one of a select few registry companies whose technology currently is used to power IDN TLD’s. CoCCA’s pamoja SRS system, the same software that will be used to run the .hamrah gTLD was chosen by the National Telecommunications Regulatory Authority in Egypt (NTRA) to mange the “ xn--wgbh1c”, the Palestinian National Internet Naming Authority PNINA, to manage “xn--ygbi2ammx” and the National Agency for Network Services (NANS) to manage the Syrian “xn--ogbpf8fl ⁄ xn--mgbtf8fl”.
All three were approved under ICANN’s ccTLD fast track program and are in production. The flexible, proven pamoja software has full support for Arabic variants and folding as well as a variety of tools to support all manner of IDN’s.






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



None.






16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string.

If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.



The team behind Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. has been involved in IDN names for many years.

The TLD is right-to-left and the registry operator is aware of that so they perform tests to ensure no rendering problem in different environments. Such testing has included all major browsers (eg. Firefox, Google Chrome, IE ) in many versions, all popular operating systems (Windows, Linux, MacOS) and all major Office products (Microsoft Office, Open Office, Libre Office).

The TLD is using single script and the character table was also designed and based on IDNA2008 to make sure there are no rendering issues.






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



N⁄A










Mission/Purpose
 





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



18(a)

There are in excess of a hundred million of Persians worldwide. They are a disparate group, yet they are united through their core beliefs. They are a group whose origins are found several millennia in the past, their ethnicity often inextricably linked with their heritage. Hitherto, however, there has been no way to easily unify them and their common cultural, linguistic and historical heritage. The word .همراه (.hamrah) means concomitant, compeer or comrade, bringing a sense of being together. Thus, the .همراه (.hamrah) gTLD, and the online unification it will create, is the perfect way to bring this disparate group together.
The origins of the ethnic Persian community can be traced to the Ancient Iranian peoples, who were part of the ancient Indo-Iranians and themselves part of the greater Indo-European linguistic family. The Ancient Iranian peoples arrived in parts of Iranian plateau around 2000-1500 BCE. Important Iranian tribes such as Old Persians, Medes, Parthians, Bactrians, Scythians, and the Avesta people used the name Arya (Iranian), which was a collective definition, denoting peoples who were aware of belonging to the one ethnic stock, speaking a common language, and mainly sharing a religious tradition that centered on the worship of Ahura Mazda. 
The Old Persians (one of these ethnic Iranian groups) were originally nomadic, pastoral people occupying the western Iranian plateau. By 850 BCE they were calling themselves the Parsa, and their constantly shifting territory Parsua for the most part localized around Persis (Pars), bounded on the west by Tigris River and on the south by Persian Gulf. The first known written record of the term Persian is from Assyrian inscriptions of the 9th century BCE, which mention both Parsuash and Parsua. These cognate words were taken from old Iranian Parsava and presumably meant border, borderland and were geographical designations for Iranian populations. Nonetheless, Parsua and Parsuash were two different geographical locations - the latter referring to southwestern Iran, known in Old Persian as Pârsa (Modern Fars). The Greeks (who tended earlier to use names related to ʺMedianʺ) began in the 5th century to use adjectives such as Perses, Persica or Persis for Cyrus the Greatʹs empire, which is where the word Persian in English comes from. In the later parts of the Bible, where this kingdom is frequently mentioned (Books of Esther, Daniel, Ezra and Nehemya), it is called ʺParasʺ (Hebrew פרס ), or sometimes ʺParas ve Madaiʺ (פרס ומדי ) i.e. ʺPersia and Mediaʺ. As the Old Persians gained power, they developed the infrastructure to support their growing influence including creation of a capital named Pasargadae, and an opulent city named Persepolis.
Starting around 550 BCE, from the region of Persis in southern Iran, encompassing the present Fars province, the ancient Persians spread their language and culture to other parts of the Iranian plateau and assimilated and intermingled with local Iranic and indigenous non-Iranic groups including the Elamites over time. Persians also interacted with other ancient civilizations in Europe and Africa. The first Persian Empire extended as far as the limits of the Greek city states, where Persians and Athenians influenced each other in what is essentially a reciprocal cultural exchange.
While the .همراه (.hamrah) gTLD ties back linguistically and culturally to the Persian people, it also has the potential to tie together the tens of millions of people across the globe who read Persian-script languages.
The word همراه (hamrah) particularly brings Persian speaking people together because it provides a sense of “not being alone” because of the meaning it has (as described above, concomitant and other derivations of this concept). Equally, .همراه (.hamrah) will offer Persians worldwide the opportunity to read their desired content purely in Persian script, facilitating internet use for those who do not speak English. Thus, while the .همراه (.hamrah) TLD ties back linguistically and culturally to the Persian people, it also has the potential to tie together the tens of millions of people across the globe who read Persian-script languages.
A robust gTLD has the power to bring together people across national borders in a free-flowing exchange of information and commerce. There is not a .COM or .ORG equivalent of the .همراه (.hamrah) --a domain that has universal appeal across a common origin.  ICANN is dedicated to creating more competition in the TLD space, and the introduction of Persian-speakers online through a .همراه (.hamrah) gTLD does so in one simple stroke. 
Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) was founded by individuals of Persian origin who derive a great sense of honor and pride from their community, history and ancestry. AGITSys’ founders have gathered together a team with extensive experience in Persian language on the Internet, a daunting but critical task. The team behind AGITSys, including technical advisor⁄member Dr. Shahram Soboutipour, has taken a leading role in working toward Persian domain names (something it considers inevitable) for more than 8 years. No entity is better suited to manage the .همراه (.hamrah) gTLD, nor more dedicated to providing new online tools and services to facilitate the unification of the .همراه (.hamrah) community online. The .همراه (.hamrah) gTLD will increasingly open up the vast resources of the Internet and the associated global interconnectedness to this Persian community, while stimulating the introduction of more online information and resources in the Persian language – and AGITSys will be at the helm of this change.
The company is not only perfectly situated ideologically, but also physically, as is headquartered in Turkey, which ties together the global Persian population through close relations both with the citizens of Persian-speaking countries in the East, as well as the diasporas of Persian language speakers in Western nations. Turkey’s geographical and political location aids it enormously in the endeavors needed for the .همراه (.hamrah) gTLD to be a success, as it literally and figuratively sits in-between the East and West. This is important because the .همراه (.hamrah) gTLD is designed to accommodate people from all over the world, not only traditionally Persian areas. Thus, AGITSysʹ team’s work with ICANN has always looked toward not just to serving the Afghan, Tajik and Iranian people but all users of Persian-script languages.






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



18(b)

The benefits of the .همراه (.hamrah) gTLD will be manifold, not just to registrants but also to tens of millions of Persian internet users, as well as many others with an interest in or curiosity regarding Persia. The presence of a Persian-specific gTLD will increase the volume of online Persian resources, as the emergence of the .همراه (.hamrah) second-level domains sees a marked increase in the use of Persian script online – which should in turn create further demand. In terms of goals in the areas of specialty, service levels, and reputation for the proposed .همراه (.hamrah) gTLD, AGITSys is committed to offering choice in top level domain extensions among Persians and readers of Persian script.  Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. (AGITSys) recognizes many new gTLDs will naturally have a relatively narrow appeal and audience. The .همراه (.hamrah) gTLD is different, as it not only targets a distinct online community, but one that spans the globe. Therefore, 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 Persian community together through a dedicated gTLD, as well as bringing Persians in to the larger online community. No organization has a greater understanding both of the opportunities a .همراه (.hamrah) gTLD will afford as well as the challenges that its adoption and spread will bring. AGITSys is prepared to ensure the success of .همراه (.hamrah), 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 .همراه (.hamrah) 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 well-known in the ICANN community as a selfless champion of the interests of Persians around the world, including those with ties to the Persian language and thus the idea of همراه (Hamrah). 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 .همراه (.hamrah) gTLD.
Under the shepherding of AGITSys, the .همراه (.hamrah) gTLD will increase competition, provide more online differentiation for customers and consumers, while also driving digital innovation.  The addition of the .همراه (.hamrah) gTLD will create new competition for names within the domain name space. Not only will the offering of .همراه (.hamrah) domains create competition within content providers for users of Persian language 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 .همراه (.hamrah) gTLD will quickly develop as a favored gTLD among Persian-script readers worldwide. The demand for Persian script 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 Persian-script reading population demand content that is tailored to their own unique needs and wants, under the umbrella of a dedicated gTLD. .همراه (.hamrah) will be one such gTLD. As stated in 18(a) above, as Persian-script 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 .همراه (.hamrah) 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 population of Persian-script readers, 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 .همراه (.hamrah) 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 .همراه (.hamrah) gTLD become synonymous with a safe and trusted online experience.
AGITSys will not tolerate radical content, nor will it tolerate content that criticizes Persia and the Persian culture. 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. 
Because of its dedication to the promulgation of Persian script and language online and the .همراه (.hamrah) 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 .همراه (.hamrah) 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 outreach by the .همراه (.hamrah) gTLD, it is expected that the momentum around .همراه (.hamrah) will build quickly, given the pent-up demand that has been building for years within the ranks of the Persian-speaking (and Persian script-reading) people. AGITSys, as their champion in gTLD discussions, knows full well how popular this service will be.
Augmenting this, AGITSys is also active in the business community within Turkey and Middle Eastern countries and interconnected across the spectrum of the Persian–speaking world due to its promotional efforts with ICANN and elsewhere. It will leverage that network to spread the word of the .همراه (.hamrah) gTLD in order to promote adoption.  The best steps AGITSys can take to ensure the gTLDs’ 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 by itself.






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



18(c) 
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 .همراه (.hamrah) second-level domain, not least because AGITSys has every incentive to encourage the adoption and growth of the .همراه (.hamrah) 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. In terms of cost, benefits, and incentives to registrants of the Persian-speaking population, AGITSys will offer fair and competitive pricing campaigns, introducing them to the wonders of the Internet and the Persian culture 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 .همراه (.hamrah) 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 Persian-speakers through Internet technologies remains our first priority.  










Community-based Designation
 





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



No






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









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









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









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









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









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



Attachments are not displayed on this form.










Geographic Names
 





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



No






Protection of Geographic Names






22. Describe proposed measures for protection of geographic names at

 the second and other levels in the applied-for gTLD.



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 .همراه (.hamrah) 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.”










Registry Services
 





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



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 .همراه (.hamrah) TLD. The .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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, .همراه (.hamrah) 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 .همراه (.hamrah) TLD when launched. 

.همراه (.hamrah) 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 .همراه (.hamrah) to the CoCCA CRS, Acceptable Use Policy and Privacy and RDDS Policy via the .همراه (.hamrah) 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 .همراه (.hamrah) 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.










Demonstration of Technical & Operational Capability
 





24. Shared Registration System (SRS) Performance



The .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah):

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

* .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) will be branded as epp.nic.همراه 

24.3	WHOIS Interface (port 43 and 443)

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

24.4	GUI Interface (port 443)

The GUI Interface for .همراه (.hamrah) 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 .همراه (.hamrah) will be branded as ʺregistry.nic.همراه ʺ.

24.5	Hidden Master DNS (s) (port 53)

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

24.7	Public anycast DNS

CoCCAʹs distribution master notifies the anycast providers (PCH and ISC) and .همراه (.hamrah) 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






25. Extensible Provisioning Protocol (EPP)



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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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.همراه.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 .همراه (.hamrah) 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.







26. Whois



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 .همراه (.hamrah) 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.همراه  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 .همراه (.hamrah) 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 .همراه (.hamrah). 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.همراه  and abc.domain.همراه  does not exist then the SRS would display the information on domain.همراه 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 .همراه (.hamrah) TLD.   

If WHOIS caching is required as the .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) TLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating  the .همراه (.hamrah) TLD.






27. Registration Life Cycle



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

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

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. Abuse Prevention and Mitigation



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 .همراه (.hamrah) TLD to the CoCCA Complaint Resolution Service (ʺCRSʺ). Any individual who has a concern regarding abuse involving a .همراه (.hamrah) domain, glue record, or the CoCCA PCH or ISCʺs network services as they relate to .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) TLD Registrant Agreement (“RA”). This RA is a collateral agreement that supersedes any Registrar – Registrant agreement and binds all Registrants to the .همراه (.hamrah) AUP, Privacy and WHOIS policy, CoCCA CRS and any other requirements or dispute mechanisms mandated by ICANN.  

The draft .همراه (.hamrah) AUP follows below in sections 28.4. The RA and WHOIS and Privacy Policy may be viewed at http:⁄⁄coccaregistry.net⁄hamrah⁄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 .همراه (.hamrah) 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  .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) TLD is well protected against abuse targeting the .همراه (.hamrah) 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 Acceptable use policy
INTRODUCTION 
AGITSys supports the free flow of information and ideas over the Internet. AGITSys does not exercise editorial control over the content of any message or web site made accessible by domain name resolution services in the .HAMRAH (IDN) (همراه) TLD. 
AGITSys may discontinue, suspend, or modify the services provided to the registrant of an .HAMRAH (IDN) (همراه) Domain name (for example, through modification of .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) Domain names in relation to various purposes and activities are as follows. Registration of one or more .HAMRAH (IDN) (همراه) Domain names or access to services provided by AGITSys may be cancelled or suspended for any breach of, or non-compliance with this AUP:
COMPLIANCE WITH AGITSys AUP
The AGITSys Network and .HAMRAH (IDN) (همراه) 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: 
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. 
Communication, publication or distribution of material (including through links or framing) that denigrates the Persian Language, Culture and History.

Registration or use of a .HAMRAH (IDN) (همراه) Domain name in circumstances in which, in the sole discretion of the AGITSys:
The .HAMRAH (IDN) (همراه) 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:
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
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
The use trades on or passes-off a .HAMRAH (IDN) (همراه) Domain name or a website or other content or services accessed through resolution of a .HAMRAH (IDN) (همراه) Domain as being the same as or endorsed, authorized, associated or affiliated with the established business, name or reputation of another; or 
The use constitutes intentionally misleading or deceptive conduct in breach of AGITSys policy, or the laws of Turkey; or
The .HAMRAH (IDN) (همراه) Domain name has been used in bad faith, including without limitation the following:
The User has used the .HAMRAH (IDN) (همراه) Domain name primarily for the purpose of unlawfully disrupting the business or activities of another person; or
By using the .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) Domain name; 
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; 
As a blocking registration against a name or mark in which a third party has superior intellectual or industrial property rights.
A .HAMRAH (IDN) (همراه) 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 .HAMRAH (IDN) (همراه) Domain name is part of that pattern;
The .HAMRAH (IDN) (همراه) 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.
Unlawful communication, publication or distribution of registered and unregistered know-how, confidential information and trade secrets. 
Publication or distribution of content which, in the opinion of the AGITSys:
is capable of disruption of systems in use by other Internet users or service providers (e.g. viruses or malware);
seeks or apparently seeks authentication or login details used by operators of other Internet sites (e.g. phishing); or
may mislead or deceive visitors to the site that the site has an affiliation with the operator of another Internet site (e.g. phishing).
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 community of Turkey 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 .HAMRAH (IDN) (همراه) TLD. 
Material that a reasonable member of the community of Turkey 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
Communication, publication or distribution of defamatory material or material that constitutes racial vilification.
Communication, publication or distribution of material that constitutes an illegal threat or encourages conduct that may constitute a criminal offence. 
Communication, publication or distribution of material that is in contempt of the orders of a court or another authoritative government actor within Turkey. 
Use, communication, publication or distribution of software, technical information or other data that violates Turkey’s export control laws. 
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. 
ELECTRONIC MAIL 
AGITSys expressly prohibits Users of the AGITSys Network from engaging in the following activities: 
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. 
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. 
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. 
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ʺ). 
Causing or permitting the advertisement of a .HAMRAH (IDN) (همراه) Domain name in an unsolicited email communication.
DISRUPTION OF AGITSys NETWORK 
No-one may use the AGITSys Network or a .HAMRAH (IDN) (همراه) Domain name for the purpose of:
Restricting or inhibiting any person in their use or enjoyment of the AGITSys Network or a .HAMRAH (IDN) (همراه) Domain name or any service or product of AGITSys.
Actually or purportedly reselling AGITSys services and products without the prior written consent of AGITSys. 
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. 
Providing false or misleading information to AGITSys or to any other party through the AGITSys Network. 
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). 
NETWORK INTEGRITY AND SECURITY 
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: 
accessing data not intended for such user; 
logging into a server or account which such user is not expressly authorized to access; 
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; 
probing the security of other networks; 
executing any form of network monitoring which is likely to intercept data not intended for such user. 
Users are prohibited from effecting any network security breach or disruption of any Internet communications including, but not limited to: 
accessing data of which such User is not an intended recipient; or 
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.
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.
NON-EXCLUSIVE, NON-EXHAUSTIVE 
This AUP is intended to provide guidance as to what constitutes acceptable use of the AGITSys Network and of .HAMRAH (IDN) (همراه) Domain names. However, the AUP is neither exhaustive nor exclusive. 
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. 
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:
a violation of the AUP has or may have occurred; or
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. 
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’s 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):
supplying the services again; or 
paying the cost of having the services supplied again. 
9.	REMOVAL OF CONTENT RESPONSIBILITY 
At its sole discretion, AGITSys reserves the right to: 
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; 
re-delegate, redirect or otherwise divert traffic intended for any service; 
notify operators of Internet security monitoring, virus scanning services and⁄or law enforcement authorities of any apparent breach of this AUP or .HAMRAH (IDN) (همراه) TLD Policies; and⁄or 
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 .HAMRAH (IDN) (همراه) 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.






29. Rights Protection Mechanisms



Asia Green IT System Bilgisayar San. ve Tic. Ltd. Sti. is fully aware of the importance of protecting the rights of others in the .همراه (.hamrah) gTLD and has made rights projections a core objective. The .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) TLD should consist of proper characters unique within top-level domain, followed by the characters ‘.همراه (.hamrah)’.  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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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.’ .همراه (.hamrah) 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 3 professionals to coordinate the operation of the .همراه (.hamrah) gTLD.  At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .همراه (.hamrah) gTLD.  
As the .همراه (.hamrah) 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






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



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 .همراه (.hamrah) TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah)

The .همراه (.hamrah) 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 .همراه (.hamrah) DNS infrastructure and Nodes

The .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) to absorb even a coordinated DoS attack originating from multiple locations at once. 

The geographically diverse Anycast network proposed for .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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 .همراه (.hamrah) 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.
















© Internet Corporation For Assigned Names and Numbers.