Application number: 1-1276-92005 for Atgron, Inc.

Atgron, Inc.

8201 Corporate Drive
Suite 500
Hyattsville, MD 20785
US

3013750748

2025959095

Adrienne McAdory

President & CEO

3013750748

amcadory@atgron.com

Maxine Luster

Managing Principal

3018873429

mluster@atgron.com

Corporation

State of Delaware United States of America

Not Available

Adrienne McAdory
President & CEO
Curtis Ransom
Director
Daria Williams
Director
Darryl Taylor
Director

Maxine Luster
Managing Principal

Adrienne McAdory
President & CEO

wed

Not Available

16 Operational or Rendering Problems with .WED gTLD
There are no current top level domain strings similar in English common lexicon or character set to the applied-for gTLD mitigating the risk of any operational or rendering problems. 

18.1 .WED gTLD Mission⁄Purpose

18.1.1 Company Mission

Atgronʹs mission for the .WED gTLD is to provide wedding couples around the world an unambiguous domain name of their choice via this niche gTLD. The .WED gTLD will be an open unrestricted registry but will institute policies designed to promote short-term annual registrations of domain names with the intent to create more frequent availability of domain names to a never ending supply of wedding couples.

18.1.2 Community Mission

While the .WED gTLD will not be a community-based gTLD, Atgron, Inc., the TLD Registry Operator, has a community mission. The community mission of the organization is to honor the service and dedication of soldiers and sailors in the United States by providing employment and training to veterans who wish to re-enter civilian work life in a technical field.

The driving force for both our Company and Community missions is our Chief Executive Officer, with the support of the Atgron, Inc. Board of Directors. Our CEO and Board chose a gTLD extension, which would create inherent leadership roles for women. Our CEO also spent a significant portion of her career working with soldiers and sailors and recognizes the invaluable training our veterans obtain while in service. There is a perception it is a civic duty to employ veterans and while that is a noble sentiment, it distracts from a far more important factor to a successful business. Veterans represent an outstanding candidate pool of capable resources with training and discipline that will benefit any company. 


18.2.3 Pledge to Customers

The .WED gTLD will provide a wholesome, responsive venue for couples and families involved in the planning and execution of a wedding. We will strive to provide couples with their desired domain names in a timely fashion by discouraging domain name parking and other forms of domain name speculation.


18.1.4 Pledge to Employees

Our employees will enjoy a friendly, fair, and creative work environment, which respects diversity, new ideas, and hard work.

18.2 Goal of .WED gTLD

18.2.1. What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation? 


Wedding Couples

Our key constituency is couples planning their wedding around the world but with an initial marketing focus in the United States of America. Our target market is couples who want to share their experience via the internet without the need to use the gateways of wedding website resellers in the .com, .biz, .org, .net and other gTLD and ccTLD spaces. The .WED TLD brand will be one that epitomizes the special nature of a wedding and recognizes the significant investment families make in creating an event they will treasure forever. Couples will no longer have to provide their personal information to login to wedding website vendor reseller sites or leverage these reseller website offerings at the third level due to the limited availability of .com and other gTLD domain names. .WED provides an immediate connection between the domain name and the event eliminating the need for longer domain name strings. 

.WED will be an open and unrestricted registry. The pricing strategy, registrar policies, Acceptable Use Policy and Wildcard Blocking program are designed to create the best opportunity for couples to obtain the .WED domain name of their choice. These components are also designed to minimize domain name speculation, cyber-squatting and human trafficking. We are particularly concerned with the possibilities of human trafficking and will actively combat this practice. The three policies designed to accomplish these goals are as follows: 

Pricing Strategy: Annual registrations and renewals are priced affordably for couples who on average use a website for their engagement and wedding for a year or less and usually no more than 18 months. Any annual registrations over two years or initial registrations exceeding a two-year term will be priced significantly higher than any wedding couple would be expected to budget for a presence on the internet. We recognize this may create an inconvenience for some commercial enterprises that desire a longer-term domain name registration. The .com, .biz, .org, .co, and .net gTLDs as well as many of the new gTLDs and ccTLDs offer businesses and other commercial entities multiple opportunities to have a presence on the internet so Atgron doesnʹt think this represents a barrier to competition and could act as a deterrent to other forms of domain name misuse, particularly those related to intellectual property violations in the .WED TLD. 

Registrar policies: Bulk registrations and renewals will only be allowed if registrars confirm the bulk registration or bulk renewal is a result of direct interaction between the registrant and couples or families planning a wedding. Any accredited registrars offering .WED TLD domain names for longer than two year terms, will need to obtain electronic acknowledgement from registrants of their understanding of the significant price increase for .WED TLD domain name registrations beyond two years.

Acceptable Use Policy: Material that promotes pornography, human trafficking, mail order bride services and forms of discrimination as well as hatred and violence are strictly prohibited. We will actively monitor registered domains for these violations and use our Wildcard Blocking feature to block common terms with pornographic intent. Please see the response to Question 28 for the detailed Acceptable Use Policy.

Wildcard Blocking: The .WED TLD will offer the ability for verified Trademark Holders to block variants of their trademarked name in perpetuity via a one-time premium wildcard blocking program. Blocked variants will be based upon demonstrable usage by the trademark holder and appropriate interpretation of the trademark intent. Details of this program are provided in the response to question 29. 

Municipalities

Because weddings tend to be local events, we will provide unique spaces to countries, provinces, states, counties, and cities to promote tourism generated by weddings, if they so desire. No geographic domain names will be approved without the express request or approval of an authorized governmental agency. Violations of this policy will be handled using the Complaint Resolution Service (CRS) of Atgronʹs Registry Service Provider, CoCCA Registry Services Limited. For details of the CRS process, please see the response to question 28.

18.2.2 What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

A wedding is a special but fleeting occasion. The .WED gTLD will offer couples the ability to provide targeted communication conveying their special event using a channel designed for that specific purpose. 

Competition

Currently, the .com, .biz, .org, and .net, gTLDs as well as ccTLDs are the most common strings used by wedding couples today. Many of these strings are saturated and couples are unable to obtain the domain name of their choice. The .WED TLD will offer wedding couples additional choices related specifically to their unique event. 

Because Atgron, Inc. and its partners have no affiliation with any wedding industry vendors and conducts no business in the wedding industry, there is decreased risk of anti-competitive behavior. We have no incentive to steer registrants to any particular vendor, inhibit competition, promote products or leverage registrant information for competitive advantage. Our target market, wedding couples, will be our competitive advantage and our entire focus will be providing the best gTLD registry to meet their needs. 

Differentiation and Innovation

Unlike other gTLDʹs, the .WED TLD is designed to offer domain names to couples planning and executing a wedding, a fundamentally short-term need. This niche TLD will offer a supply of domain names that can be recycled forever. Supplying domain names to families for this short-term need is the foundation of the differentiation and innovation of the business model.

18.2.3 What goals does your proposed gTLD have in terms of user experience?


The goal is to provide a consistent, wholesome, exceptional quality online wedding brand with a reputation for reliability and specialization in this area. Registrants must abide by local legal restrictions but will also be prohibited from promoting violence or hatred against individuals or groups, on the basis of religion, ethnic origin, race, sexual orientation, disability, gender, age, or veteran status. While there is no way to eliminate these occurrences, we will provide these terms and conditions to hinder these activities. Violations of this policy will also be handled by the CRS process detailed in the response to question 28.

We will also work with our registrars to provide a .WED TLD central website which not only lists all the participating ICANN accredited registrars but also includes their prices for .WED TLD domain names and any additional services they may offer related to creating wedding products for couples. This site is intended to create ease of use for couples searching for registrars and will not collect any domain name fees. This site will be provided at no charge to .WED TLD registrars but will require registrars to keep the information up-to-date and accurate. Equal access will be provided to all accredited registrars who provide the .WED TLD to the public.

18.2.4 Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.


The registry will comply with all consensus policies adopted by ICANN but the following policies directly support the goals listed above:
- Uniform Rapid Suspension System (URS) Policy.
- Uniform Domain Name Dispute Resolution Policy (UDRP).
- Trademark Clearinghouse Policy - The Trademark Clearinghouse will be used during the Sunrise period as required by ICANN. The .WED TLD will also offer the ability for verified Trademark Holders to block variants of their trademarked name via a premium Wildcard registration program. Details of this program are provided in the response to question 29. 
- Trademark Post-Delegation Dispute Resolution Procedure (PDDRP).
- Privacy Policy that provides registrants with the maximum privacy possible within the requirements of the WHOIS policy and Unites States legal requirements. Please see the Acceptable Use Policy and Privacy Policy provided in the response to question 28. 

18.2.5 Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures. Describe whether and in what ways outreach and communications will help to achieve your projected benefits.


The .WED gTLD will institute a Privacy Policy that provides registrants with the maximum privacy possible within the requirements of the WHOIS policy and Unites States legal requirements. The release of contact information for couples planning a wedding could present the opportunity for unwanted solicitations to domain name registrants and it will be our goal to minimize these possibilities. Please see the .WED TLD Acceptable Use Policy and Privacy Policy provided in response to question 28.

18.3 .WED gTLD Operating Rules 

18.3.1 How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

During the Sunrise period, applications will be accepted via .WED TLD ICANN accredited registrars submitted to the Registry and verified electronically via the Trademark Clearing House. Multiple valid applications for a trademarked .WED TLD domain name will be auctioned using an experienced auction vendor.
 
During the Landrush phase, applications will be accepted via .WED TLD ICANN accredited registrars and submitted to the Registry. Any applications for duplicate .WED TLD domain names will be auctioned using an experienced auction vendor. 

Due to the pricing policy, Atgron expects Sunrise applications to mainly focus on defensive mechanisms to avert possible trademark violations and use of the Wildcard blocking program. Any Landrush applications will most likely be for exploratory purposes to test the value of the .WED TLD brand or short-term promotions for commercial entities.

During General Availability, domains will be sold on a first come first served basis via ICANN accredited registrars.

18.3.2 Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).


We do not anticipate the need for bulk promotions or introductory discounts at this time but do not rule out the possibility of promotions in the future.

18.3.3 Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

With the advent of hundreds of new gTLDʹs and market uncertainty, we do not think it prudent to make contractual commitments regarding the magnitude of price escalation in the first two years of operations but will reassess this option in the third year of operations. At this time, we do not anticipate any price increases in the first three years of operation. We will adhere to all ICANN requirements for written notice of price increases to registrars per the Registry agreement and any updated ICANN policies. Registrars will be offered the opportunity to provide the .WED TLD for terms from one to ten years as required by the registry agreement.

No

Not Available

No

22 Geographic Names

Registration of geographic names at all levels will only be granted if an official request is received by Atgron, Inc. from an authoritative governmental entity. Any non-authorized geographic name domain registrations will be inactivated after a review is conducted to confirm the lack of sponsorship by an appropriate governmental agent. The Complaint Resolution Service (CRS) of Atgronʹs Registry Service Provider, CoCCA Registry Services Limited, will be leveraged to address any abuse of this policy. For details of the CRS process, please see the response to question 28.

23 Registry Services

Atgron, Inc. has contracted CoCCA Registry Services (NZ) Limited (ʺCoCCAʺ) to provide hosted Registry Services for the .WED TLD. The .WED 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 .WED zones on the Internet Software Consortium (ʺISCʺ), Packet Clearing House (ʺPCHʺ) anycast networks - and on CoCCA unicast servers. 

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

The .WED 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, 35 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 35 TLDs, the exact number of users is hard to determine as the pamoja software is freely available for download from the internet. CoCCA 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]
.bow | 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]

23.3 CoCCAʹs Hosted SRS

Atgron has confirmed with CoCCA their production experience and the availability of the Registry Services described briefly in sections 23.4-23.25 below - and in greater detail in the responses to questions 24-43. Atgron 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 .WED 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 .WED 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 .WED 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 Atgron policy. The .WED 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 .WED 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 be 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 in 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 .WED TLD will be 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 .WED TLD 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 websites. 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 .WED TLD on port 43 in accordance with RFC 3912 and the requirements set out in Specification Four (4), 1.1-1.7 and in 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 Memorandum of Understanding, 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, .WED 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 .WED TLD when launched. 

.WED SRS data will be deposited with NCC Group, CoCCA Data Escrow and ICANN. Additional information on Escrow is available in 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 Services 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, and contacts can be easily extracted. 

23.16 Monitoring

CoCCAʹs Registry Services 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. Atgron will bind all registrants in the .WED TLD to the CoCCA CRS process, and Atgronʹs Acceptable Use Policy and Atgronʹs Privacy and RDDS Policy via the .WED Registrant Agreement (ʺRAʺ). CoCCAʹs front-line CRS services are a ʺroleʺ performed by CoCCAʹs 24⁄7⁄365 NOC Support.

23.19 Registrar Support

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

The pamoja SRS application is used to manage critical TLD infrastructure, each release is tested prior to release or deployment by CoCCA developers, as well as 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 Services 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 Atgronʹs .WED policies before being granted EPP or GUI access to CoCCAʹs production SRS.

23.22 Authorization Key Retrieval

CoCCAʹs Registry Services 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 emails 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 these entities continuous registry access free of charge to facilitate two-way data exchanges aimed at preventing and mitigating abuse in the DNS. 

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

24 Technical and Operational Capability

Atgron, Incʹs string, .WED, 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 .WED currently complies with the requirements of Specifications 4, 6 and 10 and will be scaled or modified to meet SLA requirements for 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 Atgron. To ensure this CoCCA will use PCHʹs DNSSEC and anycast infrastructure for offline storage, signing and resolving the .WED 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 policies 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 an 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 a 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, todayʹs ʺ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 ICANNʹs gTLD SLA requirements and complies 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.2 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.2.1 SRS Infrastructure ⁄ Architecture

The following describes the key features of CoCCAʹs current production SRS that will be utilized for the .WED TLD:

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

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

* SRS Escrow at tier three co-location facility (Magnet) in Auckland NZ and Failover at a tier four facility (Equinix) 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.2.2 Specification 6, Section 1.2 Compliance

The .WED 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 is attached.

24.3 EPP Interface

The port 700 EPP interface for .WED 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 .WED will be branded as epp.nic.WED. 

24.4 WHOIS Interface (port 43 and 443)

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

24.5 GUI Interface (port 443)

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

24.6 Hidden Master DNS (s) (port 53)

There are two hidden master servers. CoCCA will transfer the .WED 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 transfer it back to CoCCA using TSIG and IXFER⁄ AXFER. CoCCA will then load 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.7 CoCCA Public Unicast DNS

DNS servers on virtual machines running BIND in the Sydney NOC and NZ SRS will pull and resolve the .WED TLD zones.

24.8 Public anycast DNS

CoCCAʹs distribution master notifies the anycast providers (PCH and ISC) and .WED 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.9 ftp Server

Server to distribute zone files as required under Specification 4, Section 2.

24.10 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.11 Number of Servers
 
There are seven physical server appliances in the Sydney NOC configured such that they host 17 virtual machines. 

24.12 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 extended 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 be load balanced by simply having the nagios monitoring software automatically modify resource records and send traffic to either of the secondary ⁄ failover SRSʹs for near-real time WHOIS. When the primary becomes available or SLA issues (DoS etc) are resolved, RDDS services are automatically switched back to the primary SRS. 

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

VMware images of 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 vm images.

25 EPP Protocol 

Atgronʹs Registry Services provider, 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 meeting the 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 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 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.4. Atgron has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OT&E) 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.4 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.4.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.4.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 .WED 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 .WED 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.4.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 .WED 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.4.4 Contact Proxy Extension

〈extURI〉https:⁄⁄ epp.ote.WED.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 previous contact proxy info. 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 used to give this proxy info a particular reference. Each reference must be unique, so if there is an existing contact proxy info record with this reference value, UPDATE that record, changing the proxy info for any existing contact referencing that proxy.

 If a reference is not specified, one will be created 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 existing Proxy 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 to be used. 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 .WED 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.5 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 a 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.6 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.7 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.8 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.9 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 .WED 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 Atgronʹs management team and applicable ICANN requirements.

26.1 WHOIS Architecture and Infrastructure Overview

CoCCAʹs flexible WHOIS architecture 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 supplement 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, and 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: whose ʺ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: whose ʺh -whois.nic.WED 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 .WED thick registry model, registrars will not operate their own WHOIS servers. 


26.2.3 Name Server Data:
* Proposed Production Query format: whose ʺ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, and email addresses can and will be configured to conform to the mappings specified in EPP RFCʹs 5730-5734.

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

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

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

* If there is no exact match but a super-ordinate domain exists the SRS data for the super- ordinate name is to be displayed. By way of example if an individual searches for abc.domain.WED and abc.domain.WED does not exist then the SRS would display the information on domain.WED 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 Specification Four, Section One. Atgron has instructed CoCCA to make available to evaluators an Operational and Testing and Evaluation (OT&E) 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 ⁄ Bunt ), 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 an issue, pamojaʹs RDDS read-only services can be configured to extract data from a replicated copy of the SRS. 

Individuals or entities with the 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 Atgronʹs growth projections for the .WED TLD. For a 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 have 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 CoCCAʹs 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 SLAs for the .WED TLD. 

If WHOIS caching is required as the .WED 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 minute 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, CoCCA will also provide fee-based Premium RDDS service described in further detail below. CoCCA and Atgron acknowledge that ICANN reserves the right to specify alternative formats and protocols and if such change were to occur; CoCCA will implement specification changes.

CoCCA and Atgron 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 .WED TLD 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: whose ʺ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: whose ʺNS1.EXAMPLE.TLDʺ or whose ʺnameservers (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, Atgron 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 is 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 a 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)

Atgron, 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 .WED 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 Atgron to otherwise make available to the public via WHOIS and the services of a 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 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, Atgron 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 the Registry Operator or any ICANN-accredited registrar. CoCCA will seed the SRS with unique records that enables tracking of reported abuse back to an individual RDDS subscriber. 

* Because this is only offered as a premium and paid service, the request must follow CoCCAʹs application process to confirm the userʹs 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 .WED zone files via the port 43 GUI up to six (6) times in any 24-hour period. 

CoCCA will comply with 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 .WED TLD will be added to CoCCAʹs SRS at their primary data center in Sydney, which currently supports the features noted above.

Atgron will dedicate 1.5 full-time equivalents to coordinate the operation of the .WED TLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .WED TLD.

27 Registration Life Cycle

Atgron will adopt the CoCCA harmonized life cycle currently adopted by a dozen ccTLDs. The .WED life-cycle described below 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 .WED TLD builds on the traditional gTLD life-cycle by adding direct Registrant-Registry interaction.

The proposed .WED life-cycle ensures key elements of the .WED TLD abuse prevention and mitigation framework are adhered to by delaying mapping of the Registrantʹs desired Name Server (NS) delegation information until the registrant has Activated a domain. All .WED registrations are provisional until Activated. Activation requires that the registrant confirm (with CoCCA) the accuracy of the contact information lodged by the registrar and agrees to the .WED Registrant Agreement (RA), AUP and Privacy and 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 .WED RA, AUP and Privacy and 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-Cycle.

27.1 Registration | Initial Registration

Not Registered
SRS EPP domain:check response

〈ʺxml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ standalone=ʺnoʺ〉
〈pep 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

TERMS OF USE: 〈Legal Notice〉

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

$ 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

TERMS OF USE: 〈Legal Notice〉

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

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 .WED TLD policy all registrations are considered provisional by Atgron until the Registrant accepts the .WED 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 an Atgron, Inc. controlled website that displays the domains port 43 WHOIS information. The SRS ignores the registrar-submitted 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, Atgron deems the application to have been withdrawn by the registrant and the Status is changed to ʺPending Purge ʺ Restore Not Possibleʺ (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=ʺ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 Atgron has deemed the application to register to have been withdrawn. 

If more than 10% of a Registrarʹs domains are not activated by the Registrant in a given month, or deleted by the Registrar within the Min Period (14 days) days, CoCCA may review EPP access or add a minimum transaction levy equal to one monthʹs registration for future registrations in order to discourage abuse of the Activation policy as a holding instrument.

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 .WED 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 registrarʹs 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 below 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 .WED 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, Atgron 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 .WED TLD RA, registrants are required to confirm the accuracy of the contact details and accept the .WED 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 in 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 an Atgron parking page. 

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

An expired and suspended name not locked 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 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 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

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

28.1 The Atgron .WED Policy Matrix

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

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

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

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

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

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

28.2 Contractual Framework

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

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

28.3 Minimizing Harm, Pro-active Measures

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

Atgron will adopt the following key provisions (28.3.1-28.3.8) of CoCCAʹs already field - tested policies and technology aimed at preventing and mitigating abuse: 

28.3.1 ʺTrust but Verifyʺ

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

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

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

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

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

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

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

28.3.2 Registrantsʹ rights to a limited license

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

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

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

See attached draft Registrant Agreement for more information. 

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

28.3.3 Fast flux mitigation

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

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

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

28.3.5 High Risk Strings

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

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

28.3.6 Atgron CERT Law Enforcement Collaboration

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

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

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

See attached for the RA in entirety. 

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

28.3.7 Domain Scans

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

From the .WED RA (attached)

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

28.3.8 Notify Services

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

28.3.9 Malware ⁄ Malicious Domain Polling

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

28.4 CoCCA Complaint Resolution Service 

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

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

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

29 Rights Protection Mechanisms

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

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

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

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

29.1 Registration Abuse Prevention Mechanismʹs Pre Launch

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

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

29.1.1 Sunrise & Land-rush

To meet the ICANN requirement of a 30-day Sunrise process for those with verifiable trademark rights or owners of exact matching strings in other TLDs, CoCCA shall implement for Atgron 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 Atgron or an Atgron approved Registrar. The CoCCA SRS will store and make available via the SRS all documents lodged in support of a Sunrise Application.
 
During the Sunrise period, Atgron 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 Landrush 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, Atgron 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, Atgron or the Registrar will provide notice to the prospective registrants where an identical match is identified in the Trademark Clearinghouse. The notice will include warranties that the prospective Registrant must understand and adhere to so 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 .WED 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, Atgron requires that domain names within the .WED TLD should consist of proper characters unique within top-level domain, followed by the characters ʺ.WEDʺ. 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

Atgron has developed an Acceptable Use Policy (AUP) framework that is referenced in the answer to Question 28. This AUP clearly defines what type of behavior is expressly prohibited in conjunction with the use of a .WED domain name. Atgron 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 .WED TLD.
 
29.2 Rights Protection Mechanismʹs Post Launch

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

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

29.2.1 Unqualified Registration Safeguards

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

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

Atgronʹs and the .WED Registry Services providerʹs Network and Domain names must be used only for lawful purposes and must comply at all times with this AUP. The creation, transmission, distribution, storage of, or linking to any material in violation of applicable law or regulation or this AUP is prohibited. This may include, but is not limited to, the following: 

(1) Communication, publication or distribution of material (including through links or framing) that infringes upon the intellectual and⁄or industrial property rights of another person. Intellectual and⁄or industrial property rights include, but are not limited to: copyrights (including future copyright), design rights, patents, patent applications, trade marks, rights of personality, and trade secret information. 
(2) Registration or use of a .WED Domain name in circumstances in which, in the sole discretion of Atgron:
(a) The .WED Domain name is identical or confusingly similar to a personal name, company, business or other legal or trading name as registered with the relevant agency of the United States of America, or a trade or service mark in which a third party complainant has uncontested rights, including without limitation in circumstances in which:
(i) The use deceives or confuses others in relation to goods or services for which a trade mark is registered in the United States of America, or in respect of similar goods or closely related services, against the wishes of the registered proprietor of the trade mark; or
(ii) The use deceives or confuses others in relation to goods or services in respect of which an unregistered trade mark or service mark has become distinctive of the goods or services of a third party complainant, and in which the third party complainant has established a sufficient reputation in the United States of America, against the wishes of the third party complainant; or
(iii) The use trades on or passes-off a .WED Domain name or a website or other content or services accessed through resolution of a .WED Domain as being the same as or endorsed, authorized, associated or affiliated with the established business, name or reputation of another; or 
(iv) The registration or use may tend to mislead or deceive Internet users or consumers in breach of Atgron policy, or the laws of the United States of America; or
(b) The .WED Domain name has been used in bad faith, including without limitation the following:
(i) The User has used the .WED Domain name primarily for the purpose of unlawfully disrupting the business or activities of another person; or
(ii) By using the .WED Domain name, the User has intentionally created a likelihood of confusion with respect to the third party complainant‚ 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 .WED Domain name; or
(iii) For the purpose of selling, renting or otherwise transferring the Domain name to an entity or to a commercial competitor of an entity, for valuable consideration in excess of a User‚ documented out-of-pocket costs directly associated with acquiring the Domain Name; or
(iv) As a blocking registration against a name or mark in which a third party has superior intellectual or industrial property rights.
(3) A .WED Domain name registration which is part of a pattern of registrations where the User has registered domain names which correspond to well known names or trade marks in which the User has no apparent rights, and the .WED Domain name is part of that pattern. 
(4) The .WED Domain name was registered arising out of a relationship between two parties, and it was mutually agreed, as evidenced in writing, that the Registrant would be an entity other than that currently in the register.
(5) Unlawful communication, publication or distribution of registered and unregistered know-how, confidential information and trade secrets. 
(6) Publication of web content which, in the opinion of Atgron:
(a) is capable of disruption of systems in use by other Internet users or service providers (eg viruses or malware);
(b) seeks or apparently seeks authentication or login details used by operators of other Internet sites (eg phishing); or
(c) may mislead or deceive visitors to the site that the site has an affiliation with the operator of another Internet site (eg phishing)ʺ

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

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

29.2.2 Wildcard Registrations

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

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

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

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

29.2.3 Alert Services

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

29.2.4 Clearing House for Intellectual Property (CHIP)

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

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

29.2.5 Thick WHOIS

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

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

29.2.6 Registrar Relationship

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

29.2.7 Uniform Dispute Resolution Policy (UDRP)

The UDRP is a proven rights protection mechanism whereby complainants can object to a domain registration via a UDRP provider. The Registrant in question has the opportunity to respond to the complaint and defend its registration and 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 Atgron must implement and respond to UDRP policy where applicable. Penalties will apply where Registrars are found to be in breach.

29.2.8 Uniform Rapid Suspension (URS)

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

29.2.9 Post-Delegation Dispute Resolution Procedure (PDDRP)

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

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

29.2.11 Rapid Takedown & Suspension

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

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

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

29.2.12 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 the domain (in second level or subordinate domains) within the TLD. Phishing activity most often occurs through a subordinate domain, rather than a directly registered second level domain. For this reason, the registry should query for any wild-card occurrence of a domain that has been flagged as a phishing site or one that contains malware. CoCCA is currently investigating this technology for use in ccTLDs and will deploy it for the .WED gTLD, if it proves effective. 

29.2.13 Malware Mitigation

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

29.2.14 DNSSEC Deployment

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

29.2.15 Security of Domain Resolution 

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

29.2.16 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.17 Law Enforcement and Anti-Abuse Community Collaboration

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

29.2.18 Super-Locks

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

29.3 Resource Plans
Atgron will dedicate 1.5 full time equivalents to coordinate the operation of the .WED gTLD. At the same time, the technical professionals at CoCCA will be supporting the vast majority of the technical aspects of operating the .WED gTLD, including operation of the CRS and URS response on a 24⁄7⁄365 basis.
 
The following CoCCA team members will be used to support the rights protection plan; CoCCA CRS Officers, the CoCCA Ombudsman and CoCCA Expert Panelists.

CoCCA acting as registry services provider maintains a resource model to meet the demands of RPM implementation and on-going operation of the protection mechanisms. 
 
The CoCCA workforce-staffing model is sized to provide the appropriate services for each managed TLD. Given the dynamic nature of technologies and innovation, the CoCCA staffing model is constantly reviewed and adjusted to achieve optimization without sacrifice to customer satisfaction and service level requirements. In cases where growth dictates an increase in staff, CoCCA maintains a proven staffing process for acquiring qualified candidates. Details of staffing resource plans for Atgron can be found in response to questions 46 and 47 of the Financial Projections section of the application. 

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

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

Given the estimated registration volumes of 3,900 Year 1, 4,953 Year 2 and 6,290 Year 3, respectively, in Atgronʹs Template 1: Most Likely Financial Projections attached to Question 46, CoCCA estimates it will require the following personnel to support the RPM implementation and operations for Atgron:

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

30a Security Policy
Atgron 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 the .WED TLD on the Internet. CoCCA, together with partners PCH and ISC will endeavor to ensure the secure operation of Registry Services for the .WED 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 .WED 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 .WED TLD

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

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

The geographically diverse Anycast network proposed for .WED 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 that of 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 Atgron 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 Atgron 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 .WED 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 .WED 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 Atgron has at least two ʺlast resortʺ DNS nodes under direct management. Both PCH and ISC networks provide the .WED TLD 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 it reachs the servers and to augment 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 .WED Privacy and RDDS 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 .WED 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.