ICANN New gTLD Application

18.B USER BENEFITS

Uniregistry will offer .HIPHOP as an intuitively relevant top-level domain serving registrants seeking to provide information about hip hop culture and music.

We will provide affordable, predictable, transparent pricing; freedom to utilize names without micromanagement from the registry administrator; and transparent rules to prevent rights infringement and abuse.

18.B.1 Competition, Differentiation, and Innovation

Uniregistryʹs .HIPHOP gTLD will increase competition by offering a specialized, semantically meaningful alternative to existing gTLDs. New gTLDs, like .HIPHOP, allow businesses, organizations and individuals to identify their Internet presence with an easy to register and memorable name without having to purchase the name on the secondary domain name market in the current limited TLD offerings.

The registry will compete with other new market entrants on price, better top-down administrative management, and marketing.

The launch of a number of new, specialized, meaningful and distinctive strings as TLDs will facilitate bottom-up innovation of the naming system. Indeed, the value of each TLD will increase as more are added, because the ability of the SLD.TLD combination string to convey distinct information regarding the target site or service will increase.

Uniregistry plans to offer fixed, flat rate, predictable, and transparent pricing for all registrants in all parts of the world. Our business models do not contemplate price increases or variable pricing over the consumer price index (cpi) in the first five years of operation. We plan to maintain low, affordable prices as a core tenet of our culture of service to our .HIPHOP registrant population.

Uniregistry does not have any interest in any user group or industry segment signified by the .HIPHOP TLD. Uniregistry believes that registrants are best served by a neutral registry service without conflicts of interest. Interested entities or cartels composed of market participants seeking to run registries for their markets present a real risk of discriminatory operation of the TLD to the exclusion or detriment of competitors.

We do not believe delegation of a generic TLD to a participant in the designated industry, or to a favored group among several in what may be defined as a community, is appropriate, desirable, or serves the basic values of a free, fair and open Internet. Uniregistry will operate as a neutral registration platform, favoring no specific registrant or group of registrants.

18.B.2 User Experience

Our goal is to provide the highest quality experience for registrants and users. The technical infrastructure behind the registry is built and maintained using systems, software, and procedures from the Internet Systems Corporation (ISC). Internet Systems Corporation (ISC) is the premier provider of domain name registration and publication systems.

ISC maintains and extends the Berkeley Internet Name Daemon (BIND), the most widely deployed domain name server software on the Web. ISCʹs software is the reference standard against which all other domain name systems (DNS) are measured. ISC operates the F-root server, one of the 13 root servers, which facilitate the function of the Global Internet. ISC is an Internet-vanguard: they were among the first to feature multiple exchange points. ISC was first to deploy ANYCAST routing technology to allow a single virtual root server (or any DNS server) to be replicated around the world and was also was among the first to deploy Internet Protocol Version 6 (IPv6). ISC has one of the worldʹs largest operational deployments of Domain Name System Security Extensions (DNSSEC).

As a result of its contract with ISC, all aspects of the Uniregistryʹs hardware and software implementation are designed and built to be robust, replicated, and recoverable. Uniregistry hardware uses redundant elements such as power supplies, Redundant Array of Independent Disks (RAID) storage, and Error Correcting Code Memory (ECC). All network connectivity uses redundant interfaces, geographically differentiated pathways, and automatic fallbacks. Our databases are built using an architecture that uses master servers with hot standbys, meaning database files can be backed up or moved without stopping services.

All systems will be monitored 24x7x365 by a worldwide array of hardware and performance monitors backed by people at a central Registry Operations Center (ROC). Uniregistry transactions are time-stamped and logged in journals that may be used for audits or data reconstruction.

The partnership between ISC and Uniregistry will allow our gTLD to offer technical excellence at exceptionally affordable pricing.

18.B.3 Registration Policies in Support of the User Experience Goals

Uniregistry believes that first-come first-served is the most fair and inexpensive way to allocate registrations to the public. We plan egalitarian, flat-rate pricing made possible by the long-term payback horizon of our lead investor. Uniregistry plans to implement rate limited registration queues made equitable through a randomized, round robin acceptance of orders. This will make land-rush allocation of SLD registrations more balanced for all participants.

Uniregistry plans to improve the registration and ownership experience of registrants. These plans include ongoing post-registration redemption rights for outgoing registrants with a no-charge, 180 day suspension of expiring domain names to permit former registrants a long window to recover their accidentally expiring or forgotten SLD names, and to protect their residual reputation from harm or confusion with successive registrants. After names expire and an extended redemption period has passed, Uniregistry will delete names within a randomized one month window to avoid gaming of the deleted name stream by speculative entities with superior technical skills. Random deletion coupled with a registration query rate limit will permit would-be registrants of all levels of technical ability an opportunity to register their preferred SLD. Uniregistry plans to implement a ʺmust deleteʺ policy to work against such registrar warehousing of the expiring name stream and to give registrants of all levels of sophistication an opportunity to register their expiring name of choice.

18.B.4 Protecting the Privacy or Confidential Information of Registrants or Users

Uniregistry will work to ensure that registrant information is protected in the manner required by law in relevant jurisdictions. Uniregistry believes well-managed and accurate WHOIS is critical to the success and prosperity of a new namespace and proposes a WHOIS system of unparalleled reliability and accuracy. It also intends to launch an innovative registrant-centric, enhanced two-way ʺwhoisʺ (WHOIS) lookup service to protect registrants, Intellectual Property (IP) interests, and the public alike. This ʺgive-informationʺ to ʺget-informationʺ WHOIS facility will protect the privacy of registrants and the confidential information of registrants and users. It will allow registrants increased transparency about the use of their WHOIS data while at the same time providing accurate information to users of the WHOIS system.

18.B.5 Outreach and Communications

Uniregistry has a unique relationship with a large network of sites that market domain names in existing TLDs. We will leverage that relationship to increase awareness of the .HIPHOP top-level domain. In addition, we will reach out to registrars by offering a percentage of first dollar gross sales as a marketing fee for registrants.

18C - Operating Rules To Reduce Social Costs

18.C.1 Assignment of Domain Names

New TLDs ought to serve all registrants equally on a first-come, first-served basis, while reserving the opportunity for incumbents to optionally enhance the existing goodwill of their established identities or, alternatively avoid dilution of their Internet identity, without having that choice forced upon them. 

Uniregistry believes introduction of new TLDs should not be an opportunity for registries to engage in what is viewed by some as extortion of payment for brand protection.  Our financial projections do not include, expect, nor rely upon an assumed profit from defensive registrations.  Prior to general registration availability, Uniregistry will conduct a Sunrise period during which names may be reserved or registered on the basis of trade or service marks validated by the Trademark Clearinghouse.  
  
Brand owners who are not interested in using the TLD should not be charged a premium nor risk implicitly threatened consequences of non-registration.  Hence, we will offer the opportunity to block trade or service marks in the .HIPHOP TLD strictly on a cost-recovery basis.  While the Trademark Clearinghouse provides an economy of scale for Sunrise programs across registries, Uniregistry will provide further burden reduction with a ʺonce and for allʺ unified multi-TLD Sunrise registration application process.  A single Sunrise application can be designated to cover all future TLDs which Uniregistry is entrusted to manage, such that delegation of other TLDs to Uniregistry decreases the net cost, time and inconvenience to any parties engaged in intellectual property protection.  

Because the HIPHOP will be of interest to registrants with substantial non-trademark interests, such as publicity and personality rights in their individual or personal names, we propose to solicit the cooperation of relevant organizations to reserve such non-trademark personal names at no cost, to ensure they may only be registered to those registrants in the event they desire to utilize the HIPHOP TLD, while imposing no burden if they do not. We further propose to implement a low cost resolution policy to address unauthorized registration of personal names.

Domain names not allocated during the trademark sunrise process or registry reserved as above and in accordance with ICANN reserved names and GAC advice, will be made available to all registrants equally on a first-come, first-served basis.  At launch, Uniregistry intends to implement randomized and equitable rate-limited registration queues to both handle the load at the registry and also ensure that registrants and their registrars have equal opportunities to register their preferred domain names.  Uniregistryʹs business model also does not assume or rely upon reservation and sale of ʺpremium namesʺ or other forms of domain speculation.

18.C.2 Cost Structure and Increases

Uniregistry will offer flat-rate, affordable pricing. It intends to offer certain co-marketing rebates and incentives to all registrars, some of which may be returned to registrants as introductory or bulk registration discounts at the discretion of the registrar.  

While not a ʺcommunityʺ application, Uniregistry views its prospective domain registrants as a community to be served, and not exploited.  Uniregistry intends to make a contractual commitment to registrants and their registrars not to increase registry prices above cost of inflation for the first five years after launch of the registry.  Our initial pricing model allows registry prices to find a market value that may be substantially below our projections, which are based on conservative assumptions of registration volume, rather than locking in a captive market with a deceptively low initial registration cost.  

Uniregistry does not believe that registry fees should rise when the costs of other technology services have uniformly trended downward, simply because a registry operator believes it can extract higher profit from its base of registrants.  While competition in registrar services by ICANN caused an initial and substantial drop in retail domain registration prices, the fees for registry services have increased over the same span of time.  Those increases have not been justified by increased Internet traffic, and thus zone server operational cost, since the cost the underlying technology has trended down while performance has increased.   We do not believe registry fees should follow a different trend than comparable technological services. Uniregistryʹs management includes individuals who participated in anti-trust litigation which was brought to combat increases in existing TLD registry charges they believed to be unjustified, and we have no intention of following that path. We believe our best opportunity for prosperity is to offer a reliable, differentiated TLD which will attract increasing numbers of registrants.

18.C.3 Mitigating Externalities

18.C.3.1 Pro-Active Abuse Prevention, Monitoring, and Mitigation

Historically, domain name registries have viewed their companies as purely technical service providers and seen socially undesirable Internet behavior, such as abuse, criminality and fraud, as someone elseʹs problem. The Internet increasingly permeates human interactions and processes, whether those interactions are social, commercial, financial, industrial, or governmental.  Uniregistry believes that a registry should possess sophisticated technical tools to identify and redress behavior, wielded by experienced and knowledgeable management committed to rapid response to clearly abusive behavior. While what may be a criminal act in one jurisdiction might be a lawful expression in another, we believe it is possible, and necessary, to define and respond to behaviors which constitute, in their motivations and consequences, attacks on the Internet itself as a reliable medium for the free expression of ideas, information and commerce.  Fraud, cybervandalism, identity theft and other universally recognized forms of cybercrime can adversely impact utilization of the Internet to advance the human condition in ways that are as insidious as the injudicious application of policies designed to combat them.

This Application proposes a suite of abuse prevention, investigation and response tools, including active monitoring of WHOIS accuracy; participation in ISCʹs Security Information Exchange; detection of anomalous network traffic consistent with abuse profiles; agents for service of legal process, warrants and subpoenas in the United States; a single point of contact for abuse reporting and response with 24x7 availability; a directory of abuse response resources for third party responders; zone file access; searchable WHOIS; anti-terrorism measures; and graduated tiers of registrar incentives and disincentives based on policy compliance and responsiveness. As undesirable Internet behavior continues to evolve in sophistication and creative unpredictability Uniregistryʹs commitment to be an active participant in the relevant cooperative law enforcement and industry and anti-abuse communities, and the demonstrated record of Uniregistryʹs contractor Internet Systems Consortium in that regard, is perhaps of greater importance than the rules, policies and services which Uniregistry will provide and enforce.

18.C.3.2  Civil Disputes

Uniregistry will require and enforce registrar compliance with the Uniform Domain-Name Dispute Resolution Policy, Uniform Rapid Suspension (URS), and all requirements of the RAA relevant to civil disputes.  The URS is not currently offered by any dispute resolution provider which has committed to ICANNʹs target estimate of $300 for URS disputes.  Uniregistry believes that cases of clearly unambiguous, facially apparent cybersquatting against established brands can be resolved fairly, promptly and economically, because the type of cases qualifying for the URS are precisely the sort of cases which do not require analysis at length.  Uniregistry will seek to implement a URS equivalent to be administered by recognized experts in the field of domain name disputes in the absence of URS availability at the cost target established by ICANN. In conjunction with Sunrise registrations, Uniregisty will implement Sunrise challenges to address abuse of the Sunrise registration system; a trademark claim notification service for pre-empting a defense of ignorance as an excuse for cybersquatting; designated resolution of suspended or blocked domains to prevent ISP re-direction of non-resolving names; and a registration string watch service to permit policing of domain registrations containing strings of interest to users.   

Because of the particular attractiveness of the .HIPHOP TLD to registrants who use their personal or professional names in the relevant commercial field, and which may not constitute trade or service marks per se, Uniregistry will further implement an individual name dispute procedure which is designed to address a form of cybersquatting that has received uneven treatment under existing dispute policies. 

18.C.3.3  Technical Security and Stability

Uniregistryʹs technical services provider, ISC is well known in the domain name services community as the operator of the F-Root, and its personnel include highly respected and experienced participants in the Internet Engineering Task Force, and numerous ICANN working groups, task forces and committees.  ISC brings decades of experience in operating high reliability and high security systems to the operation of the .HIPHOP TLD.   The application proposes a modular, scalable, and geographically diverse registry platform which can accommodate registration volume and name resolution second to none, independent of whether the actual volume fails to meet or overwhelming exceeds expectations, and can accommodate addition or replacement of capacity without service interruption.  The WHOIS system described in the application is further designed to accommodate selective publication of WHOIS data on a jurisdictional basis, as various standards for the handling of personal data continue to evolve.

18.C.3.5   Financial Stability

Experience gained since the launch of new TLDs and general marketing of certain ccTLDssince 2000 has demonstrated that treatment of a TLD delegation as a privately-owned balance sheet asset or private fiefdom does not inspire user confidence.  Uniregistry believes that delegation of a TLD is an appointment of a private steward of a public trust.   Accordingly, a registry should be prepared to execute a plan of operation which does not rely on rosy scenarios, unrealistic projections and revenue gimmicks.

Uniregistryʹs business plan is based on providing registry services to end users, and not on ʺpremium nameʺ sales, extorting trademark owners, or returning gains to passive outside investors.   Uniregistry is not seeking to obtain any necessary capital based on the prospect of selling a stake in Uniregistry ownership contingent upon approval of this application.  Uniregistry is well-capitalized, fully funded and ready to commence operation rapidly upon approval of this application.  Uniregistryʹs financial reserve is held in gold, and thus immune to currency fluctuations from global economic uncertainty.

TABLE OF CONTENTS

23.1 SUMMARY
23.2 OPERATIONS
23.2.1 Registry Operations Team
23.2.2 Registry Systems
23.3 SERVICES
23.3.1 Object Registrations
23.3.2 Receipt of Data From Registrars
23.3.3 Dissemination of TLD zone files
23.3.4 Dissemination of contact or other information concerning domain name registrations
23.3.5 Internationalized Domain Names
23.3.6 DNS Security Extensions (DNSSEC)
23.3.7 Registry Operations Center (ROC)
23.3.8 Abuse Mitigation and Prevention
23.4 GENERAL RESOURCING PLANS FOR THE REGISTRY
23.4.1 Human Resources

- - - - -

23.1. SUMMARY

Our various registry services fall into these categories:

* Services to Registrars
** Object Registration and Management (Extensible Provisioning Protocol (EPP) , Registrar Web Interface, Registrar Toolkit)
** Notification, information, and documentation
* Services to Registrants
** Internationalized Domain Name (IDN) registration
** DNSSEC
** Publication of zone file data (DNS name servers)
** Anycast management of replicated DNS servers
* Services to the public
** Classic WHOIS
** Tiered access by registered and authenticated users
* Maintenance services for the registry itself
** Generation of zone files
** DNSSEC signing of zone files
** Dissemination of zone files
** Zone file access
* Abuse Mitigation and Prevention
** Server protection strategies and mechanisms
** Abuse monitoring, recording, and analysis.
** Security and Stability Operational Practices
* Registry Operations Center (ROC)
23.2. OPERATIONS

23.2.1. Registry Operations Team

Registry operations are outsourced to and performed by Internet Systems Consortium, Inc (ISC).

Founded in 1994, ISC has been a vanguard in the growth and stability of the Internet. In addition to its better-known role as a technology leader and developer, ISC is one of the worldʹs most important organizations entrusted with management of Internetʹs essential infrastructures. From respected and prolific standards development for DNS, DNSSEC and IPv6; development and maintenance of the widely-used BIND and DHCP open source software; deployment and operation of critical global Internet services such as F-Root and SNS; to leadership in abuse prevention and mitigation strategies and tools, ISC is the worldʹs preeminent expert in the technology and operation of the Domain Name System.

ISC operates the F-root server, one of the 13 root server complexes on the internet. ISC pioneered use of the anycast routing technology that allows DNS servers to be replicated to improve performance, reliability, and resistance to attack. Today the F-root has 59 anycasted instances that are globally distributed and strategically placed at highly-connected nexus locations. F-root instances are also installed in more remote regions around the world such as in Mongolia and Fiji. This diversity was specifically pursued to increase resilience and performance for small and remote developing countries. This anycast architecture has been adopted by other root server operators and also by many gTLDs and ccTLDs, including .com, .net, and .org. Since shortly after its founding in 1994, ISC has maintained 100% up-time for F-root, and today the servers that implement F-root handle approximately 25% of the Internetʹs root traffic.

ISC provides other critical resources and services such as Secondary DNS for more than 50 ccTLD registries and non-profit organizations (including ICANN). ISC has long operated its own hosting facilities and provided hosting to key Internet open source projects such as Linux, Mozilla, FreeBSD, and the Internet Archive.

As new needs arise, ISC continues to develop and offer new services to support an open and robust Internet. One such project is the Resiliency and Security Forum, which operates the Security Information Exchange (SIE). SIE provides summary or distilled feeds of combined global DNS activities in real time to qualified recipients, which enables a pro-active defense against cybercrime. Recently ISC was a participant in a public⁄private partnership with law enforcement agencies around the world to assist with the largest takedown of a botnet in history.

ISC has one of the worldʹs largest operational deployments of DNSSEC.

ISC and its people are widely trusted around the world. Of the 21 people worldwide (known as the Trusted Community Representatives, or TCRs) who are entrusted with the DNSSEC keys to the root zone, two are ISC employees.

Under such pedigree, ISC has developed the next-generation Registry Services Platform presented in this application.

The Internet Systems Consortium is incorporated in the US state of Delaware, with employees in numerous countries around the world.

23.2.2. Registry Systems

Our systems are state-of-the-art and designed to meet the highest standards of TLD operational performance, reliability, scalability, and security. All components of the technical infrastructure for the registry have been built with 8 to 10 times the forecast capacity for our largest scenario of registration volumes. Thus, the capacity of the technical infrastructure is scaled at a level that covers the full range of projected volumes from ʺWorst Caseʺ to ʺBest Caseʺ without large or incremental capital costs for infrastructure and is easily scalable to higher volumes if required.

The registry is built as several major subsystems, each of which, in turn, is implemented as a collection of subsidiary services. This way we can use the most appropriate technologies for each subsystem and service, to obtain flexibility and scalability while retaining security, robust resilience to load and attack, and high availability.

Many of the major components of the registry system have been in use in commercial services on the Internet. The components that were developed specifically for Registry use have been carefully integrated with and tested with those existing components.

Our registry protects registration data and performance levels across all of its information services. Our system engineers have put a major emphasis on design review, high-reliability engineering methodologies, and structured testing to ensure that consistency and referential integrity is maintained even in the event of a catastrophic incident.

Every aspect of every module is designed and built to be be robust, replicated, and recoverable:

* Multiple data centers, with wide geographic diversity, that mutually support one another for backup and failover.
* Hardware uses redundant elements such as power supplies, RAID storage, and Error Correcting (ECC) memory.
* All network connectivity uses redundant interfaces, geographically differentiated pathways, and automatic fall backs.
* User facing systems are all replicated with no single point of failure and automatic failover to a backup system.
* Load balancing techniques are incorporated to prevent overload of any single user-facing component.
* Firewalls are used to prevent most malicious traffic from even reaching registry systems.
* All registrar and other non-public network service interfaces are protected by access lists, encryption, and authentication.
* Public network service interfaces are protected by rate limiters that can be activated when needed.
* Databases are built using an architecture employing master servers with hot standbys.
* The database has been configured so that rigorous quality and consistency checks are automatically enforced throughout the lifetime of the data.
* Database files can be backed up or moved without interrupting online services.
* All systems are monitored 24x7x365 by a worldwide array of hardware and performance monitors backed by the Registry Operations Center (ROC).
* The Registry Operations Center is backed by a worldwide staff that is ready to assist the operations staff or (in case of disaster) to take over its operation, all without interrupting user services.
* Every transaction is time stamped and permanently logged in journals that can be used for audits or data reconstruction.
* Data, systems, and operations are distributed so that no single event could cause an outage longer than a few seconds while transition occurs. Most systems would have no user perceived outages at all.
The use of replication as a fundamental design element means that the system can scale and adapt in response to equipment, software, or network failures.

23.3. SERVICES

23.3.1. Object Registrations

One of the principal objectives of any Internet Domain Registry is to manage the allocation, registration, and status of Internet Objects: Domain Names, Contacts, and Hosts (name servers).

From the point of view of the registry, a Domain Name comes into existence when it has been registered by an accredited Registrar, there is no requirement of zone file appearance for a domain name to be considered as registered. This is clearly stated in RFC 5731 (section 3.2.1). To be eligible to be included in the TLD zone file, at least two name servers must be associated with the registered domain name. In other words, names that are registered but which do not have at least two name servers are not published into the TLD zone file. Whois data is published for a registered name whether or not that name is included in the TLD zone file.

Contact information is managed as specified in RFC 5733. Our base requirement is that contact information be in English (US-ASCII). However, in order to allow local language communities to make full use of our registry we allow contact information in other languages and their characters sets. This provides the opportunity for fully localized contact or domain records, both of which show information in both English (US-ASCII) as well as the localized languages that might be required.

23.3.1.1. Host Registrations

Host registrations are subjected to a series of checks to prevent unauthorized creation of glue records. In the same manner, periodic audits are performed to detect and flag lame server delegations (name servers to which a domain has been delegated but which have not been configured to serve any data for that domain.)

Host registrations are verified for compliance with RFC 953 and RFC 1035 and compliance with the restrictions related to IDN that have been explained elsewhere in this document.

Periodic audits are performed on contact information to flag potentially inaccurate or incomplete information.

Registrars are notified of suspect contact data via the messaging interfaces in the EPP protocol and our Registrar Web Interface.

23.3.1.2. Blocked Name or ʺDesignated Resolver Nameʺ

ʺBlocked Namesʺ are names which a trademark owner does not want to use but wants to prevent others from using. Blocked names are offered during Sunrise, and go through the same registration path as Sunrise names. With a ʺblocked name,ʺ however, the TM owner indicates in the Sunrise application that it desires a blocked name instead of a resolving name. The WHOIS for a blocked name looks like that of a Sunrise name. The registrant of a blocked name cannot change the nameservers.

23.3.2. Receipt of Data From Registrars

Our Back-end Registry Service provides ICANN-accredited registrars with a standards-based interface to perform domain registration operations.

Registrars may use this service in two ways:

* An Extensible Provisioning Protocol (EPP) interface.
* A Registrar Web interface.
23.3.2.1. Extensible Provisioning Protocol Interface

Our platform implements the standard EPP protocol as described by RFC 5730. We also implement Internet Engineering Task Force (IETF) defined mappings for Domain Names (RFC 5731), Internet Hosts (RFC 5732), and Contacts (RFC 5733). Our EPP is carried over the TCP protocol (RFC 5734) and operates in dual stack IPv4⁄IPv6 mode.

Strong security ensures that this interface may be used only by known entities that have been accredited by both ICANN and our Registry. Use of this secure Registry Service is tightly controlled at multiple levels:

* Secure encrypted channels (TLS) using X.509 Certificate validation back to a known certificate issuing authority.
* Dual static IPv4⁄IPv6 DPI Firewalls to filter out irrelevant and suspect incoming traffic.
* Behavior and anomaly traffic monitoring using IPFIX technologies.
* IPv4⁄IPv6 source address verification (IP address whitelists).
* User authentication (user⁄password) at the application level.
In conformance with standard gTLD registry practices, the Registry Service implements the DNS security extensions for the EPP protocol (RFC 5910), allowing registrars to include secure delegation points to DNSSEC signed zones.

Similarly, the system incorporates Domain Grace Period Mapping (RFC 3915), to comply with TLD extended life cycles.

To support Internationalized Domain Names (IDN), we use a custom EPP extension to specify the language tag in which the domain name has been coded, allowing the application of IDN registration policy as mandated by the TLD manager.

Scalability and high performance are achieved through the use of multiple front-end servers, each running the EPP service. Each Front-end EPP instance is capable of querying multiple Back-end servers that, in turn, have access to a master database for read⁄write operations. In addition there are server and database replicas to support read-only operations (checks, info, etc.) and thus reduce the burden of the read-write database facility.

With EPP, registrars can verify the result of each transaction and have confidence that the operations reported as successful have indeed been processed by the registry.

We time stamp and log all EPP transactions for auditing, capacity planning, offline attack analysis, or forensic reconstruction. We retain these logs indefinitely and securely.

23.3.2.2. Registrar Web Interface

The Registrar Web Interface is designed to complement the EPP Interface, to provide Registrars with backup access to the registry in the unlikely event that its EPP clients are not functional. The Registrar Web Interface supplies a set of domain management functions of the EPP interface and also additional functionality not available within the EPP protocol itself. The Registrar Web Interface provides:

* EPP services
** Management of Internet Objects (domain, hosts and contacts)
** Registrar notification messages
* Financial balance checks and reporting
* Operational and statistical reporting (including DNS server activity)
* Problem and abuse reporting and tracking
* Access to registry support services
Access to the Registrar Web Interface is restricted using the same techniques used for the EPP Interface, which include Signed TLS Certificate, IP address white lists, firewalls, and authentication via login.

23.3.3. Dissemination of TLD zone files

23.3.3.1. DNS Service

No matter how good the registration system, Internet users require that domain names resolve quickly and reliably. Our DNS service provides name resolution for all domain names in our registry.

This registry was constructed on top of an already-operational worldwide publication⁄distribution system and network of name servers. These name servers employ IP-Anycast technology for scalable geographic redundancy, strong defense from Denial of Service attacks, high quality of service, and to give excellent response to widely geographically diverse clients.

DNSSEC and IPv6 are already fully integrated into this network and its component servers.

Our DNS publication system uses both scheduled and on-demand updates. When it is time to perform an update, the process starts by generating all needed certified zone files from the authoritative registry database. Candidate files are validated and checked for errors.

Our system signs each zone with DNSSEC before distribution to the global network of publication servers. Those publication servers are the advertised DNS servers for these domains.

Our DNS master servers compute the changes from the prior zone file and send secure incremental updates via our distribution system. Any lost updates are automatically healed by full-fetch refresh transactions initiated by the publication name servers themselves whenever conditions suggest, or even hint, that incremental synchronization has been lost. A full-fetch refresh can also be initiated by the Registry Operations Center.

Every published zone is stored in a version control system. This allows us to compare zone data as it changes, for recovery, capacity planning, security monitoring, and forensic reconstruction.

23.3.3.2. Zone File Access

In accordance with ICANN requirements, all gTLD registries must offer a zone file access service through which one may download copies of the TLD zone file (as snapshotted once a day.) This service is offered only to registered users. The intent is to facilitate the work of companies, researchers, and individuals who are looking for evidence of malicious conduct.

Eligible individuals and entities may apply for Zone File Access. Access credentials will be issued by the Registry. Those credentials permit controlled retrieval of the zone file images.

23.3.4. Dissemination of contact or other information concerning domain name registrations

23.3.4.1. Port 43 Whois:

Port 43 Whois implements the RFC-3912 Whois protocol specification. This is the classic Whois - it provides public exact-match searches for Internet objects held by the registry.

Our Port 43 Whois servers are geographically distributed in several locations. This improves user experience, performance, reliability, and load distribution.

To prevent abusive behavior, our Port 43 Whois servers implement configurable per-IP rate-limiting controls. In addition, queries are logged for abuse detection, statistical analysis, capacity planning, and reporting.

23.3.4.2. Tiered Access Searchable Whois:

Tiered Access Searchable Whois begins where Port 43 Whois leaves off.

Tiered Access Searchable Whois is a RESTful web service: The query is expressed as part of a URI that is sent by the user to the registry via secure HTTP (HTTPS) as part of a GET or HEAD operation. The default format for the response data is XML. Other formats (such as JSON) may be requested in the URI.

In its basic mode a Tiered Access URI contains a simple match criterion on the name, as with Port 43 Whois. In searchable mode the URI contains search criteria such as partial-match and wildcard searches on the name and use of additional registration fields (such as creation date.)

The searchable mode accommodates situations where customers or law enforcement require capabilities not provided by traditional Port 43 Whois.

Both of these modes facilitate access by user-written software tools. The basic mode interface may be made available to the public. The searchable mode is available only to contracted, identified, credentialed users for lawful public benefit purposes and subject to an agreement to use the data only in compliance with applicable privacy laws and regulations. The searchable mode is also available, in accord with registry procedures, to law enforcement.

Whois queries made to the system, whether they come from the Tiered Access Searchable Whois or the Port 43 Whois are logged for analysis, capacity planning, and abuse detection.

23.3.4.3. Whois API

Tiered Access Searchable Whois is a service for registered and authenticated users to perform wildcard searches on object registrations and retrieve them in a user-friendly way.

An Applications Programming Interface (API) also is provided, thereby enabling information systems to integrate with our RESTful whois service.

If the user of the Tiered Access Searchable Whois system is also the current registrant of a particular domain name, an additional feature is available which allows the user to view whois query reporting information based on the data collected from the monitoring service for that domain name.

Among the items made available to the registrant are:

* Number of times the registrantʹs domain name has appeared on port-43 whois results, over time, and by country;
* General and detailed information on who has been searching for them in the RESTful Whois Interface; and
* Registry system statistics associated with their domain names such as number of DNS queries
23.3.5. Internationalized Domain Names

An Internationalized Domain Name (IDN) is a name that contains at least one non-ASCII character, as permitted according to ICANN and its IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄idn-guidelines-02sep11-en.htm), and IETF standards such as RFC 3490, RFC 3491, and RFC 3492.

23.3.5.1. IDN Registrations

The top level domain name for which we are applying is an ASCII string. We will allow registration of second level IDN names within the TLD.

Our registry policy is that when a name is registered it must be bound to a specific language tag. We have defined an EPP extension (which we have prepared as an IETF draft and will submit for approval and subsequent standardization) to convey that tag information. Our name registration procedure validates that the characters in the proposed name are consistent with the language tag. (If no tag is given the registration is treated as if the English language tag had been specified.) Our registry accepts registrations in ASCII (default), and in Cyrillic, French, Italian, German, Portuguese, and Spanish character sets.

As described in our response to Question 28, Uniregistry participates in the ISC Security Information Exchange and other mechanisms for real-time monitoring and takedown of domain names involved in malicious activity. We believe that pro-actively addressing instances of abuse is preferable to unintended consequences which may arise from constraining user options in registration of IDN domain names. Uniregistry will implement any ICANN Consensus Policy which may IDN registration policies, and it will proactively monitor abuses of IDN registrations to determine whether additional policies or protections are necessary.

23.3.5.2. IDN Whois

Our whois implementation allows UTF-8 input by default on the query command, but defaults to ASCII responses in order to provide backwards compatibility for ASCII-only clients. Domain name objects that include characters other than ASCII are shown in the A-LABEL form.

The reason for this behavior, is that port-43 Whois (RFC 3912) does not have a mechanism to signal the use of character encodings. The use of ASCII-only responses guarantees backwards client compatibility. If the response contains characters other than US-ASCII, a disclaimer note is shown referencing a URL where the complete UTF-8 encoded information is available.

The RESTful interface (in XML format by default) are pretty-formatted if rendered using a web-browser. The content is UTF-8 encoded to allow for extended character sets other than US-ASCII. The format of that XML file is detailed in our answer to question 26 (Whois Service), and will be reviewed and kept up-to-date with IETF proposed standards and best current practices.

23.3.6. DNS Security Extensions (DNSSEC)

Our registry backend operator, Internet Systems Consortium (ISC) has significant experience with DNSSEC. ISC participated in the development of the DNSSEC protocol itself within IETF, and is author of one of the earliest and most popular current free open source DNSSEC implementations available (BIND). ISC operates and manages one of the largest portfolios of DNSSEC signed zones and DNSSEC capable servers.

Registrars collect Delegation Signer (DS) information from Registrants and submit it to the Registry using the EPP service covered under RFC 5910 (DS Data Interface) (DNSSEC Mapping for EPP) or via the Registrar Web Interface.

The TLD zone with all of its resource records are signed using the best current practices for DNSSEC operations.

Hardware Security Modules (HSMs) are used to securely store both the Key Signing Keys (KSKs) and (Zone Signing Keys) ZSKs.

Except for the HSMs which will be provisioned after approval of this TLD, our DNSSEC system is fully operational and in daily use by several ccTLDs and commercial second-level DNS zones.

DNSSEC key management, protection, and signing formalities are in accord with developing norms such as those being used on the root zone itself. (See answer to question 43 for additional information)

23.3.7. Registry Operations Center (ROC)

We have centralized registry management, control, reporting, measurement, and repair functions into a facility we call the Registry Operations Center (or ROC).

There is a secure physical facility that serves as the primary home of the ROC.

Backup ROC facilities may be established on a temporary basis should the need arise.

The ROC is the primary point of contact for all registry issues. The ROC can receive input via several means - PSTN telephone, VoIP telephone, web input, e-mail, and text messages, etc. Special access methods are available to registrars and law enforcement.

The ROC assures that all incoming reports are logged, assigned identifiers, triaged, assigned to staff for resolution, and tracked. A strict reporting structure assures that all issues are handled and, if necessary, escalated and assigned additional resources.

The ROC is also a collection point for the receipt and analysis of monitoring and logging data.

The ROC is supported by geographically distributed staff members who are able to provide assistance if needed. Should there be a failure that takes the ROC offline, those remote staff members will have the tools and security credentials to take over operations until the ROC comes back online.

ISC has successfully used these methods for several years to support F-Root and other critical Internet services.

23.3.8. Abuse Mitigation and Prevention

We anticipate that our Registry (like all registries) will be the target of various kinds of abuse.

* We anticipate that our registration, whois, and name servers will be the target of frequent attacks ranging from heavy-load Distributed Denial of Service (DDoS) attacks to sophisticated penetration attempts.
* Registered names may be mis-used in ways that violate the rights of others.
To deal with direct attacks, we do this:

* Armor our networks and systems with firewalls and filters.
* Pre-deploy significant overcapacity to absorb excess load.
* Use system architectures that allow us to shed an individual device that is under attack.
* Use reasonably secure hardware and software which we will keep up-to-date as vulnerabilities are discovered.
* Monitor for attacks and penetrations so that we can initiate countermeasures.
* Have replicated data (and off-site backups), audit trails, and journals to allow recovery from data damage and to assist law enforcement.
In addition we use an Adaptive Intelligent Mitigation (AIM) strategy in which we use a real-time global system to evaluate actual DNS and Whois activity for signs of errors, trouble, abuse, or attack.

To reduce the abuse of names, our Registry Operations Center maintains active contact points for the reporting of abusive behavior. This is backed by procedures and systems to research the abuse claim, to track progress of the handling of that claim, and to take remedial actions.

Our Registry Operations Center also serves as the primary point of contact for law enforcement interactions with the registry.

To redress name-registration abuse, we:

* Implement ICANNʹs Uniform Dispute Resolution Policy (ʺUDRPʺ).
* Implement a sunrise protection and registration program that uses ICANNʹs Trademark Clearinghouse (ʺTMCHʺ).
* Implement ICANNʹs Uniform Rapid Suspension Policy (ʺURSʺ).
23.3.8.1. System Security and Stability

Our systems have been engineered using standards and best current practices in information system security.

Our systems are protected by multiple security mechanisms ranging from firewalls to multiple levels of authentication, IP address white-lists, real-time monitoring, and audit logs of transaction and system events.

We maintain several levels of non-incremental data backup. We perform realtime data replication among our master and hot stand-by nodes. The replication is designed to safeguard against hardware or software failures. To handle human errors -- for instance, erroneous deleting of records -- a comprehensive backup policy is in place.

We participate in trusted security committees and forums so that we can quickly learn of new threats and solutions.

However, new threats arise every day. No system can be totally secured against every threat. Therefore we have procedures, resources, and backups ready to detect problems at an early stage so we can prevent further harm and restore our systems back to full operational status.

23.3.8.2. Monitoring of Whois and DNS Query Streams

The registry offers a service through which network operators, law enforcement, security companies, and research organizations are able to monitor actual DNS and Whois query⁄response activity.

This service is available only under strict access controls and only to credentialed, identified users operating for the public interest under contractual constraints or to law enforcement personnel.

This service passively monitors queries sent to both the Whois and the DNS service. The monitored transactions are classified into set of channels. Subscribers to a channel can view that channelʹs DNS and Whois transaction activity.

This is far more than a simple packet monitoring service because the transactions are preserved in a searchable database for historical analysis.

In addition, this information is used to feed our analysis systems. Among other things the analysis tries to recognize malicious domain name activity. Suspicious behavior is logged and reported to the Registry Operations Center and, if warranted, to the appropriate registrar.

Overall, this system gives us a unique real-time view of our performance.

23.3.8.3. Front Desk for Abuse Reporting and Mitigation

Through our Registry Operations Center (ROC), anyone can report suspicious activity. Requests are assigned a number (ticket number) and entered into a tracking system, so that the request can be tracked as it is being handled by our team.

Requests resulting in a determination of misuse of a domain name generate a notification for the registrar so they can deal with the registrant to resolve the problem.

In case there is no response from the registrar within a reasonable period of time, a take-down policy will come into effect, where the domain name is disabled (not deleted) until matters can be settled.

23.4. GENERAL RESOURCING PLANS FOR THE REGISTRY

The management of UniRegistry and ISC is committed to providing world-class registry services, including all necessary assurances for performance and availability of those services to the community at large.

UniRegistry has secured ISCʹs support for this endeavour due to ISCʹs extensive experience operating critical infrastructure such as F-Root and ISC-SNS. These are globally DNS services which have reliably served millions of users without interruption since they were deployed.

Operations staff with this level of experience will be in charge of all aspects of UniRegistryʹs registry operations, including DNS, EPP, and WHOIS services. As additional guarantees, ISC has 50+ employees with dedicated operations, support and software engineering resources that will be available to contribute to both the initial implementation and to the ongoing operation, monitoring, and maintenance of the registry system. ISCʹs engineering and operations staffs specialize in the technologies that are required to build and operate a registry and its associated systems.

Additionally, ISC has a world-renowned cyber-security engineering team that will create and maintain a proactive approach to security. ISC is actively involved in major Internet industry security organizations like SSAC and various trusted groups. This team will assist and support the appointed UniRegistryʹs Chief Information Security Officer (CISO) and the Computer Incident Response Team (CIRT) when needed.

All resources required for the fulfilment of the obligations derived from the operation of this TLD will be fully available when registries operations begin. These resources have been enumerated through all the responses of this application and have been accounted for in the corresponding business, operations and⁄or disaster recovery plans

UniRegistry has secured geographically diverse locations to base its registry operations, complemented with a third location where operations are to be resumed in the event of a disaster. Diverse disk & tape based backup systems insure a copy of the data survives catastrophic events and remain available at surviving facilities. Those provisions will remain in place over the lifetime of the TLDʹs assignment.

Performance of service and compliance with SLAs is insured due to the over-provisioning that is built in by-design. Ongoing investment in the platform, vendor support and parts to replace failed components are further evidence of the effort that goes into supporting all operational and business functions. Vendor support in particular is an important factor: All critical components of the service platform are covered by 7x24 support contracts with response within 4 or 8 hours. This level of support is supplemented by on-hand spares, allowing the on-site staff to recover from most hardware failures on short notice.

A custom monitoring platform complemented with third party monitoring services and systematic service health checks reinforce the ability to maintain responses within the terms of the SLAs.

The highly critical DNS service is provided with a combination of the ISC-SNS service -- a worldwide, anycast-based DNS secondary service -- and dedicated unicast-based DNS servers.

A comprehensive Disaster Recovery Plan that is tested and reviewed frequently, supported through the UniRegistryʹs Security Policy, guarantees the ability to restore services to maintain aggressive availability targets, insuring services are available to the public at all times.

Failover Testing and other aspects of the disaster recovery planning are managed by a designated person dedicated to that task, our Disaster Recovery Specialist or DRS. The DRS has at his or her disposal resources from the whole organization -- including management resources -- to ensure that the testing plans are executed and its results and lessons are incorporated into the operation toward the future.

The DRS is responsible for obtaining and properly storing machine logs as well as the service monitoring reports that accompany each test depicted below. This information is preserved and considered an integral part of the Test Report, that remains available for reassessing findings or post-mortem analysis.

The Registry Operations Center (ROC) that is supported by a 24x7 call center and custom automation will receive, aggregate and respond to normal and abnormal issues arising from the operation of the registry services. This organization serves as the focal point for response coordination, threat mitigation and effective policy controls implementation.
Costs and procurement of the resources described here are detailed in response to Question 47.

23.4.1. Human Resources

Management Staff

Management provides guidance and support for the deployment and operation of the registry.

Key members of the Registry Operations Group can be viewed in EXHIBIT ʺ23-Key-Resource-Profiles.pdfʺ

TABLE OF CONTENTS

24.1 SHARED REGISTRY SYSTEM
24.1.1 EPP Software
24.1.2 Platform
24.1.3 EPP System Performance
24.1.4 Registrar Web Interface
24.2 RESOURCING PLANS
24.2.1 Human Resources
24.3 ABOUT THIS RESPONSE

- - - - -

24.1. SHARED REGISTRY SYSTEM

Our Shared Registry System (SRS) is a set of registrar-facing servers, each offering an Extensible Provisioning Protocol (EPP) interface and a Registrar Web Interface. These servers interact with a high-performance redundant back-end system that applies registry policy, and that in turn uses a distributed database master⁄slave cluster.

Our high-performance database system, built on PostgreSQL, uses live streaming replication to update multiple servers simultaneously. Any of these replicas can be promoted to full read⁄write operation if necessary, replacing the master server in case of a failure affecting that master.

Non-master servers share the load of database read-only operations, giving the overall database cluster a significant speed advantage over traditional single-server systems; however, write operations are exclusively and carefully routed to the master server to ensure consistency. Changes to the master are replicated to the other servers after being committed at the master.

Each system component has been engineered to be fully redundant. The hardware used to host them has been designed to allow for single component failures, including power supplies, hard drives, and network interface cards.

In addition to that fully redundant hardware, the software that implements each service has been engineered so that it can operate as multiple instances of that service running on multiple servers. This ability to replicate components (both hardware and software) is critical to the scalability of any high volume, critical service. By having replicated services, the overall system may be geographically distributed among several data centers, which gives multiple-site redundancy to the registry and its services.

The servers in our system all use the Network Time Protocol (NTP) to synchronize their internal clocks, enabling the proper recording of audit traces so that event correlation can be performed at any instant. We operate our own Stratum 1 clock which (along with access to several other Stratum 1 clocks operated by other organizations) gives all of our servers a highly consistent, reliable, and accurate time baseline.

The internal communication between a server and the back-end system is performed with authenticated Representation State Transfer (RESTful) operations layered on HTTPS transport.

Our systems support both IPv4 and IPv6. Our registration systems and name server systems are fully DNSSEC compliant.

For information on Whois and DNS service implementation and performance, please refer to our answer to questions 26 and 35.

24.1.1. EPP Software

Internet Systems Consortiumʹs Shared Registry System (ISC-SRS) is a software package created from the ground up. Its design is based on the set of requirements specified in the ICANN gTLD Applicantʹs Guidebook and on our previous experience with registry software. This is a second generation implementation; its predecessor (OpenReg) had been an earlier initiative within ISC to provide an Open Source registry solution.

OpenReg was used by a few organizations, but mostly became a reference implementation for various software implementers who used it as the platform on which to build their solutions.

The experience gained from OpenReg, and the incorporation into ISCʹs staff of engineers and operations staff with background in registry operations, has led to the creation of a new and innovative system that makes use of modern software technologies to achieve simplicity, scalability, and resiliency with high performance and high integrity.

24.1.1.1. Software Development Process

ISC makes use of the Agile Software Development methodology, advocating frequent releases in short development cycles, with the intention of increasing productivity and introducing checkpoints where new requirements can be adopted.

Our methodology focuses on having extensive code reviews (by at least one other person), unit testing of all code, measurability by code-coverage analysis, and prioritizing based on functionality.

24.1.1.1.1. Coding Guidelines

For ISC-SRS, we follow the guidelines and recommendations of the BIND 9 Coding guidelines as published in http:⁄⁄bind10.isc.org⁄wiki⁄BIND9CodingGuidelines

24.1.1.1.1.1. Code Review

As is standard for all ISC software development, code must be reviewed by peers before it can be considered ready for production testing. This ensures that coding guidelines have been followed, the code is consistent and factored appropriately.

24.1.1.1.1.2. Code Versioning

Source code is stored using the GIT version control system, which is widely used by many organizations that do software development. Among them are: Linux Kernel, Perl, Eclipse, Gnome, KDE, PostgreSQL, etc.

The main features of this system are:

* Distributed development: provides a full copy of the entire repository for developers;
* Strong support for non-linear development: rapid support for branching and merging;
* Efficient handling of large projects;
* Cryptographic authentication of history; and
* Easy integration with existing unix command line tools.
24.1.1.1.2. Software Testing

24.1.1.1.2.1. Unit Tests

Unit Testing is where software development starts. Once there is a clear definition of the functionality that we want to achieve, we proceed to write code that is capable of executing in small or factored pieces.

When the tests have been written, we run them, and verify that all of them fail.

Once the testing framework for a specific project has been put into place, we write the actual implementation, making sure that there is complete coverage of what the tests will be looking for.

When the code has been written, the tests can verify each specific code function, always aiming at a 100% source code coverage.

Having a full set of unit tests written from the beginning enables us to do regression testing, a vital step to make sure that new code additions do not break existing functionality.

24.1.1.1.2.2. Protocol Conformance Tests

In addition to Unit Testing, we run a different set of tests, which allow us to verify that the code conforms with protocol specifications.

To achieve this, we have developed a set of testing tools to check for specific use cases, as defined in Request For Comments (RFC) documents.

As with Unit Tests, it enables regression testing and backwards compatibility with changes going forward.

24.1.2. Platform

The ISC-SRS system is a high performance, scalable platform built for simultaneous support of multiple TLDs. ISC-SRS has the ability to scale with its customer base by adding resources (processors, storage, memory, network capacity) incrementally as needed.

The initial platform for Uniregistry consists of two live sites located at:

* Palo Alto, CA, US (Master); and
* Chicago, IL, US (warm standby).
A third site (another warm standby) is planned to be deployed as soon as the risk assessment, to be performed during mid 2012, is complete.

Each site is fully capable of handling the entire largest-case expected load of SRS operations, and it is designed to be fully redundant from its component base to its network connectivity.

24.1.2.1. Network

For Internet connectivity the ISPs that provide connectivity to our sites meet the following set of requirements:

* IPv4 and IPv6 native connectivity
* Ability to deliver multiple links through different network paths
* Ability to use an IGP (Internal Gateway Protocol), to automatically re-route traffic
* Presence at chosen data centers
* Good peering diversity
* Not provide Internet transit services to another of our registry sites
Complementing the ISP-provided Internet access two private links are provisioned between registry sites, providing a redundant path with consistent low latency for the purpose of guaranteeing database replication and front-end to back-end communication.

See EXHIBIT: ʺ24-Diagram-Network-Sites.pngʺ for a visual description of the connectivity for the sites.

On each site, connections are terminated in two routers having:

* One Internet Transit Link for Management
* One Internet Transit Link for Services
* One Inter-Site link
* One connection towards the other router
* One connection towards each firewall.
The routers provide the ability to adapt the network to link failures, providing the best available path for inter-site traffic and the rest of the world (Internet).

24.1.2.2. Site Configuration

The configuration for each registry site is as follow:

* Two (2) Routers
* Two (2) Network Firewalls
* Two (2) Network Switches
* Two (2) Local Load Balancers
* One (1) Global Load Balancer
* Two (2) High Performance Database Servers
* Two (2) EPP Servers
* Two (2) Whois Servers
* Two (2) Back-end Servers
* Two (2) Management Servers
* One (1) DNS Server
* Two (2) Hardware Security Modules (HSMs)
DNS Services are provided using ISC-SNS platform, which is an Anycast cloud-based service that disseminates and serves DNS information using a globally distributed system.

There is also an additional DNS server per site, in Unicast mode, for additional redundancy and diversity.

24.1.3. EPP System Performance

Our platform is not yet in use for this TLD, so we cannot measure performance with live traffic. We have done performance testing using a laboratory system to determine the load limits of our system and platform.

The laboratory testing platform on which these measurements were made consisted of only one server with low I⁄O performance (only one hard drive) that was executing three competing system components: EPP front-end, SRS back-end, and the database system.

Our laboratory performance measurements understate the performance that will be delivered in full production. As compared to the lab systems, the production EPP servers have higher capacity (more CPU cores, more RAM, faster memory bus). Further, the production servers are dedicated systems that do not perform any other functions that compete for resources.

The hardware profile of the servers is expected to change over the lifetime of the project as industry trends change. At the time of this writing, production servers are based on x86 architecture and fitted with enough RAM and storage capacity to run the expected workloads with a considerable excess capacity.

24.1.3.1. Setup

To measure performance, the platform was provisioned in a lab under the following conditions:

* Both the client and the server were located in the same room
* A 1-GigE switch was used to provide network connectivity
* No firewall or packet filtering was used for the test
* Each server had two network cables attached to the switch:
** (1) for Management
** (1) for Client-Server communication
24.1.3.2. Server Specifications

The hardware chosen for the laboratory testing platform differs from the production architecture. For actual deployment we use a multi-level system to provide load balancing in conjunction with high performance dedicated database systems to minimize the impact of Input⁄Output bottlenecks. Our test system did not have any of that extra capacity or high-performance backend.

Our test platform is thus less powerful than that which we will actually use. We anticipate that in full production, our platforms will exhibit much higher performance capacity.

Yet even on this scaled-down test platform we easily meet the requirements of Specification 10. The test configuration can be seen at EXHIBIT: ʺ24-Table-Server-Specifications.pdfʺ

24.1.3.3. Procedure

To test the platform, the performance software (perf-epp) simulated a registrar performing a high volume of operations on the server. Performance metrics were collected to measure the number of transactions per second (TPS) as well as the round trip time (RTT) of each individual operation.

The ʹperf-eppʹ software simulated:

* 1 registrar sending a stream of operations;
* 2,4,8,16,32,64 and 128 parallel connections performing operations.
Once the client has been initialized with the command line options, it proceeds to:

* Start Phase 1, which:
** Generates a 1 client connection to the EPP server
** Generates a random list of 500 unique domain names
** Generates 500 EPP ʺcreateʺ,ʺinfoʺ and ʺdeleteʺ commands
** Send all the ʺcreateʺ, ʺinfoʺ and ʺdeleteʺ commands and store performance metrics in a file
** Continue to Phase 2
* Phases 2-8 perform the same steps as above, but using 2,4,8,16,32,64 and 128 parallel connections to the EPP server.
* Once all the processes have completed, a post-processing routine analyzes the files to produce the statistical results of the operation.
* For the purpose of measuring the EPP session commands, we decided to time how long it would take to perform an EPP ʺloginʺ command on the server.
The perf-epp collected the ʺloginʺ RTT as it progressed through the test.

24.1.3.4. Results

24.1.3.4.1. Session Command

All the session initiation commands were performed under the SLA as specified in the Specification 10 document in the Applicantʹs Guidebook.

See EXHIBIT: ʺ24-Chart-EPP-Graph-login.pngʺ for a visual interpretation of the data generated by the test.

The Y-axis represents the Round-trip-Time (RTT) time in seconds, while X-axis the time in seconds elapsed during the test. The blue ʹplottedʹ line, shows the round-trip times as observed by the tool. The red line, shows the SLA is the Service Level Agreement as shown in Specification 10.

24.1.3.4.2. Query Commands

To test the EPP query operations, the perf-epp system uses the ʺinfoʺ command.

See EXHIBIT: ʺ24-Chart-EPP-rtt-graph-query.pngʺ for the round trip times observed during the test. The test shows consistent response times under the SLA specification in the Applicantʹs Guidebook.

See EXHIBIT: ʺ24-Chart-EPP-qps-graph-query.pngʺ for the simultaneous number of queries that the test system was able to perform with 1 to 128 simultaneous clients.

24.1.3.4.3. Object Transformations

Object creation and deletions are part of the EPP transform commands. EXHIBIT: ʺ24-Chart-EPP-rtt-graph-create.pngʺ and EXHIBIT: ʺ24-Chart-EPP-rtt-graph-delete.pngʺ graphically compare the results of the performance test against the SLA in specification 10 of the Applicantʹs Guidebook.

EXHIBIT: ʺ24-Chart-EPP-qps-graph-create.pngʺ and EXHIBIT: ʺ24-Chart-EPP-qps-graph-delete.pngʺ show the number of transactions per second (TPS) that the system was able to achieve during simultaneous client connections. To stress the system, 1,2,4,8,16,32,64 and 128 simultaneous were used.

The results of these tests clearly show that our system exceeds the SLA specification for transform operations as defined in specification 10.

24.1.3.4.4. Server Load

During the time the test was running, we collected system performance data using the linux command vmstat. Among other variables, this command reports on CPU usage (both user and system), which we used to observed how the system behaved under heavy load.

After reviewing the performance data, the server maintained an average 75% load during EPP ʺcreateʺ and ʺinfoʺ queries, but later the CPU usage went high when performing massive EPP ʺdeleteʺ commands. This is easily remedied by separating functions not competing on CPU resources on the front-end.

See EXHIBIT: ʺ24-Chart-EPP-Vmstat-graph.pngʺ.

24.1.4. Registrar Web Interface

The registrar web interface complements the functionality provided by the underlying EPP protocol, with rich features to instill confidence in the registrar, aimed at providing:

* Management of Internet Objects (hosts, domain and contacts)
* Administrative information such as:
** Balance checks
** Financial reporting
* Operational and statistical reporting:
** Registry services status
** DNS platform stability and performance
* Registrar messages and event notifications
* Registry support services
As with the the EPP Interface, the system uses a multi layer authentication system that includes:

* TLS Certificate to identify the client
* User⁄password combination to authenticate access the system
* Devices accessing for the first time into the system must be approved by an email challenge sent to the registrar operational contact
* Any changes to Internet Objects within the registry will also require an email challenge sent to the operational contact
Since this web interface uses a communication channel specifically designed for registrars, we can be innovative with regard to the services offered through and we can adapt to new challenges and technologies as they come along.

This service is intended to be used as a backup or in unusual circumstances by the registrars; we do not envision high load demands over it.

24.2. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in response to Question 47.

24.2.1. Human Resources

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

See EXHIBIT: ʺ24-Chart-Resourcing.pngʺ for human resource assignments.

24.3. ABOUT THIS RESPONSE

We believe this answer is complete and must be awarded the full score:

* We includes a complete description of the SRS solution proposed by ISC, including a high-level description of the system, a representative network diagram, a table with the initial number of servers in the solution, a description of the interconnections with other components, a discussion about the synchronization scheme -- both time and database synchronization are explained early in the response -- including the frequency of synchronization (instantaneous and continuous) and the synchronization scheme (live streaming replication).
* This solution provides high performance, high integrity, and high availability - it provides full service through foreseeable failures and includes sufficient resilience and backup to assure business continuity.
* The system architecture is readily expansible: it can obtain increased performance by adding new servers.
* This solution meets, and exceeds, the performance requirements of Specification 10.
* We fully support EPP, DNSSEC, IPv4, and IPv6.

TABLE OF CONTENTS

25.1 EPP SERVICE
25.1.1 Standards Compliance
25.1.2 EPP Service Features
25.1.3 Service Architecture
25.2 EPP EXTENSIONS
25.2.1 Internationalized Domain Names
25.2.2 Launch Phase
25.3 RESOURCING PLANS
25.3.1 Human Resources
25.3.2 Technical Platform
25.3.3 Facilities
25.4 ABOUT THIS RESPONSE

- - - - -

25.1. EPP SERVICE

EPP service is the primary interface between registrars and registries. Our EPP service supports a high transaction volume.

Our other registrar-facing service interface is a web-based service that has some additional capabilities not present in EPP, but with lower transactional volume. This web-based service is described in our answer to question 23.

Our EPP service is extensible, robust, secure, accountable, scalable, and conforms to all relevant ICANN requirements, internet standards and published best practices.

Our EPP service is designed with simplicity and intelligence at the application level to facilitate the most demanding operational models.

We believe that for a high-volume critical service to succeed, it must be modular. Therefore we have designed and built our EPP service to use multiple geographically distributed servers. These servers are front-ended with security firewalls and high performance load balancers. These load balancers ensure that client requests are sent to the least busy (hence best) EPP server.

The load balancers also monitor individual EPP server performance metrics and availability. Thus, in the case of failure or maintenance, the load balancers will automatically stop routing new work to non-responsive EPP server(s) and spread that work among the best of the remaining servers. This substantially improves the scalability of the registry by making it a relatively easy and non-critical task to add or remove EPP servers without interrupting ongoing operations.

25.1.1. Standards Compliance

Our EPP server implements the following RFCs:

* RFC 5730 - Extensible Provisioning Protocol (EPP)
This RFC describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.
* RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
* RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
* RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as ʺcontactsʺ) stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.
* RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP;
This RFC describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server.
* RFC 5910 - Domain Name System (DNS) Security Extensions Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.
* RFC 3915 - Domain Registry Grace Period Mapping
This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.
* RFC 5646 - Tags for Identifying Languages
This RFC describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.
For IDN support, our implementation uses the following RFCs as guidelines:

* RFC 3454 - Preparation of Internationalized Strings (ʺstringprepʺ);
This RFC describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
* RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
This RFC is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set.
* RFC 5891 - Internationalized Domain Names in Applications (IDNA): Protocol
This RFC is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text.
In addition to the above-mentioned published RFCs, we have implemented a custom extension to associate the domain name to a language tag, as required by ICANNʹs Registry Implementation Committee. The specification of that extension has been prepared as an experimental Internet draft, suitable for eventual IETF consideration for the standards track.

25.1.2. EPP Service Features

Our EPP implementation includes the following features:

* Both IPv6 and IPv4 transport and record support.
* Automatic load balancing among server instances.
* Geographic distribution of servers with diversity of communications paths to mitigate the extent of local or regional failures.
* Transaction journaling and statistics for both performance and transactions.
* Authentication: our EPP implementation uses a multi-factor system to authenticate registrars; the process is as follows:
** Source IP address is verified and checked against a whitelist at connection time;
** X.509 Certificate validation back to a known certificate issuing authority at TLSv1.2 session initiation; and
** User⁄Password authentication at the EPP level.
* All data transmitted over the network is encrypted using TLS v1.2.
* Well-formedness check: If at any given time, a command is sent to the server in a format other than proper well-formed XML, the server will drop the connection and de-authenticate the client. This protects against defective clients and adds a measure of protection against exploration by rogue users.
* XML Validation: every EPP command is validated against the associated XML Schema, as specified in the RFC or custom extension. When a client sends an XML command that does not pass the validation check, the EPP server sends the registrar a ʺSyntaxʺ error response signaling the inappropriate message format.
* Time Outs: Every session automatically times out after 15 seconds of client inactivity. Issuing an EPP ʺhelloʺ or ʺgreetingʺ command resets the time out counter, allowing the registrar to use it as a keep-alive method. Once the registrar has been authenticated, it is allowed to perform commands to manage the session, query and transform objects, as permitted by registry policy. When issuing a ʺlogoutʺ command, the server acknowledges it and terminates the session.
25.1.3. Service Architecture

25.1.3.1. Authentication

Service authentication is achieved using a multi level system to authenticate access to the EPP interface, as shown in the EXHIBIT ʺ25-Figure-EPP-Authentication.pngʺ.

By using three successive access control methods, we significantly improve the overall system security. Registrars wishing to use the EPP system must provide in advance the list of IPv4 and IPv6 addresses from which they will access the EPP Service. Each service request will be authenticated in the following manner:

* At the firewall level the system will check for source IP, comparing it to those in the registered Access Control Lists;
* Once the IP has been verified, the next step is to initiate the TLS session, which will trigger:
** Secure Channel communication
** Client X.509 certificate check, which must be signed by the registry-operated Certificate Authority (CA), and must not be in the revocation list;
* The registrar must authenticate itself to the EPP service with a user⁄password combination.
This multilayer approach to client authentication protects against many forms of unauthorized access.

25.1.3.2. Server Selection

Our system performs load balancing to send clients to the best available EPP server. This balancing is done as part of the DNS name resolution process when the client seeks to connect to an EPP server. Each load balancer continuously monitors performance metrics, such as server load and geographic location, to determine the best server binding for each incoming client. This choice is delivered to the client through the address records in the DNS response returned to the client when it looks up the EPP server by name.

EXHIBIT ʺ25-Figure-EPP-Network-Diagram.pngʺ, explains how the client is directed to the EPP Servers using DNS queries to which the response is determined by performance data.

Server selection description:

* Clients (Registrar A and B) initiate the process by sending a DNS query to EPP.[TLD].registry.isc.org, where [TLD] is the string that represents the top-level domain
* [TLD].registry.isc.org. is a sub-domain delegated to the load balancers, thus the queries are sent to one of the load balancers (it does not matter which load balancer receives the clientʹs query.);
* Each load balancer evaluates the performance metrics from all four EPP Servers, and decides which EPP server is the best fit and returns the IP address of that server to the client;
* Clients connect to the IP as supplied by the Load Balancer that handled its request, initiate the EPP connection, and perform the desired EPP operations using that IP address.
25.1.3.3. EPP Session Handling

The numbers on this diagram correspond to the numbers in the EXHIBIT ʺ25-Figure-EPP-Flow-Diagram.pngʺ:

Once the Registrar has passed the source-IP verification and the TLS X.509 certificate validation, the EPP session follows this life cycle:

* Registrar initiates a connection to the server on TCP port 700 (EPP Port);
* The server replies with an EPP ʺgreetingʺ response, displaying the namespaces for objects and extensions available on the system;
* The Client processes the greeting and sends an EPP ʺloginʺ command with its credentials (user⁄password), along with the namespaces of the extensions that it wishes to use during this session;
* The EPP server checks the credentials against the Back-end system, and answers either with an EPP success or failure response;
* The registrar evaluates the authentication response from the server. In case it is a failure, it has the option of either disconnecting itself, timing out, or to try sending new authentication credentials again (step 3);
* If authentication succeeds, the client reads the next available command from its command queue and forwards it to the EPP Server;
* The server processes the command and responds back to the client with the requested data, confirmation receipt or EPP failure response;
* The client will then read another command from its queue; if that queue is empty, it will send an EPP ʺlogoutʺ command
* If the command requested was an EPP ʺlogoutʺ the server disconnects the client after sending the EPP success⁄ending session response back to the client.
25.2. EPP EXTENSIONS

25.2.1. Internationalized Domain Names

See EXHIBIT ʺ25-EXHIBIT-EPP-IDN.pdfʺ

25.2.2. Launch Phase

Domain registries typically operate in special modes within certain periods of time to facilitate allocation of domain names for a subset of the zone namespace that becomes available. This document uses the term ʺlaunch phaseʺ to refer to such a period.

The EPP domain name mapping RFC5731 is designed for the steady state operation of a registry. During a launch phase, registries typically accept multiple applications for a given domain name. This document proposes an extension to the domain name application in order to unambiguously manage the received applications.

See EXHIBIT ʺ25-EXHIBIT-EPP-LaunchPhase.pdfʺ

25.3. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in response to Question 47.

25.3.1. Human Resources

See EXHIBIT: ʺ25-Chart-Resourcing.pngʺ

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

25.3.2. Technical Platform

A total of four (4) high performance servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a eighty percent (80%) of the systemʹs total capacity. Provision of additional EPP servers does not disrupt ongoing operations.

Each of the registry locations, Palo Alto and Chicago, will, by itself, be able to sustain the entire estimated traffic level. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.

In addition, the Registry Operations Center will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.

25.3.3. Facilities

Two carrier grade data centers will be used to host the registry platform:

* Palo Alto Internet Exchange (PAIX) in Palo Alto, CA, operated by Equinix; and
* Equinix Co-location in Chicago, IL.
Although the sites have not yet been provisioned, the plan for the deployment of the registry takes into consideration the contracting of the datacenter space in mid 2012 so that it is fully provisioned by the time of delegation.

Each facility must cover the following criteria:

25.3.3.1. Power

Provide a minimum N+1 redundancy for every power system, to maximize uptime availability.

Uninterruptible Power Supply (UPS) systems to prevent power spikes, surges, and brownouts, and redundant backup diesel generators provide additional runtime.

Provide continuous monitoring of all power system components on-site or remotely, to respond quickly to any situations.

25.3.3.2. Cooling

Includes a robust HVAC system to provide stable airflow, temperature and humidity, with minimum N+1 redundancy for all major equipment.

Representative Specifications:

* 13,652 BTUH per cabinet
* Six (6) 750-ton centrifugal chillers
* Six (6) variable primary chilled water pumps
* Six (6) condenser pumps
* Six (6) cooling towers
* 24 air handling units in the colocation area
25.3.3.3. Flood Control

Built above sea level with no basements and have the following flood control features:

* Moisture barriers on exterior walls
* Dedicated pump rooms
* Drainage⁄evacuation systems
* Moisture detection sensors
25.3.3.4. Fire Detection and Suppression

Key features of the fire detection and suppression system must include:

* Multi-zoned, dry-pipe, double-interlock, pre-action fire suppression system
* Very Early Smoke Detection and Alarm (VESDA)
25.3.3.5. Earthquake

Must meet or exceed local building codes for lateral seismic design forces. Equipment and nonstructural components, including cabinets, are anchored and braced.

25.4. ABOUT THIS RESPONSE

This answer meets the requirements of this question:

* Our EPP protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* Our EPP service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* We have defined an EPP extension (to support internationalized names) in conformance with all relevant internet standards and RFCs. We will be submitting this extension to the IETF.
* That EPP extension is documented fully in this answer.
* That EPP extension is fully integrated into our registry technical approach and operations; it has no significant financial or resource impact.
* Our EPP service in conjunction with the EPP extensions defined here are consistent with the technical, operational, and financial approach as described in this application.
* Many of the needed technical resources (computers, network access, software, facilities, and management) are either already on-hand (and in some cases are already operational). Other technical resources are easily acquired as commercial off-the-shelf (COTS) items (such as servers, firewalls, and routers.) We already have presence in several data centers. And we already have the financial and staff resources.

TABLE OF CONTENTS

26.1 WHOIS SERVICE
26.1.1 Architecture
26.1.2 Port 43 Whois
26.1.3 Tiered Access Web⁄RESTful Interface
26.1.4 Privacy and Transparency
26.1.5 Abuse Mitigation
26.2 RESOURCING PLANS
26.2.1 Human Resources
26.2.2 Technical Platform
26.3 SYSTEM PERFORMANCE
26.3.1 Procedure
26.3.2 Results
26.3.3 Queries per Second
26.3.4 Round Trip Times
26.3.5 Server Load
26.4 ABOUT THIS RESPONSE

- - - - -

26.1. WHOIS SERVICE

26.1.1. Architecture

Our whois service is highly robust, geographically scalable, flexible, allows resources to be added or replaced without service disruption, and executes seamless failover. As shown in EXHIBIT ʺ26-Figure-Whois-Architecture.pngʺ it is located in three data centers. The location of the third data center will be determined by a security assessment to be performed in mid 2012. Each data center is internally redundant with local Load Balancers (LB) and firewalls, and each provides backup for the other. Global LB apportions the query traffic among the two centers. Each facility can handle the entire anticipated whois traffic load.

The LB servers provide two distinct forms of access: Port 43 Whois (RFC 3912), providing classic Whois service; and Tiered Whois Access using a RESTful web interface supporting various search facilities, and returns answers in XML.

When a user contacts the whois service, the LBs will route the user to the most appropriate data center and server. Should a server or a data center be unavailable, the LBs will spread the work among the rest of the servers to improve reliability. EXHIBIT ʺ26-Figure-Whois-Overview.jpgʺ further shows the front-end to back-end communication path.

26.1.1.1. Scalability

Every element of the whois service platform can be expanded without disrupting operations, and each single server can provide all necessary components of the system. Hence, a server can be placed in any location as chosen by the Registry Operations Center (ROC). In case of a large demand spike, such as DoS attacks or unpredicted traffic bursts, additional servers can be quickly deployed to distribute the load on a temporary basis.

26.1.1.2. Frequency of Updates

Whois servers query a database cluster that is part of our live database replication system.

This means that servers are up to date quickly after the submission of the operation. The servers are designed to be able to handle user queries even when isolated from the main database cluster replication mechanism. When replication is not possible, the system falls back to periodic (1 hour) updates.

26.1.2. Port 43 Whois

Our standard Whois service implementation consists of a high capacity Internet server that answers RFC 3912 requests on TCP port 43, waits for a query string and returning a text response. The system supports various anti-abuse mechanisms to protect the service.

26.1.2.1. Software

The whois server is a custom designed solution that uses our front-end architecture to interact with high performance back-end components.

Servers can be provisioned individually to increment the service capacity transparently. Systems architecture allows servers either to have their own read-only replica database, or to share a cluster among them for increased-demand scenarios.

26.1.2.1.1. Development Process

The Agile software development process used for this service is the same that is explained in our answer to Question 24.

26.1.2.1.2. Features

Our Whois system implements the following features:

* Input timeouts to limit resource usage (default 4 seconds).
* Input length verification to prevent resource exhaustion attacks (default 1024 bytes).
* Response Caching
* Statistics collection
26.1.2.2. Query Format

RFC 3912 specifies the format in which a Whois query is to be sent to the server. After the client has initiated the TCP connection to port 43 of a Whois server, the server expects to receive a valid query within the input timeout interval.

Any mixture of upper- or lower-case letters may be used in a query; the protocol is not case sensitive.

Queries are encoded using either US-ASCII or UTF-8; this allows for extended character sets while keeping backwards compatibility with older implementations.

To maintain compatibility with whois clients that use keywords before the query (usually to restrict the search to a specific type of object) the whois server is also capable of understanding queries with the CONTACT, HOST, DOMAIN or REGISTRAR prefixes: DOMAIN example.tld[CR][LF]

To permit querying of an IDN domain name, either the IDNʹs A-Label or the U-Label is allowed in the query string.

26.1.2.3. Query Response

The whois response consists of US-ASCII encoded text with a set of key⁄value pairs and informative notes describing the object queried and legal disclaimers.

Data objects are represented in key⁄value pairs. Lines start with a key followed by a colon ʹ:ʹ and a space as delimiters, followed by the value.

Fields that contain multiple values for the same key repeat the key at the beginning of the line.

This format conforms to Specification 4 of the Registry Agreement.

The EXHIBIT: ʺ26-Table-WHOIS-Responses.pdfʺ contains examples of the response for a WHOIS query for a domain, registrar and name server.

All of the fields specified in the response will conform with the mappings specified in the RFCs related to EPP: RFC 5730, RFC 5731, RFC 5732, RFC 5733, RFC 5734 and RFC 5910.

26.1.3. Tiered Access Web⁄RESTful Interface

26.1.3.1. Summary

To overcome the limitations of the Whois protocol as specified in RFC 3912 we have developed a tiered system that supports varying levels of access to Whois information.

The Tiered Access system uses a web-based RESTful (Representational State Transfer) interface to query the registry.

Tiered Access to Whois data is subject to strict security and access controls to ensure that access is limited to identifiable qualified users.

All transfers are encrypted using the HTTPS protocol.

Tiered Access queries can either be general exact-match queries similar to the port-43 service, or wildcard search strings that can yield more than one result. The particular information that is made available to the service user is configurable according to registry policy.

The registry operator can grant bulk data access to qualified organizations. Such use will be governed by a contract that sets forth the conditions and limitations of such access. Bulk data access is performed using a specialized RESTful interface based on HTTPS.

Currently the RESTful interface lacks any IETF standardization. ISC participates in this effort within the IETF and will adjust its operational implementation to be RFC compliant once such an RFC exists.

26.1.3.2. Searchability

The Tiered Access RESTful⁄Web-whois service is not bound to the same protocol technology restrictions as the port 43 (RFC 3912). Consequently there is room for innovation in the way clients interact with the service.

The system allows the user to query the whois database using keywords. These keywords will be partially matched against the following database fields:

* Domain name;
* contact names (including registrant), and:
** Postal Addresses;
** City;
** State;
** Country; and
** Any other subfields as needed
In addition to the partially matched queries, the system will also support exact match on the following fields:

* Registrar ID;
* Name server (using a Fully Qualified Domain Name);
* IP addresses (IPv4 and IPv6)
Multiple keywords may be combined using the following boolean operations: AND, OR and NOT.

Search results will consist of lists of objects that match the userʹs search criteria.

This search capability meets or exceeds the requirements of Specification 4 of the Registry Agreement.

26.1.3.3. Architecture

The Tiered Access interface to the whois system uses the same underlying architecture as described previously in this answer. The only difference is the way the system is queried and the format of the responses.

The architecture uses a RESTful interface, as described in http:⁄⁄en.wikipedia.org⁄wiki⁄Representational_state_transfer.

When issuing a Tiered Access query the following HTTP methods are supported:

* GET - This is used to obtain information about an object.
* HEAD - This is used to check object existence without obtaining the actual data.
26.1.3.4. Query Format

All the queries to the system are performed through HTTPS (HTTP Secure) using URLs crafted to contain the query information. These are described below.

26.1.3.4.1. Exact Matches

For exact match searches the user will issue an HTTP query of the following form: https:⁄⁄whois.nic.HIPHOP⁄rest⁄OBJECT⁄NAME where OBJECT corresponds to any of the following keywords:

* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
NAME corresponds to the object ID that the client wishes to retrieve.

26.1.3.4.2. Searchable Keywords

Searchable Whois accommodates those cases where customers such as law enforcement require additional capabilities not available via traditional Port 43 whois. To access the searchable part of the Tiered Access service, customers must have obtained authorization credentials by registering into the Web whois system, and providing at least:

* Email Address
* Desired Password
* First Name
* Last Name
* Affiliation or Capacity
Once the requester has submitted the registration form, an email address will be sent to verify the email address. This allow us to certify that the email is valid, and that it is in use by the current requester.

For a searchable Tiered Access Whois query the user will issue an HTTPS query of the following form:

https:⁄⁄USER:PASSWORD@whois.nic.HIPHOP⁄search⁄OBJECT⁄KEYWORDS?key=value

USER:PASSWORD provides the authentication credentials to use the RESTful interface.

OBJECT corresponds to any of the following keywords:

* domain - for domain objects;
* host - for name servers;
* contact - for contact objects; and
* registrar - for registrar information
KEYWORDS correspond to partially matched string corresponding to the identifier of the object, for example, the query:

https:⁄⁄foo:bar@whois.nic.HIPHOP⁄search⁄domain⁄exam?country=US&state=CA

Will result in the list of domain names that start with exam* and that have a registrant in the United States. By default the system uses the AND boolean operator to perform the search. However a + and ! character can be prepended to the value string to indicate OR or NOTʹ operations.

For example, a query similar to the one described above but for domain names where the registrant is NOT in the US would be:

https:⁄⁄foo:bar@whois.nic.HIPHOP⁄search⁄domain⁄exam?country=!US

Note that this interface is still under development. We are tracking the efforts of the IETF WIERDS working group in this area. Our interface will evolve in response to the IETFʹs work.

26.1.3.5. Query Response

The Tiered Access interface allows the output to be in XML format. XML tools such as XSLT and stylesheets make it possible to convert or re-format the data as desired.

26.1.3.5.1. XML Format

The current proposed format for the XML response, will use namespaces as similar as possible to those provided in RFC 5731, RFC 5732, RFC 5733 and RFC 5734.

The following exhibit shows an example of a whois response for example.HIPHOP.:

https:⁄⁄whois.nic.HIPHOP⁄rest⁄domain⁄example.tld.

See EXHIBIT: ʺ26-Exhibit-Restful-Whois.pdfʺ.

The format consist of a ʺresponseʺ tag that contains exactly one object, in this example, the domain object example.tld.

Any objects mentioned within the response object will be returned in the ʺadditionalʺ section using the same object-notation format.

This format is subject to change when the IETF working group standardizes the interface.

26.1.4. Privacy and Transparency

ISC SRS implements the ability to specify the fields that can be publicly displayed as described in RFC 5733. Fields marked to prohibit disclosure are not shown to public or unauthorized users. Registrars can set the level of privacy based on the relevant jurisdiction and will be required to comply with applicable privacy protection laws. Uniregistry will provide registrars with a set of default privacy level protections based on the country of the registrant, to the extent that such privacy protections are known. As the party collecting data, registrars are best positioned to provide the required notifications, warnings or terms of service to their customers as dictated by jurisdictional requirements. The RFC 5733 mechanism is combined with appropriate language in the registrar agreement to facilitate compliance with jurisdictional requirements on the information that is presented to third parties and under what circumstances.

ISC SRS also implements the ability to remove Contact objects when those are not required for other active registrations, allowing inactive registrants to remove their personal information from the registry database, allowing compliance with all current privacy requirements at the required jurisdictions.

To promote transparency, Uniregistry will implement a service in which registrants can opt-in through their registrar, allowing a registrant to receive notice whenever domain name contact information is accessed via one of the whois querying mechanisms.

Certain jurisdictions, notably the European Union, have implemented data protection regulations and principles that may conflict with one another and with which there has been tension and ongoing discussion in relation to ICANN policies and requirements. While Uniregistry cannot track and implement multiple conflicting data protection requirements on a global basis, the primary commercial relationship is between the registrar and the registrant.

Uniregistry will continue to monitor policy developments in this area, which principally occur in venues such as the Internet Governance Forum and the ICANN Government Advisory Committee, to remain abreast of best practices in this area. Uniregistry will require its accredited registrars to maintain compliance with relevant regulations in their respective jurisdictions, and receive input from impacted registrars to detemine how Uniregistryʹs Whois practices can best accomodate the continued expansion of domain name availability into jurisdictions under-served by local registrars and which may present conflicts that may need to be addressed with the appropriate authority in such jurisdictions.

26.1.5. Abuse Mitigation

Whois services are subject to multiple forms of attack, some of them well known in the industry. The first and most common line of defense is to rate-limit the number of queries one client can perform according to various criteria.

Since it is not possible to envision every type of attack against a whois server, the registry will collect queries in real time and stream them into an analysis system to detect unusual patterns and behaviors, feeding the ROC with the information it needs for defense.

The provision of Whois services will be subject to terms prohibiting the use of Whois data for mass marketing and other inappropriate uses. Uniregistry will actively seek to detect these activities, investigate third party reports of misuse of Whois data, and de-accredit registrars if they or their resellers are found to be facilitating or engaging in such activies. Uniregistry will also seek judicially-available sanctions against non-registrar abusers of Whois data in violation of the terms of service.

26.2. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in our response to Question 47.

26.2.1. Human Resources

See EXHIBIT: 26-Chart-Resourcing.png

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

26.2.2. Technical Platform

Four servers will be made available to registrars to interact with the registry. Provisioning of additional servers is a straightforward procedure that can be triggered by demand thresholds, which is currently set a 80% of any systemʹs total capacity. Adding servers does not disrupt ongoing operations.

Each of the registry locations is able to sustain the entire estimated traffic level by itself. Nevertheless, we expect that traffic load will remain equally distributed among them to provide a better user experience.

The ROC will be monitoring source traffic to gather data that can be used to plan the location of potential new sites aimed when expansion becomes necessary.

26.3. SYSTEM PERFORMANCE

26.3.1. Procedure

To test the whois service, a custom software defined as ʹperf-whoisʹ was written with the purpose of simulating client connections.

The test was executed using:

perf-whois -h 10.1.2.1 -p 43 -n 1000 -q ʹdomain example3.iscʹ -d results⁄
The software then proceeded to generate:

* One stream of 1000 sequential queries
* 2,4,8,16,32,128 parallel streams of 1000 queries each
The software was collects the round-trip-time and the number of queries per second of the whois queries.

26.3.2. Results

26.3.3. Queries per Second

The EXHIBIT ʺ26-Chart-Qps-graph.pngʺ is a graphical view of the number of queries per second collected by the tool.

26.3.4. Round Trip Times

The current Service Level Agreement (SLA), as described in Specification 10 of the Applicants Guidebook, references a maximum of 2000 milliseconds for at least 95% the RTT of the whois service. During our test we did not see any RTT values go higher than 229 ms.

Since we are planning to deploy four (4) high performance Whois servers, we expect to exceed the SLA with the setup that we currently have in place.

The EXHIBIT ʺ26-Chart-Rtt-graph.pngʺ is a graphical view of the raw data as collected by the tool.

26.3.5. Server Load

During the performance test, we collected CPU usage (system and user). We did not observe the system to be even slightly stressed during the procedure. The CPU usage levels increased to a maximum of 70%, clearly with enough capacity to keep performing other functions.

The EXHIBIT ʺ26-Chart-Vmstat-graph.pngʺ show the results of the CPU usage of the server during the test.

26.4. ABOUT THIS RESPONSE

This answer meets the requirements of this question:

* Our Whois protocols, interfaces, and data conform to all relevant internet standards, best practices, and RFCs.
* We support a searchable whois via our Whois Tiered Access interface.
* Access to our Tiered Whois Service is protected by security and access control.
* All of our Whois services are protected against foreseeable attacks.
* Our Whois service is highly robust and scalable, with dynamic load balancing, geographic distribution, high levels of security and access control, and fast fail-over.
* Our Whois service is fully integrated into our registry technical approach and operations.
* Our Whois service complies with Specifications 4 and 10 of the Registry Agreement.
This answer exceeds the requirements of this question:

* We provide a searchable Whois service using a RESTful web service interface that allows searching by several registration fields and with combinations of search operators. We provide a service that is compliant with relevant privacy protection laws.
* Our Whois services are protected by access controls and rate limitations. Advanced features are constrained so that they may be used only by known users who have been granted access credentials.

TABLE OF CONTENTS

27.1 DOMAIN REGISTRATION LIFECYCLE
27.1.1 Note on the Status Codes
27.1.2 Initial Registration ⁄ Add-Grace
27.1.3 Registration Changes Affecting The Registration Lifecycle
27.1.4 Expiration of Registration Term
27.1.5 Delete Cycle and Redemption Grace Period
27.1.6 Deletion
27.2 RESOURCING PLANS
27.2.1 Human Resources
27.3 ABOUT THIS RESPONSE

- - - - -

27.1. DOMAIN REGISTRATION LIFECYCLE

The domain registration cycle for second-level domain name registrations in .HIPHOP is substantially the same as the well-understood life cycle in the existing generic top-level domains.

Second-level domain names are registered for a term which is an integer number of years, up to a maximum registration term of ten years.

An initial Add Grace Period (AGP) of five days is provided during which domain names registered as a consequence of error or registrar malfunction can be canceled. To deter the abusive practice of “domain tasting” or “domain kiting” registrars must provide a report of circumstances under which the Add Grace Period is invoked, and are limited to a fixed proportion of such instances.

During the registration period, second-level domain names may be transferred from one registrant to another, and from one registrar to another. Such names are subject to transfers, cancellations, and de-activation in accordance with intellectual property protection and abuse policies described under the relevant responses of this Application.

A substantial improvement to security and stability is provided through the addition of a “quiet period” that occurs after expiration of a domain name and prior to deletion of that domain name from the registry. While ICANN has addressed the practice of Add Grace abuse at the initial period of domain registration, the problems associated with a deterministic domain deletion cycle have gone unaddressed.

One of these problems is rapid polling of registry systems by those seeking to instantaneously register deleted domain names. The intent may be to innocently acquire deleted names for a legitimate new use. Or the intent may be to acquire recently deleted names in order to usurp the prior registrantʹs identity. (Naive prior registrants may not realize that after abandoning a name that a successor may use that domain name to maliciously masquerade as that prior registrant or to monetize residual network traffic coming into that name.)

Quiet periods of this type are a standard practice for many internet service provider account identities and email addresses; an extended and non-deterministic period of non-availability for domain names responds to registry stability and registrant security issues which have not been addressed in the existing generic top-level domains to date.

The significant events of a standard domain lifecycle are explained in the following sections, and graphically depicted in the two flow diagrams as follows:

See EXHIBIT ʺ27-Figure-Domain-Lifecycle-1.pngʺ referenced as 27-1 below; and

See EXHIBIT ʺ27-Figure-Domain-Lifecycle-2.pngʺ referenced as 27-2 below.

27.1.1. Note on the Status Codes

Object status codes used in this answer have been based on the status codes explained in the following references

* RFC 3915 -- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
* RFC 5730 -- Extensible Provisioning Protocol (EPP)

27.1.2. Initial Registration ⁄ Add-Grace

Referring to step 1 of Exhibit 27-1, a second level domain name is accepted for registration if (a) it is not already registered or reserved, (b) it satisfies the string requirements (e.g. 63 allowable characters, no trailing dashes, etc.), and (c) administrative requirements of the Registrar Accreditation Agreement are satisfied, such as prohibition against securing registrations for which a registrar has not obtained assurance of payment.

During the first five days of registration, at step 2, the domain name is subject to an initial Add-Grace period (AGP). The purpose of the AGP is to provide an opportunity for a registrar to discontinue a registration made in error, such as by a malfunction of registrar software resulting in unintended registrations. As shown in steps 3-5, if a delete command is received during the AGP, the registrar is refunded the registration fee, and the registration proceeds to immediate deletion at step 39 (label D, Exhibit 27-2). During the AGP, the ICANN Add Grace Period Limits Policy (http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) shall be applied to deter “domain tasting”.

Significant provisions of the ICANN AGP include:

A. During any given month, the registry shall not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations in that month (calculated as the total number of net adds of one-year through ten-year registrations), or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted for extraordinary circumstances.

B. A registrar may seek a specific one month retroactive exemption from application the AGP restrictions upon the documented showing of extraordinary circumstances. For any registrar requesting such an exemption, the registrar must confirm in writing to the registry how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and⁄or were outside the Registrarʹs control. Acceptance of any exemption will be at the sole and reasonable discretion of the registry in consultation with ICANN. ʺExtraordinary circumstancesʺ which reoccur regularly for the same Registrar will not be deemed extraordinary. Invocation of such circumstances for any two one-month periods in a single year will result in application of the second-tier penalties described in the response to Question 29, and successive tiered penalties for each month thereafter, leading to de-accreditation.

C. The registry shall report each instance of application of an exemption to ICANN, along with a brief descriptive identification of the type of extraordinary circumstance and the action, approval or denial that was taken by the registry.

If the registration is not deleted during the AGP, it proceeds to the registration term (step 6).

27.1.3. Registration Changes Affecting The Registration Lifecycle

Registrations during the contracted term will be subject to actions which do not affect the lifecycle, such as WHOIS updates and nameserver changes. Also, during the registration term Uniregistry may re-assign nameservers to prevent resolution of a domain name due to action taken under the Uniregistry Abuse Policy (see Question 29), or in response to a decision under the Uniform Rapid Suspension Policy (URS) requiring that the domain name resolve to a designated web page indicating that the domain name has been disabled. Uniregistry will also implement such changes as may be ordered by a court of competent jurisdiction or necessitated by registrar de-accreditation. Absent such unusual circumstances, any of the following actions prior to expiration of the registration term, will result in extension or shortening of the term:

Extension of Term (EPP command ʺrenewʺ), step 8: A registration can be extended prior to expiration of the registration term in one year increments up to a total of ten years maximum. The account of the sponsoring registrar at the time of the additional extension will be charged for the number of years the registration is extended. As indicated in steps 12-14, if a delete command is received within a period of five days, the registrar will be credited for the previously charged extension, and the registration will proceed to the Delete Cycle (label A, Exhibit 27-2).

Express Deletion (EPP command “delete”), step 9: An express deletion issued by the sponsoring registrar during the registration term will initiate the Delete Cycle (label A, Exhibit 27-2).

Registrar Transfer (EPP command “transfer”), step 10: If a gaining registrar issues a transfer command, the registry will re-assign the authoritative registrar for a domain name upon receipt of a valid transfer request and authorization code. Transfers shall be implemented in accordance with the current version of the ICANN Inter-Registrar Transfer Policy (http:⁄⁄www.icann.org⁄en⁄transfers⁄). If the losing registrar expressly authorizes the transfer, the transfer shall proceed immediately. Otherwise, the transfer will proceed within five days. When the registration is assigned to the gaining registrar, the expiration date of the domain is extended by at least one year, and limited by the maximum registration term of ten years, and the gaining registrar is charged accordingly. As indicated in steps 21-23, if an express deletion is issued by the gaining registrar within five days, the registrar is credited for the renewal fee mandated by the transfer, and the registration proceeds to the Delete Cycle (label A, Exhibit 27-2). Otherwise, the registration continues in accordance with the new registration term (step 6).

27.1.4. Expiration of Registration Term

Registrars will be required to implement the relevant provisions of the ICANN Expired Domain Deletion Policy (EDDP) (http:⁄⁄www.icann.org⁄en⁄registrars⁄eddp.htm) for names subject to deletion as a consequence of non-renewal, and to accept renewal payments for names subject to dispute in accordance with the provisions of the EDDP relating to domain dispute procedures.

At, step 7, upon the completion of the contracted registration term, the registration proceeds to an Auto-Renew Grace Period (ARGP) of forty five days in step 24. The sponsoring registrar is required to notify the registrant of impending expiration at least twice prior to expiration - once at least 30 days prior to expiration and once within 30 days of expiration. By default under the ARGP, expired domain names will be automatically renewed by the registry for a single year.

In steps 25 and 26, if a domain is deleted within the ARGP, the sponsoring registrar at the time of the deletion receives a credit of the renewal fee (step 14), and the registration proceeds to the Delete Cycle (label A, Exhibit 27-2). If no delete command is issued during the ARGP, then the renewal is confirmed, and the registration proceeds in accordance with the renewed term (step 6). A registration can also be expressly renewed and its term extended beyond a single year during the Auto-Renew Grace Period, subject to a limit of ten years total. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

In step 27 of Exhibit 27-1, if a domain is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge (step 28), the year added by the Auto-Renew operation is canceled, and the registration proceeds to the transfer process described above (label E, Exhibit 27-1). In the event of a bulk transfer with ICANN approval during the Auto-Renew Grace Period (such as may occur upon de-accreditation of the sponsoring registrar), the expiration dates of transferred registrations are not affected and the losing registrarʹs account is charged for the Auto-Renew.

27.1.5. Delete Cycle and Redemption Grace Period

A Redemption Grace Period (RGP) is applied at the initial step 30 of the Delete Cycle. The RGP is a period of six months, during which the subject registration is placed on REGISTRY-HOLD, and nameserver records for the registration are removed from the zone file, such that the domain name will not resolve. This six month period is significantly longer than the present industry standard, which has been subject to community criticism for not providing sufficient time for registrants with extenuating circumstances. Rendering the registration non-functional in this manner is effectively the final notice to the registrant that the name is subject to deletion at the end of the RGP, even if inaccurate contact data or other technical issue resulted in failure of the registrant to receive renewal reminders or expiration notices.

During the RGP, as indicated in steps 31-35, the registration may only be restored to the original registrant, subject to issuance of a “restore” command (step 32), followed by receipt of a redemption report from the sponsoring registrar (step 35) within a Restore Lock Period of five calendar days (step 34). During the RLP, the nameservers are restored, and the domain status is:

PENDING RESTORE + UPDATE PROHIBITED + DELETE PROHIBITED + RENEW PROHIBITED + TRANSFER PROHIBITED

If a Restore Report is not received from the registrar within the RLP, the nameservers are removed, and the domain is returned to step 30 until expiration of the RGP with status of:

PENDING DELETE RESTORABLE + HOLD

In order to restore the registration, a redemption report submitted in step 35 must indicate that the registrar has (a) verified identity of the party seeking redemption of the registration, (b) paid a renewal fee, and (c) paid an RGP service fee for reviewing the redemption report circumstances of requested redemptions. If so, the registration returns to step 6 of Exhibit 27-1 for the renewed term of registration.

Extension of the RGP to six months, as proposed herein, addresses a frequently-criticized aspect of current registration practices, under which a successive registrant of a previously registered domain name may utilize it to engage in identity fraud or reputational damage to the previous registrant. The six month period proposed here, reduces the efficacy of this abusive practice.

27.1.6. Deletion

If the registration is not redeemed during the RGP, it proceeds to Pending Delete status in step 36. Here, the lifecycle varies significantly from the standard gTLD registration lifecycle. Instead of a deterministic interval between the end of RGP and the start of deletion, a random, non-published time interval of 1 to 30 days is set for final deletion of the registration. When the random deletion period has elapsed (step 38), the registration proceeds to final deletion from the registry (step 39).

Registrars found to be engaging in unreasonably repetitive registration attempts of registrations during the Quiet Period (such as attributable to automated processes being conducted by or through the registrar, and not as a consequence of manual availability queries by end users) will be suspended from registry access until the cause of such repetitive attempts are eliminated. Repeated suspensions for this reason shall lead to the graded penalties described in the response to Question 28 of loss of incentives, financial penalties, and ultimate de-accreditation.
27.2. RESOURCING PLANS

Costs and procurement of the resources described here are detailed in response to Question 47.

27.2.1. Human Resources

See EXHIBIT: ʺ27-Chart-Resourcing.pngʺ.

27.3. ABOUT THIS RESPONSE

We believe that this answer meets the requirements and addresses all the points of this question:

* We have provided a complete and detailed statement of the registration lifecycle to be used for .HIPHOP.
* This lifecycle is substantially the same as the well-understood life cycle in the existing generic top-level domains.
* We have modified the lifecycle to redress problems, such as identity theft, that can occur when names are deleted.
* This lifecycle is coupled to and consistent with our abuse mitigation policies.
* We have adequate technical, operational, legal, and financial resources to handle this lifecycle.

TABLE OF CONTENTS

28.1 ABUSE PREVENTION AND MITIGATION
28.1.1 Overview
28.1.2 Abusive Conduct
28.1.3 Directory of Abuse Response Tools
28.1.4 Single Point of Contact
28.1.5 Abuse Identification, Queuing, and Response
28.1.6 Pro-active Abuse Detection And Mitigation
28.1.7 Whois Accuracy
28.1.8 Terrorism and International Criminal Organizations
28.1.9 Criminal Investigations ⁄ Law Enforcement Contacts
28.1.10 Cooperative Efforts
28.1.11 Orphan Glue Records and Consistency Checking
28.1.12 Registrar incentives ⁄ disincentives
28.1.13 Registrant Security
28.1.14 APPENDIX A: UNIREGISTRY .HIPHOP ABUSE POLICY
28.2 RESOURCING
28.2.1 Human Resources
28.3 ABOUT THIS RESPONSE

- - - - -

28.1. ABUSE PREVENTION AND MITIGATION

28.1.1. Overview

UniRegistry understands that the privilege of operating Internet infrastructure brings with it the responsibility of ensuring that the infrastructure operates in a secure, stable and predictable manner. Additionally, the ultimate commercial success of the registry is determined in large part by its reputation among users of the internet. To the extent that any TLD is known as a haven for abusive activities, such a reputation may be imputed in the minds of users to all registrants in the TLD. To protect against such harms, UniRegistry has implemented a comprehensive policy to prevent, mitigate and correct abusive uses of the DNS, registrations, and Whois as they are detected.

At the same time, UniRegistry believes that domain name registrants should be secure in their ownership of domain names. Our abuse policies will be developed and implemented in an open and transparent manner designed to allow users a clear and accurate understanding of the state of their domain names at all times.

For transparency, orders from courts directed to the registry for purposes of altering the registration state or ownership of a domain name will be posted on a publicly accessible website operated by UniRegistry.

What constitutes ʺabuseʺ can be subjective and can also depend on the jurisdiction in which the ʺabuseʺ has an impact. Additionally, those intent on disruptive or criminal behavior on the internet are endlessly creative, so a static definition of ʺabuseʺ can become obsolete or inapplicable to new forms of undesired behavior. What can be done at a registry level is to (a) detect and investigate behaviors frequently associated with common known forms of abusive behavior, and (b) to respond promptly and intelligently to reported instances of abusive behaviors with appropriate action, bearing in mind that a domain name registrant may itself be an incidental victim of hacking, identity theft, and other abusive activities designed to conceal the identity of a third party bad actor.

The primary commercial relationship defined by a domain registration is between the registrant and the registrar. Many incidents of abuse arise from compromise of the registrantʹs account with its registrar or hosting provider (which is often the registrar). For example, many phishing sites are deployed in subdirectories of web hosting accounts of sites which are otherwise operating normally. Because these incidents arise at a level which is not best addressed by disabling a domain name in its entirety, .HIPHOP accredited-registrars are a key component of our abuse policy and response. The registrars have a direct relationship with the customer, and are most favorably positioned to address and resolve instances of account hacking with their customers.

UniRegistry will provide front-line response to urgent abuses that threaten the security or stability of the DNS. UniRegistry will also track registrar response to abuse reports in order to take action in the event the registrant, registrar or hosting provider does not respond to or mitigate issues in a reasonable amount of time. What is ʺreasonableʺ in this context depends on the nature of the abuse at issue.

We believe in the value of accurate contact information for all .HIPHOP domain name registrants. To ensure compliance both with ICANN policy and UniRegistry whois accuracy policies, UniRegistry has adopted a three-pronged approach to data accuracy, described below, which will (i) provide registrants an incentive to providing accurate information; (ii) create consequences for non-compliance for registrants and registrars, including loss of a domain name or loss of accreditation; and (iii) evaluate and, if necessary, correct registration data on a continuous, rolling basis.

28.1.2. Abusive Conduct

UniRegistry policies, flowing to registrars and registrants through their relevant agreements, will prohibit abusive uses of .HIPHOP domain names. As defined by UniRegistry, ʺAbusive Useʺ shall include the following actions:

(a) Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums.;

(b) Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;

(c) Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;

(d) Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses;

(e) Fast flux hosting: Use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves;

(f) Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);

(g) Child endangerment, including the distribution of child pornography; and

(h) Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

What constitutes ʺabuseʺ is an evolving definition, as bad actors develop more sophisticated or novel forms of undesired behavior. Uniregistry shall maintain engagement with the relevant policy bodies in addition to ICANN, such as the Internet Governance Forum, the Internet Engineering Task Force, and other organizations which provide government and non-governmental policy reports identifying new forms of abusive behavior, and Uniregistry will continue to update its abuse response policies and procedures based on evolving best practices. By the same token, registrants need to have a degree of security that their domain names will not be disabled in response to spurious or incorrect abuse reports.

28.1.3. Directory of Abuse Response Tools

The first issue confronting entities engaged in abuse response, or victims of abusive behavior is often ʺto whom do I report this?ʺ As discussed below, Uniregistry will maintain a single point of contact for receiving abuse reports, and routing them to the appropriate responder. In addition, Uniregistry will maintain in connection with the single point of contact, a directory of third party entities, such as the Internet Crime Complaint Center (IC3) maintained by the US Federal Bureau of Investigation, the UK Serious Organized Crimes Agency, and other law enforcement bodies which are engaged in international cooperative efforts to address internet crime. Additionally, the directory will include resources to consumer agencies and other organizations which provide tools, education, monitoring and assistance in combating abusive internet activities.

This information will be published on the registry website. We will receive reports from registrars, resellers, registrants, and third parties.

28.1.4. Single Point of Contact

To make contacting UniRegistry easy and intuitive, we are reserving ʺABUSE.HIPHOPʺ as a name for exclusive use for the registry for purposes of abuse reporting. The main website for the registry, and other intuitive names, such as ʺUNIREGISTRY.HIPHOPʺ and ʺNIC.HIPHOPʺ will include links to the abuse reporting system. The website at http:⁄⁄ABUSE.HIPHOP⁄ will host UniRegistryʹs abuse policy (attached as Appendix A to this answer), provide a web form for reporting DNS abuses, and provide postal, fax, email and telephonic abuse reporting contacts. In addition, a website at NIC.HIPHOP will be used as a directory for all registry services, including links to UniRegistryʹs abuse policy for .HIPHOP and the registryʹs abuse reporting and tracking facilities. We will further maintain a designated e-mail contact address, such as abuse@abuse.HIPHOP to be provided specifically to law enforcement agencies, Computer Emergency Response Teams (CERTs), the anticrime and anti-phishing community (interveners), businesses that provide online reputation protection services, network operators, and Internet users to report issues of abuse.

A front-end help desk will receive reports by telephone, email, FAX, and other unstructured means of communication, as an intake mechanism for abuse reports to be provided to the Registry Operations Center (ROC). The help desk will be staffed 24x7. The help desk staff will follow a structured procedure for taking abuse reports and entering data into the web form for reporting abuse. The help desk staff will not have discretionary authority to affect operation of a domain name.

Structured input, for example reports made via our abuse reporting website at ABUSE.HIPHOP, will bypass the help desk and be sent directly to the ROC. The abuse reporting form will include input fields to identify the domain name at issue, a menu for identifying whether the type of abuse being reported falls into a designated category defined by the Uniregistry abuse policy, contact information for the person or entity making the report in the event further information is needed, and text entry for further relevant information. Upon completion of the abuse reporting form, the reporting system will confirm whether the domain name at issue corresponds to a non-reserved domain name registered to an end user, and an email message requiring confirmation will be sent to the reporter, to discourage reports which are themselves abusive.

The ROC is a dispatch point. All incoming reports are entered into a tracking system. Each report will be given a unique identifier for tracking and compliance purposes. The ROC will do an initial evaluation of each incoming report to ascertain whether that report indicates abuse of some kind, what type of abuse is alleged, whether the report is indicative of a technical failure or is a misdirected inquiry non-indicative of abuse. The tracking system will generate reports to registry management to assure that all reports are handled in a timely and responsive manner.

Incoming reports that suggest potential abuse of UniRegistryʹs services will be sent to (i) UniRegistryʹs compliance department; (ii) UniRegistryʹs back-end service provider ISC; and (iii) the registrar of record for any reported .HIPHOP domain name included in the abuse report.

28.1.5. Abuse Identification, Queuing, and Response

As abuse reports are received, UniRegistry will use a combination of automated processes and human review to place them into three categories for response. UniRegistry also will accept and give compliance priority to abuse reports sent in machine-readable Abuse Reporting Format (ARF). The ABUSE.HIPHOP website will contain information for internet service providers, email service providers, hosting companies and other Internet infrastructure providers about how to participate in UniRegistryʹs complaint feedback loop.

Category 1 reports will receive the highest priority. These are reports of abuse in which use of a .HIPHOP domain name is either (a) causing immediate and substantial injury to Internet infrastructure, systems, or services that, if not terminated immediately, will cause unavailability or material degradation of such infrastructure, systems or services, or (b) obvious instances of criminal activity which, if not ceased immediately, is likely to cause substantial injury to Internet users. As soon as an abuse report is categorized as a Category 1 abuse, a ʺserverHoldʺ status will be set, effectively unpublishing the name from the Internet (though whois contact details will remain published and unchanged). Immediately after the deletion of the nameserver records from the zone file, notices of the domain name takedown will be sent to both the affected domain name registrant and the domain nameʹs registrar of record. The notice will provide a record of the report received, the reasons for the action taken, and a point of contact for the registrant or registrar to address the takedown and seek republication of the domain nameʹs DNS records.

Category 2 reports will be sent to registrars and registrants for investigation and response. Category 2 reports of abuse are deemed serious and potentially threatening to Internet infrastructure, systems, or services but which either (i) UniRegistry cannot verify or (ii) the potential abuse is not immediate and ongoing. For these reports, UniRegistry anticipates that the registrar will provide first line response, given its relationship to the registrant. UniRegistry will expect a response within seven (7) days. If no response is received, UniRegistry will makes its own decision about how to handle the issue.

Category 3 reports will be sent to registrars and registrants for investigation and response. Category 3 abuse reports consist of all abuse reports that do not otherwise fall into Category 1 or 2.

28.1.6. Pro-active Abuse Detection And Mitigation

It is, of course, essential to react appropriately to abuse reports. Often, such reports are ʺtoo little, too lateʺ as the intended harm has already taken place. As the zone operator for the .HIPHOP, Uniregistry is positioned to detect patterns of zone access and internet traffic indicating an activity profile consistent with known forms of abuse. We believe that detection of activity consistent with abusive behavior is preferable to an after-the-fact response once the damage has been done. UniRegistry will make use of ISCʹs Security Information Exchange (SIE) network to track, in real time, domain names associated with abusive behavior. Recently implemented, the SIE has proven itself an effective mitigation technique for protecting against misuse of network infrastructure and Internet-based resources. The SIE network consists of more than one hundred (100+) passive DNS sensors located in several Internet Service Providers (ISPs), collecting actual real time queries made to authoritative name servers from millions of Internet users.

SIE is an industry and law enforcement clearinghouse of various kinds of security-related information that can be accessed by vetted, credentialed participants in real time subject to common access rules and following strict privacy guidelines. Among the variety of information available through SIE, there are ʺchannelsʺ that provide a real-time view of DNS data associated with malicious use. Tapping this information allows UniRegistry a better chance to proactively detect uses of domain names under its responsibility that constitute abuse.
Domain names associated with suspicious activity profiles will be manually reviewed by the abuse response team as such activity is detected. Where it appears that some form of abuse (as defined in this response) is occurring the detected abuse will be addressed at the registry level in those instances where disabling the domain name is indicated or the abuse will be referred to the registrar so that the registrar can take corrective action with the registrant within a reasonable time. Detected suspicious activity profiles in which no clearly apparent abusive behavior is taking place will also be referred to the registrar for further investigation with the registrant.

28.1.7. Whois Accuracy

Accurate information in the whois database protects both domain name registrants and the users who rely on those registrantsʹ Internet-based services. UniRegistry has taken a multi-factored approach to the promotion of whois accuracy. We create incentives to registrants to provide accurate information in the first instance and to keep that information current. We have sanctions, ranging from temporary suspension up to de-accreditation, for registrars that fail to seriously heed their contractual responsibilities to obtain and maintain accurate whois data and to regularly inform registrants of their corresponding responsibility to provide and maintain accurate WHOIS data.

Uniregistry will require registrars to implement and confirm implementation of the WHOIS Data Reminder Policy (WDRP - http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm), under which the registrar will present current WHOIS information to each registrant at least annually and remind the registrant that inaccurate or false WHOIS data can result in the domain name registration being canceled.

Uniregistry will require registrars to receive and act on reports generated by the WHOIS Data Problem Report System (WDPRS - http:⁄⁄www.icann.org⁄en⁄whois⁄wdprs-report-final-31mar04.htm). The WDPRS system, as currently implemented, involves communications between ICANN and the registrar. In the event Uniregistry is notified by ICANN of registrar non-responsiveness to a WDPRS within the 15 day required response time to WDPRS reports, Uniregistry will investigate registrar handling of WDPRS complaints. If the registrar does not respond to or investigate WDPRS, and either cannot ensure compliance or is repeatedly non-compliant, such registrar will be suspended until such time as it can ensure compliance.

In addition to these passive and reactive measures, Uniregistry will implement an active WHOIS accuracy program. Registrations will be periodically statistically sampled (in the event of low registration volume the sample will include all registrations) and tested. Testing will be performed by commercial ʺdata hygieneʺ services for such internal accuracy indications as whether postal data and telephone numbers are appropriate for the indicated registrant address (i.e. postal codes correspond to the indicated geographic area of the registrant, telephone numbers are of the corresponding format and dialing codes). Uniregistry shall process exceptional WHOIS data identified by the active WHOIS data accuracy program in the same process flow as WDPRS reports are handled.

28.1.8. Terrorism and International Criminal Organizations

Uniregistry will periodically review WHOIS data against identity and contact data provided by the United States Department of Treasury Specially Designated Nationals List (SDN) maintained by the Office of Foreign Asset Control (http:⁄⁄www.treasury.gov⁄resource-center⁄sanctions⁄SDN-List⁄Pages⁄default.aspx). Any domain name found to be registered to an SDN will be summarily suspended from operation.

28.1.9. Criminal Investigations ⁄ Law Enforcement Contacts

Uniregistry will receive service of any warrant, subpoena, seizure order or equivalent directive served in Uniregistryʹs charter jurisdiction, or upon Uniregistryʹs agents for service of process in the United States and the United Kingdom. Contact information for Uniregistryʹs agents for service of process will be published at ABUSE.HIPHOP, who will issue immediate confirmation of receipt to the sender. Uniregistry shall maintain, and shall require accredited registrars to maintain, a law enforcement contact, including a 24⁄7 telephone contact by which law enforcement agencies may inquire and obtain confirmation that any other written communication directed to it has been received. Subject to confirmation of bona fide law enforcement status and provision of appropriate contact information, receipt of written and email communications from law enforcement authorities will be acknowledged within 24 hours.

Uniregistry cannot prescribe in advance how it will respond to every type of contact from every jurisdiction. What may be considered defensible freedom of expression in one jurisdiction may constitute a criminal activity in another. Uniregistryʹs response to warrants, subpoenae, court orders and the like will be guided by whether such documents originate with a court or authority of competent jurisdiction over the matter. ʺCompetent jurisdictionʺ, in general, is understood to indicate a governmental authority possessing (1) statutory authority to adjudicate the cause of action and to enforce remedies, and (2) personal jurisdiction over the registry, registrar, or registrant by virtue of presence in the indicated jurisdiction or where the actorʹs contacts with the jurisdiction are sufficiently continuous and systematic that accession to such jurisdiction does not violate inter-jurisdictional norms. For the purpose of legal compliance in situations where ʺcompetent jurisdictionʺ is questionable, but where the effects of the activity in question have a substantial impact in the indicated jurisdiction, Uniregistryʹs response will be guided by principles of inter-jurisdictional enforcement in the next-nearest ʺcompetent jurisdictionʺ (such as any competent jurisdiction attaching to the registry, registrar or registrant). For example, in relation to activities conducted in Country A having an impact in Country B with which there are no relevant treaties, diplomatic relations, or law enforcement cooperation, then the activity in question will be assessed in accordance with the relevant authority of Country A alone, and whether an entity in Country A would ordinarily be subject to law enforcement or other government actions undertaken in Country B in relation to an entity in Country B.

In no instance will Uniregistry undertake an investigation of reports alleging sexual or other illegal exploitation of minors, as accessing such material is itself a criminal activity. All reports alleging sexual or other illegal exploitation of minors will be referred to the CyberTipline operated by the US National Center for Missing and Exploited Children (NCMEC), and Uniregistry will receive and act upon instructions received by the NCMEC in relation to the report.

UniRegistry will publish on its single point of contact page directions to law enforcement around the globe on how to become a recognized law enforcement reporter in order to streamline jurisdictional review of proposed enforcement actions, in circumstances where the same or similar claims, parties and issues are involved. Recognized law enforcement reporters will be provided with information about how to contact UniRegistry and receive a token that will pre-authenticate them for future contacts with the registry.

28.1.10. Cooperative Efforts

Effective response to abuse activity on the internet is often the product of non-institutionalized and occasionally ad-hoc cooperation among the technical and law enforcement communities. The detection and response to botnets, malware, etc. can require mutual trust, goodwill and discretion among those best positioned to cooperate in such instances. For example, the so called ʺConfickerʺ malware (http:⁄⁄en.wikipedia.org⁄wiki⁄Conficker) required an extraordinary effort to convene and coordinate a response which became known as the ʺConficker Working Groupʺ (http:⁄⁄www.confickerworkinggroup.org⁄wiki⁄). Key personnel of both Uniregistry and ISC have long been participants in the relevant working groups, task forces, and internet policy groups in which the requisite trust relationships required to respond to immediate threats have been formed. Such trust relationships are essential in the context of abuse response, as effective cooperative response may require information to be shared on a confidential basis.

28.1.11. Orphan Glue Records and Consistency Checking

Our Shared Registry System (SRS), will automatically delete host registration objects whose parent domains have been deleted. However, we can only act upon names controlled by UniRegistryʹs platform.

To address other forms of inconsistency, a number of processes will generate automatic notifications to the registrar when problems in the use of the existing information are detected.

For Lame Delegations (LD) detection -- that is, name server delegations to hosts that do not respond authoritatively for the delegating domain -- our SRS will perform periodic checks over the registered domains. Name servers will be queried and its response will be analyzed for correctness and in particular, to determine whether the host is responding authoritatively for the domain.

Another expected problem is the Inexistant Host (IH) -- name server hosts outside of the registered zone. Our SRS will attempt to resolve the name of each of the name servers periodically. When name resolution for the host fails, it is classified as an IH.

When LDs, IHs or other errors are identified, a message will be sent to the registrar so that actions can be taken.

After a sufficient time has elapsed with no resolution or indications from the registrar, the delegation will be marked as ʺincompleteʺ or ʺinaccurateʺ so that inconsistent or incorrect data is never published in the DNS. The amount of time to wait for action from the registrar is to be defined and reviewed periodically.

28.1.12. Registrar incentives ⁄ disincentives

Uniregistry will conduct an annual review of abuse incidents by registrar, and will impose the following incentives and sanctions.

Abuse Prevention Incentive Tiers
1. Registrars having responsibility for at least 1000 names will be awarded a discount of registration fees for the succeeding year for an abuse incidence of under .1%.

2. Registrars exceeding an abuse incidence of 10% and⁄or failure to timely respond to WDPRS reports within 15 days on more than 5% of total WDPRS reports, will be assessed a refundable surcharge for the succeeding year, provided that the succeeding yearʹs abuse incidence rate is reduced to below 1%.

3. Registrars with exceptional incidents over a shorter span of time than one year will be subject to temporary suspension until adequate assurances are received that such registrars will improve performance by taking materially demonstrable efforts to address any underlying systemic issue or problematic registrants.

4. Registrars exceeding an abuse incidence of 10% in two successive years will be de-accredited.

Uniregistry will adjust the relevant time periods thresholds and penalties associated with the incentives and disincentives in response to experience gained.

28.1.13. Registrant Security

Uniregistry will require registrars to provide multi-factor authentication from registrants to process update, transfers, and deletion requests, to publish and explain the registrarʹs security procedures for such multi-factor authentication on its website, and to notify all points of contact designated by the registrant for notification of update, transfers, and deletion requests. In the event a registrar is determined responsible for more than three incidents of domain misappropriation in a single calendar year, a surcharge will be assessed against all registrations for the succeeding year. In the succeeding year, if the incidence of domain misappropriation has not been reduced below three incidents, the registrar will be de-accredited.

28.1.14. APPENDIX A: UNIREGISTRY .HIPHOP ABUSE POLICY

The following definitions and procedures are to be incorporated into the terms of the Registry-Registrar Agreement (RRA), and by mandatory reference into the Registrant Agreement (including where Uniregistry or an affiliated entity acts as registrar for a subject Domain Name).

Uniregistry Abusive Use Policy

1. Definitions

ʺAbusive Useʺ shall include the following actions:(a) Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums; (b) Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;(c) Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;(d) Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses;(e) Fast flux hosting: Use of fast-flux techniques to disguise the location of Web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves;(f) Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);(g) Child endangerment, including the distribution of child pornography; and(h) Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).(i) Other: Uniregistry may update these definitions from time to time as new forms of abusive activity emerge or are identified, and in general to (1) protect the integrity and stability of the registry; (2) comply with government rules or requirements or inquiries by law enforcement; or (3) avoid or mitigate any liability, civil or criminal, on the part of Uniregistry, as well as its affiliates, subsidiaries, officers, directors, and employees

2. In General Uniregistry shall reserve the right, without obligation, to receive and investigate reports of abusive use of domain names, as defined above, and to to deny, cancel, suspend, or place any domain name(s) on registry lock, hold or similar status, upon reasonable evidence thereof.

3. Accredited Reporters Uniregistry recognizes that certain governmental and⁄or industry organizations possess expertise in collecting information in relation to particular forms of abusive use. Such organizations include the Anti-Phishing Working Group, Spamhaus, LegitScript, and others. Accordingly, reports from such organizations shall receive priority attention and action by Uniregistry. Uniregistry shall assign a non-published contact method (including email and telephone) and this contact method to such organizations by which reports may be submitted. Uniregistry shall maintain and publish contact information for such organizations on an abusive use reporting page by which members of the public may report suspected abusive use directly to Uniregistry, or opt to send their report to such established organizations for their review prior to reporting to Uniregistry. Uniregistry shall further maintain an application process by which such established organizations may obtain accredited reporter status. In particular relation to reports concerning child pornography, any report and recommendation received by Uniregistry from the National Center for Missing and Exploited Children (NCMEC) will be acted upon without review by Uniregistry. Likewise, Uniregistry will undertake no independent investigation of reports of child pornography from any source, but will forward such reports upon receipt to the NCMEC.

4. Procedure (a) Accredited Report Upon receipt of a report from an accredited reporter, Uniregistry will confirm receipt of the report to the reporter, review the report to determine that the subject Domain Name is registered via Uniregistry, and will notify the registrar of record for processing according to the applicable policy of the registrar. Uniregistry will proceed to take appropriate action in relation to the report without further notice, and confirm such action to the reporter.

(b) All other reports Upon receipt of a report from a non-accredited reporter, Uniregistry will confirm receipt of the report and provide the reporter with contact information of accredited reporters who accept reports of abusive use from the general public. Additionally, Uniregistry will forward the report to the registrar of record for processing according to the applicable policy of the registrar. Uniregistry will review the report and may proceed to take appropriate action in relation to the report if such action appears warranted. In the course of such review and⁄or action, Uniregistry may request additional information concerning the report and the identity of the reporter, and will further determine whether such action is to be confirmed to the reporter.

28.2. RESOURCING

Costs and procurement of the resources described here are detailed in response to Question 47.

28.2.1. Human Resources

See EXHIBIT: 28-Chart-Resourcing.png

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

Uniregistry maintains retainer relationships with two attorneys having extensive experience in internet matters, who will be responsible for reviewing and authorizing response to any abuse incident, report, or law enforcement or court action requiring legal review such as jurisdictional analysis. At any time, at least one of these attorneys shall be ʺon callʺ to immediately address such incidents as circumstances warrant.

28.3. ABOUT THIS RESPONSE

We believe that this answer meets the requirements and addresses all the points of this question:

* We have created a single point of contact for abuse reporting using any of several means (from telephone to text message to web) and in the languages supported by .HIPHOP. This point of contact is active and available 24x7.
* We have created enhanced means to handle reports and requests from law enforcement.
* We have a Registry Operations Center that will dispatch all incoming reports of abuse to our abuse management team.
* We have a structured response plan that tailors our response to the nature and exigency of the report.
* We have mechanisms to evaluate orphaned glue records and to remove them as needed.
* Our registration system incorporates technical mechanisms to put a name into suspension when warranted by our abuse policy.
* We have written policies regarding abuse and Whois accuracy.
We believe that this answer exceeds the requirements of this question:

* We require registrars (and indirectly require registrants) to provide and maintain accurate Whois information.
* We require registrars to participate in ICANNʹs WHOIS Data Problem Report System (WDPRS) and ICANNʹs WHOIS Data Reminder Policy (WDRP).
* We will perform validation tests on statistically meaningful samples of Whois data to look for inaccurate data.
* We use strong security methods to assure that registrar-registry interactions are authenticated and protected.

TABLE OF CONTENTS

29.1 RIGHTS PROTECTIONS
29.1.1 Pre-Launch Mechanisms
29.1.2 Post Launch Mechanisms and Services
29.2 RESOURCING
29.2.1 Human Resources
29.3 ABOUT THIS RESPONSE

 - - - - - 

29.1. RIGHTS PROTECTIONS

Uniregistry believes that a TLD thrives when its registrations provide reliable sources of information, goods and services from the registrants that have chosen to register domain names. Unauthorized domain name registrations corresponding to established trade or service marks, registered primarily for the purpose of confusing consumers, not only harm Internet users but they also harm the TLD itself, if the TLD becomes associated in the minds of consumers with unreliable, low quality or deceptive sources of information. 

We believe that holders of relevant rights in goods and services of which .HIPHOP is suggestive will value the opportunity provided by the .HIPHOP TLD to differentiate their goods and services in the marketplace.  However, we also strongly believe that rights protection mechanisms should not be a profit center for registries under which protection fees are extorted under the implied threat of cybersquatting by registrants in the TLD.  For those rights holders not interested in utilizing the .HIPHOP TLD, we offer a blocking alternative on a cost recovery basis for which we will welcome an independent audit.

The long term success of .HIPHOP, UniRegistry depends on rights protection mechanisms which deter infringing domain registrations and reduce costs to rights holders of enforcing their claims. UniRegistry has adopted the ICANN consensus policies and requirements of the Application Guidebook and Model Registry Agreement, and further proposes a minimal cost domain name dispute evaluation service to resolve most domain name disputes without escalation to dispute resolution proceedings. UniRegistry is committed to constantly reviewing and updating its rights protections mechanisms as industry best practices and domain registration strategies evolve, and has provided language in its Registrar Accreditation Agreement to give it the flexibility to add new processes and procedures should recurring issues occur which are not squarely addressed by existing mechanisms.

The proposal set forth in this response, meets or exceeds the requirements set forth in ICANNʹs Specification 7.

As a species of abusive behavior, rights violations and policies to address them are closely intertwined with the abuse response policies discussed in Question 28.  The suite of rights protection measures described here provide a complementary set of specific deterrents and remedies against unauthorized and malicious use of confusing or similar domain names for the purpose of deceiving end users. The policies and practices described in this response thus operate in the context of reduced opportunities for security attacks such as phishing, pharming and identity theft which include rights infringing domain names as a subset.

29.1.1. Pre-Launch Mechanisms

29.1.1.1. Sunrise Period

For a period of at least 60 days prior to general registration availability, Uniregistry shall engage in a two-part Sunrise Registration Period, during which rights holders desiring to use their mark in .HIPHOP may obtain either an Active Registration or a Blocking Registration.  This period may be extended at the time of actual delegation and launch, as launches of multiple TLDʹs in the future may require that relevant rights holders become aware of the various options open to them.

Blocking Registrations will be provided for those rights holders that may desire to prohibit registration of a second-level domain name corresponding to their mark, but may not desire to utilize the second-level domain name.  Blocking Registrations will be offered on a purely cost recovery basis, based upon the as-yet unknown terms of access to Trademark Clearinghouse data required to verify the application, and any fee assessed by ICANN for inclusion of the blocked name in the .HIPHOP zone.  While most rights holders will likely prefer to work through their existing digital rights management partners, including registrar-based providers of such services, we will further offer blocking registration availability directly through the registry, for any rights holders which manage their digital rights in-house or otherwise do not desire to incur additional costs or bundled services.  Blocking Registrations will confer a non-transferable non-convertible reservation of the corresponding second-level domain, which shall resolve to a content-free designated web page indicating that the domain name has been reserved under Sunrise.  The designated webpage serves the purpose of avoiding otherwise ʺnon resolvingʺ DNS responses from being diverted by Internet Service Providers to advertising material, as has become a common practice, and will simply indicate that the domain name is reserved according to Uniregistryʹs rights protection practices.

Active Registrations made during Sunrise will result in the registration of a resolving second-level domain name for a selected term of up to ten years, and will be offered on the identical commercial terms as registration of a domain name during general availability.  Applications for Active Registrations during Sunrise will be submitted through the rights claimantʹs registrar and will include any requisite verification token identifying the applicant as the claimant of the mark or its designated agent. 

To further reduce any costs to rights holders, Uniregistry will implement a ʺonce and for allʺ Sunrise registration program, under which a single Sunrise application will be made effective across all TLDâ€™s which Uniregistry ultimately operates, and which may designate active or blocking registration for each. Uniregistry will also encourage and cooperate in any industry wide program of similar effect.  There will be no geographic, class or trademark type restrictions against submission of either form of application (Active or Blocking) in relation to the mark claimed in the Trademark Clearinghouse record. Sunrise applications of either type will include an affirmation by the applicant that it is the owner or agent of the rights designated in the corresponding Trademark Clearinghouse record, that such rights are in use in relation to the goods and⁄or services claimed in connection with the mark, and that all provided information is true and correct.

All received application data will be verified against the corresponding Trademark Clearinghouse record. Notice will be provided to the applicant in the event of a failure to verify that the string corresponds to a Trademark Clearinghouse record or that the applicant corresponds to the owner or designated agent of the claimed rights. Verified applications will be accumulated during the Sunrise Period for conflict resolution or, in the event of no conflicting applications, entry into the TLD zone prior to general availability of the TLD. While the technical details of operation of the Trademark Clearinghouse have yet to be finalized by the relevant ICANN Working Group, Uniregistry will adapt to the mechanisms ultimately developed by the ongoing Working Group to effect the overall purpose of providing verification of Sunrise registrations.

For the purpose of correspondence rules between registered marks and domain names where the HIPHOP string is the terminal portion of the mark, Sunrise applicants will have the option of ʺspanning the dotʺ.. For example, a Sunrise application by a rights holder in ʺXYZ HIPHOPʺ will qualify for registration of both ʺXYZ.HIPHOPʺ and XYZHIPHOP.HIPHOP. In the case of ʺonce and for allʺ applications, the Sunrise applicant will qualify for XYZHIPHOP.TLD  in every other TLD which Uniregistry operates.

Conflicting applications, or Sunrise applications for the identical second-level string shall be resolved as follows. In the event of a conflict among one or more Blocking Registrations, and the absence of any applications for Active Registrations, the designated second-level domain name will be reserved from by the registry in any event, as there is no ʺconflictʺ in the event that multiple parties seek to block a name. Conflicting applications between at least one Active Registration and one or more Blocking Registrations shall result in assignment of the second-level domain name to the Active Registration applicant. In the event of conflicting Active Registrations for the identical second-level domain name, the applicants will be notified, provided an opportunity to agree to assignment of the domain name to any one of the Active Registration applicants and, in the event of non-agreement, shall be resolved by auction among the Active Registration applicants in an auction to be conducted by a third-party auction services provider. We believe that most conflicts among applicants for Active Registrations are likely to be resolved among the applicants themselves, since many owners of concurrent trademarks have agreements in relation to use of concurrent marks in various markets, and the variety of potential conflicts does not lend itself to an uniformly acceptable rule imposed by a TLD registry.

The WHOIS record for an Active Registration shall indicate that the second-level domain name has been registered under Sunrise, and shall indicate the jurisdiction, mark and registration number (for registered marks) or other mark-identifying data in the corresponding Trademark Clearinghouse record as follows. This record conforms to the requirements of Specification 10.

Domain Name: EXAMPLE.HIPHOP
Created On: dd-mm-yyyy hh:mm:ss UTC
Last Updated On: dd-mm-yyyy hh:mm:ss UTC
Expiration Date: dd-mm-yyyy
Trademark Name: EXAMPLE
Trademark Date: YYYY-MM-DD
Trademark Country: [country]
Trademark Number: [registration number]
Sponsoring Registrar: 
Status: 
Registrant ID:
Registrant Name:
Registrant Organization:
Registrant Street1:
Registrant Street2:
Registrant Street3:
Registrant City:
Registrant State⁄Province:
Registrant Postal Code:
Registrant Country
Registrant Phone:
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:
Admin ID:
Admin Name:
Admin Organization:
Admin Street1:
Admin Street2:
Admin Street3:
Admin City:
Admin State⁄Province:
Admin Postal Code:
Admin Country:
Admin Phone:
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:
Billing ID:
Billing Name:
Billing Organization:
Billing Street1:
Billing Street2:
Billing Street3:
Billing City:
Billing State⁄Province:
Billing Postal Code:
Billing Country:
Billing Phone:
Billing Phone Ext.:
Billing FAX:
Billing FAX Ext.:
Billing Email:
Tech ID:
Tech Name:
Tech Organization:
Tech Street1:
Tech Street2:
Tech Street3:
Tech City:
Tech State⁄Province:
Tech Postal Code:
Tech Country:
Tech Phone:
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:
Name Server:
Name Server:
Name Server:

The WHOIS Record for a Blocking Registration shall indicate that the second-level domain name has been reserved under Sunrise, shall indicate the jurisdiction, mark and registration number (for registered marks) or other mark-identifying data in the corresponding Trademark Clearinghouse record, and shall include designated name servers for resolution of the second-level domain name to a Domain Reservation Indication Page (DRIP). This record conforms to the requirements of Specification 10.

Domain Name: EXAMPLE.HIPHOP
Created On: dd-mm-yyyy hh:mm:ss UTC
Last Updated On: dd-mm-yyyy hh:mm:ss UTC
Expiration Date: dd-mm-yyyy
Trademark Name: EXAMPLE
Trademark Date: YYYY-MM-DD
Trademark Country: [country]
Trademark Number: [registration number]
Sponsoring Registrar: UniRegistry
Sunrise Reserved Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant Name: UniRegistry Sunrise Reserved
Registrant Organization:
Registrant Street1:
Registrant Street2:
Registrant Street3:
Registrant City:
Registrant State⁄Province:
Registrant Postal Code:
Registrant Country:
Registrant Phone:
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:
Admin ID:
Admin Name:
Admin Organization:
Admin Street1:
Admin Street2:
Admin Street3:
Admin City:
Admin State⁄Province:
Admin Postal Code:
Admin Country:
Admin Phone:
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:
Billing ID:
Billing Name:
Billing Organization:
Billing Street1:
Billing Street2:
Billing Street3:
Billing City:
Billing State⁄Province:
Billing Postal Code:
Billing Country:
Billing Phone:
Billing Phone Ext.:
Billing FAX:
Billing FAX Ext.:
Billing Email:
Tech ID:
Tech Name:
Tech Organization:
Tech Street1:
Tech Street2:
Tech Street3:
Tech City:
Tech State⁄Province:
Tech Postal Code:
Tech Country:
Tech Phone:
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:
Name Server: NS1.UNIREGISTRY.COM
Name Server: NS2.UNIREGISTRY.COM

The .HIPHOP TLD is likely to be particularly attractive in its primary market to individuals or groups, such as hip-hop performers or groups, who use their personal or professional names or a collective ʺstage nameʺ not constituting a trade or service mark per se.   Many such individuals or groups are additionally members of organizations which provide services or otherwise organize activities of such persons and groups in the field signified by the .HIPHOP TLD.  Prior to launch of the TLD, Uniregistry will engage in outreach with such organizations and otherwise obtain public lists of the personal or professional names of such individuals and groups for the purpose of reserving such names against registration at no cost charged to such organizations, individuals or groups of individuals.  These names will be rendered available for registration only by the identified parties, should they desire to utilize them, or remain on reserve in the event they do not desire to use them.  Uniregistry believes that by reserving the established names of those having such non-trademark personality rights will (a) significantly reduce the perception of an extortive dynamic of new TLD introduction, (b) increase the reliability of the .HIPHOP TLD for registrants and users, and (c) enhance the value of membership in organizations with which Uniregistry will cooperate in educating their members about the introduction of .HIPHOP and their members rights.   This reservation mechanism will also be preferable to operation of the .HIPHOP by a single such organization, which may itself compete with other relevant organizations in the field.


29.1.1.2. Sunrise Challenge

Second-level domain names registered or reserved as Active or Blocking registrations will remain subject to a Sunrise Challenge procedure. In the event that a consensus ICANN Sunrise Challenge procedure is adopted, Uniregistry shall comply with terms thereof. Otherwise, Uniregistry will implement a Sunrise Challenge procedure under which a challenger, whether a third party or the registry itself, shall allege that the Sunrise registration failed to conform to the requirements for entry into the Trademark Clearinghouse or was otherwise unqualified for the Sunrise Registration, or that the challenger of a Blocking Registration has independent rights to the second-level domain name. Grounds for such a challenge will include:

(1) at the time of the Respondentʹs registration of the Domain Name, no current (non-expired) trademark or service mark registration was issued in the Respondentʹs name; or

(2) the Domain Name does not correspond to the textual or word elements of the trademark or service mark registration in the manner required by the Sunrise Registration rules; or

(3) the trademark or service mark registration on which the registration of the Respondentʹs Domain Name is based is not of national effect; or

(4) the trademark or service mark has been invalidated, canceled, substantially unused or abandoned, or

(5) the trademark or service mark registration on which the registration of the Respondentʹs Domain Name was based did not issue prior to the cutoff date established by the Trademark Clearinghouse; or

(6) In the case of a Blocking Registration, the challenger possesses independent rights in a registered trademark of national or regional effect corresponding to the second-level domain name and intends to utilize the domain name.

The Challenge shall further indicate whether the the Respondent, which shall be the party having obtained the Sunrise registration, shall be notified and provided an opportunity to respond to the allegations of the challenger, and the dispute shall be resolved by a neutral dispute resolution provider.

It is anticipated that a standard Sunrise Challenge procedure will emerge from the ICANN new TLD program. To avoid a profusion of registry-specific rights procedures, Uniregistry shall adopt such standard procedure. If such procedure does not provide grounds for establishing independent rights in a Blocking Registration, Uniregistry shall implement a standalone procedure in coordination with an accredited dispute resolution provider to facilitate release of a Blocking Registrations to a challenger capable of establishing bona fide independent rights to use the string at issue, in order to address improvident, improper or abusive Blocking Registrations.

29.1.1.3. Trademark Claims Service

At the opening of general availability, Uniregistry will implement a Trademark Claims Service (TCS). The terms of access to the Trademark Clearinghouse have not been determined as of the date of this application. Uniregistry believes the Trademark Claims Service need not be restricted to the minimum requirement of 60 days post-launch, and will continue implementation of the Trademark Claims Service for as long as access to the Trademark Clearinghouse remains available.

Under the TCS, each registration for a second level domain name shall be checked against the Trademark Clearinghouse for an exact match string entry in the Trademark Clearinghouse. In the event a match is found, the prospective registrant will be provided with a Trademark Claims Notice identifying the trademark claimant, trademark claimed, and a link or other pointer to the underlying claim data constituting the Trademark Clearinghouse data record. Prior to proceeding to registration of the second level domain name, the prospective registrant will be required to affirmatively acknowledge:

(i) the prospective registrant has received notification that the mark(s) is included in the Clearinghouse;

(ii) the prospective registrant has received and understood the notice; and

(iii) to the best of the prospective registrantʹs knowledge, the registration and use of the requested domain name will not infringe on the rights that are the subject of the notice.

The terms of registration shall incorporate a provision under which the domain registrant shall not be entitled to claim lack of notice of the claim.

Should the prospective registrant proceed to registration of the domain name, a notice of such registration will be sent by email to the authorized contact identified in the Trademark Clearinghouse data record.

29.1.1.4. Domain Reservation or Suspension Indicator Pages

As noted above, Blocking Registrations will resolve to a designated content-free page, a Domain Reservation Indicator Page (DRIP) which readily indicates the status thereof to end users. Suspended domains are required by other policies, such as noted in the abuse response policies in Question 28, will require a online indicator, a Domain Suspension Indicator Page (DSIP). DRIPs and DSIPs will be operated using appropriate protocols so as to convey the required status message of the affected domains to the end user.

To facilitate this, UniRegistry will initially deploy a service platform providing DNS and generic web pages that will serve a simple template signaling the reservation or suspension status of such domain names.  At least two simple DNS and web servers will be provisioned at separate datacenters, so that the activity against those web servers does not affect the regular operations of the registry.  UniRegistry intends to run this service with a reliability in line with that of industry standard low cost web hosting providers.  In the event operational information indicates higher than anticipated performance requirements are appropriate, UniRegistry will implement performance improvements to protect the integrity of operation of DRIPs and DSIPs (i.e. to prevent hi-jacking or other methods ISPs or commercial DNS service providers may use to substitute other content in response to HTTP queries.

29.1.2. Post Launch Mechanisms and Services

The mechanisms and services described in the sections below have been designated as complements to the Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) in their most current versions. UniRegistry will adhere to the PDDRP and RRDRP.

29.1.2.1. String Watch Service

UniRegistry will offer a ʺwatch serviceʺ through which a subscriber may request notification of new registrations containing any pre-defined string of characters. This will allow rights holders of any type, whether trademark, copyright, rights of personality, or persons concerned in any other string of interest to them, to monitor the registration of words and phrases that may be important to them.

Watch Service Subscribers may establish an account, specify any string or strings of interest to them, and receive a periodic email notification at specified intervals, alerting them to the new registration of any second level domain name containing the identified string(s). This service is simply a notification service of new registrations and the right to use it is not predicated on any claim of right. Notification that a domain name has been registered with words or phrases contained in the Subscriberʹs string selections does not indicate that a domain name is or is not infringing on any legal right.

UniRegistry will perform commercially reasonable efforts to insure that email communications are being delivered. Additionally and depending on the effectiveness of the email as notification medium, other mechanisms may be designed and implemented, with consideration to the best interests of all the stakeholders.

29.1.2.2. Uniform Domain-Name Dispute-Resolution Policy (UDRP)

Uniregistry will require registrars to incorporate the UDRP into the terms of registration of second level domain names, just as all existing ICANN-accredited registrars already are required to do so by the ICANN Registrar Accreditation Agreement.

The UDRP, by its own terms, does not require registry involvement; however, UniRegistry is aware that occasional issues relating to registrar compliance with the UDRP have arisen, which typically have led to de-accreditation of registrars found in habitual non-compliance. Uniregistry will receive and act on any communications received from ICANN registrar compliance personnel indicating registrar non-compliance with the UDRP. In the event of a registrarʹs failure to comply with the conditions of the UDRP, and in the absence of factors such as litigation filed under UDRP 4(k) (under which names are not to be transferred upon filing of a court action in the UDRP Mutual Jurisdiction), Uniregistry will re-assign the domain name(s) in question to a compliant registrar with which the transferee has established an account, and may charge, suspend or de-accredit the non-compliant registrar in accordance with the schedule of incentives and penalties set forth in the response to Question 28.

29.1.2.3. Uniform Rapid Suspension (URS) And Personal⁄Professional Names

Uniregistry will require registrars to incorporate the Uniform Rapid Suspension System (URS) into the terms of registration of second level domain names. The URS requires that domain names subject to suspension will resolve to a designated web page until the domain name expires. Uniregistry will receive and respond to URS determinations by updating and locking the nameservers for a domain name subject to suspension to designated servers which will resolve the domain name to the requisite web page indicating that the domain name has been suspended (or other terminal status the URS, subject to ICANN Consensus Policy or Board action may require).

Uniregistry will receive and act on any communications received from ICANN registrar compliance personnel indicating registrar non-compliance with the URS. In the event of registrar failure to comply with the conditions of the URS and in the absence of factors such as litigation filed in a competent jurisdiction (under which names are not to be disabled upon filing of a court action in the URS Mutual Jurisdiction), Uniregistry will re-assign the domain name(s) in question to a compliant registrar, and may charge, suspend or de-accredit the non-compliant registrar in accordance with the graduated penalties discussed in the response to Question 28.

At present, ICANN has projected a cost of US $300 for URS disputes.  However, no presently ICANN-accredited dispute resolution provider has confirmed that it can provide URS services at that price.   In the event that ICANN-accredited dispute resolution providers cannot provide URS services in the indicated price range, Uniregistry will contract with a URS provider in consultation with leading experts in domain dispute procedures, which can provide competent determinations of the type of clear violations which the URS is intended to address, to ensure a low cost advisory, mediation or suspension mechanism.

Because the .HIPHOP TLD is likely to be particularly attractive to individuals or groups, such as hip-hop performers or groups, who use their personal or professional names or a collective ʺstage nameʺ, it may also attract abusive registrants seeking to exploit or damage the reputation of such individuals, and whose names were not identified in the pre-launch reservation process described above.  Accordingly, whether in conjunction with the alternative URS procedure described above or as a standalone mechanism, Uniregistry will establish a personality rights resolution policy operating on a similar basis as the URS to address complaints in which a complainant may obtain transfer or blocking of a domain name under circumstances in which:

A.  the complainant is a natural person, or collective group of natural persons or the authorized representative or agent of a natural person or collective group of natural persons; and

B.    the disputed domain name substantiallyy corresponds to the personal, professional or ʺstage nameʺ of the complainant, or name by which the complainant is commonly known in the field signified by the TLD; and

C.    the disputed domain name has been registered with an unlawful intent or for the purpose of exploitation, harassment or embarrassment in relation to the complainant absent any apparent defense of legitimate fair use, that the registration of the domain name is coincidental, or that the domain name was otherwise legitimately registered for purposes relating to a fictional name or character or personal, professional or other name in bona fide use by the registrant thereof apart from registration of the domain name.


29.1.2.4. Trade or Service Mark Litigation

In the event of litigation involving a second level domain name and to which Uniregistry is named as a party, Uniregistry shall retain the right to present all claims and defenses available to it. Uniregistry will generally seek dismissal as a party, as litigation involving an alleged infringing name are properly brought between the claimant and the registered name holder.

Uniregistry will implement orders of the courts of its charter jurisdiction directing registry action to be taken in relation to a domain name. Uniregistry shall further maintain an agent for the purpose of service of process in the United States, and will comply with orders of the courts directing registry action in relation to a domain name. In the event of litigation under the United States Anti-Cybersquatting Protection Act, Uniregistry shall submit a certificate of control to the court, by which the court may direct disposition of the domain name. Uniregistry will implement such orders to the extent that Uniregistry is not itself a party to the litigation or court action in question. In all other instances, Uniregistry will retain its full legal rights to defend, settle or otherwise resolve the litigation or court action.

In the event of litigation arising in the Mutual Jurisdiction specified in the UDRP or the URS, Uniregistry will lock the subject domain name and maintain such lock until Uniregistry receives notice of a decision or dismissal by the court.

For all other court proceedings brought in relation to a domain name of which Uniregistry receives notice, the subject domain name(s) will be locked pending resolution of the proceedings in all instances where the court is of competent jurisdiction over (a) the registrant, (b) the registrar, or (c) which is otherwise served in Uniregistryʹs charter jurisdiction or upon Uniregistryʹs agent for service of process in the United States.

29.1.2.5. Criminal Infringement Matters

Uniregistry will receive service of any warrant, subpoena, seizure order or equivalent directive served in Uniregistryʹs charter jurisdiction, or upon Uniregistryʹs agents for service of process in the United States and the United Kingdom. Uniregistry shall reserve all its rights and defenses for any matter in which Uniregistry is named as a defendant or subject of criminal allegation.

29.1.2.6. Additional IP Investigational⁄Mitigation Tools

29.1.2.6.1. Zone File Access

As referenced elsewhere in the application, Uniregistry shall make the HIPHOP zone file available to third parties under the zone file access agreement. This access may be utilized by, for example, commercial providers of registration watch services available to the intellectual property enforcement community.

29.1.2.6.2. Searchable WHOIS

Under the UDRP and other intellectual property rights enforcement mechanisms, claimants may rely on evidence of patterns of registration, but such patterns have been difficult to investigate. The Searchable WHOIS described in connection with Question 28 of the application provides an additional investigational tool by which claimants may determine whether a registrant is engaged in a pattern of cybesquattting

29.1.2.6.3. WHOIS Integrity

Cybersquatting is frequently associated with fictitious or incomplete WHOIS data. As described in connection with Question 28 of the application, Uniregistry will subject WHOIS data to regular integrity checks after registration of domain names or changes to WHOIS data. Uniregistry will require registrars to receive and to act on reports from the WHOIS Data Problem Report System. In the event that Uniregistry receives communications from ICANN or from third-party reporters indicating registrar failure to receive and act on such reports, Uniregistry will investigate the underlying record and registrar non-compliance, and may suspend or cancel the domain name, and may sanction the registrar according to the schedule of graduated penalties proposed in our response to Question 28 in the event that non-compliance is found.

29.1.2.6.4. Abuse Reporting Point of Contact

The abuse reporting system and processes described in the response to Question 28 will include, as an abuse category, intellectual property or other rights infringement. Reports of intellectual property infringement will be forwarded to the relevant registrar and the registrant identified in the WHOIS data. The abuse reporting form will further include pointers to rights enforcement mechanisms including the UDRP, URS, and WHOIS Data Problem Reporting System.

29.2. RESOURCING

Costs and procurement of the resources described here are detailed in response to Question 47.

29.2.1. Human Resources

See EXHIBIT: ʺ29-Chart-Resourcing.pngʺ for information in the human resources assignment.

The resourcing plan specific to this response follows the principles, guidelines and information set forth in our response to Question 23.

The accompanying chart shows the human resources allocated to the functions depicted in this response.

Uniregistry maintains retainer relationships with two attorneys having extensive experience in internet matters, who will be responsible for reviewing and authorizing response to any incident, report, or law enforcement or court action requiring legal review such as jurisdictional analysis. At any time, at least one of these attorneys shall be ʺon callʺ to immediately address such incidents as circumstances warrant. 

29.3. ABOUT THIS RESPONSE

We believe that this answer meets the requirements and addresses all the points of this question:

* We have described how we will implement safeguards against unqualified registrations.
* We will offer both a Sunrise period and a Trademark Claims service
* We implement the URS.
* We implement means to support the UDRP and other dispute mechanisms (such as litigation.)
* We have the contractual vehicles to require compliance by registrars and, indirectly, by registrants.
* These measures are all integrated into our operational and technical designs, procedures, and operations.

We believe that this answer exceeds the requirements of this question:

* We have built rights protection into the core of our systems, procedures, contracts, and operations.
* We provide registrants with tools to monitor for potentially improper registrations.
* We have detailed procedures to suspend or take down names.
* The suite of rights management protections goes significantly beyond the minimum that is required.

TABLE OF CONTENTS

30(a).1 REGISTRY SECURITY POLICY: SUMMARY
30(a).1.1 Physical Security
30(a).1.2 System Security
30(a).1.3 Network Security
30(a).1.4 Service Security
30(a).1.5 Data Security
30(a).1.6 Security Monitoring
30(a).1.7 Attack Mitigation
30(a).1.8 Personnel Policies
30(a).1.9 Security Incident Response
30(a).2 INDEPENDENT ASSESSMENT ON SECURITY CONTROLS
30(a).3 ABOUT THIS RESPONSE

- - - - -

30(A).1. REGISTRY SECURITY POLICY: SUMMARY

In order to provide end-to-end privacy and security, the Registry Service is built in accordance with recognized best practices in architectural and operational security, providing security at each level in the design and deployment. Confidentiality, integrity, and availability of registry data is of the utmost importance to us. We intend to maintain user trust and confidence.

Our Registry commits to its registrants that:
* their registration information will always be kept appropriately secure according to ICANN policy,
* that reliable global DNS service will always resolve the registered names, and
* that all changes to registration will be properly authenticated.
To meet these promises, we have minimum threshold levels of physical, network, system, service, and data security. The policies summarized here outline the thought and principles behind our security.

In broad terms, the ISC Registry Security Policy begins with the provision of multi-layered ʺDefense In Depthʺ for every element of the Registry, including:

* Physical Security
* Network Security
* System Security
* Service Security
* Data Security
Augmenting these defenses are mechanisms to detect Security Events, including:

* Centralized Logging and Log Analysis
* Network Aberration Alerting
* System Integrity Analysis
Our systems are highly redundant and are architecturally arranged to limit the effect of security events.

Should a Security Event occur, a set of Attack Mitigation mechanisms will be triggered.

For purposes of data recovery, forensic reconstruction, and event analysis we maintain deep backup, transaction journals, and audit trails.

We have a formal Security Incident Response Plan in place to resolve each incident. We subsequently review and evaluate our response to learn where we can make improvements

This TLD string does not require elevated or specialized security levels which are specific to and expected of financial and high security TLDs.
30(a).1.1. Physical Security

All registry servers are housed in carrier grade, first-tier dedicated data center spaces that are secured and monitored 24x7 by the data center vendor (by video surveillance and⁄or by guard patrols). Access is secured by an access control list, and requires a biometric scan (hand or retina) for entry. Only our own staff members are permitted to have physical access to the equipment hosted in these facilities.

Our contracts with data center vendors must all require that we be quickly notified if there is suspicious activity or an event that affects our equipment or networks.

30(a).1.2. System Security

The computer systems used by both Registry Services and SNS are enterprise-class servers running an appropriate operating system software. Maintenance of these systems follows industry standard best practices, including regular security updates, configuration management, and backups. Configuration requirements include running only the minimal set of services that are required, local firewalling, and per-user change tracking. Remote administration of the systems is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only ISC employees may have any form of access (physical or administrative) to Registry systems.

The computer systems used by both Registry Services and SNS use operating systems and applications software that have a high resistance to computer viruses or ʺrootkitsʺ.

Business office systems, which are more vulnerable, are protected by industry best practice anti-virus tools as well as by procedures to reduce system exposure or limit the introduction of viruses.

30(a).1.3. Network Security

The network elements used by Registry Services are carrier-grade routers, switches, and load balancers. These elements are hardened against attack according to industry and ISC best practices. They are managed by expert certified network administrators. Configuration data is replicated and archived centrally. Changes are logged per user. Remote administration of the network elements is done by a limited set of authorized staff, using secure channels with limited points of network ingress. Only ISC employees or carefully-vetted contractors can have any form of access (physical or administrative) to Registry systems. In case of emergency, police and fire officers may be permitted access, duly documented and monitored by the data center staff.

In addition to securing the network elements themselves, dedicated or embedded firewalling capabilities are used to ensure that only authorized and appropriate network traffic reaches the registry systems. Should elevated or atypical network traffic be detected, appropriate notifications will be made to the monitoring system. Every system is monitored, and all monitoring data is centrally gathered and logged.

30(a).1.4. Service Security

Access to the SRS service is permitted only to those registrars that have current signed agreements with the TLD operator. Registrars will provide a list of IP addresses to be permitted to connect to the EPP servers. No connections are permitted from unauthorized client addresses. In addition the system uses SSL-based certificates to establish secure TCP connections, allowing the client and the server to authenticate one another, before supplying a mandatory user⁄password combination to authenticate an EPP session.

Services that are exposed to the Internet such as Whois, and DNS, are designed and deployed with secure techniques that prevent data from unauthorized alteration.

Tiered access services, such as the RESTful Whois interface, use SSL encryption for transmission of all sensitive information, such as passwords, or privileged information.

30(a).1.5. Data Security

While the DNS zones created by the registry from registrantsʹ submissions are publicly visible data, a need might evolve to keep some data private. Our system is ready for this eventuality. All data (whether private or not) is secured during network communication by end to end encryption. The integrity of public DNS data is ensured through the use of cryptographic shared secrets for all internal transfers. Once on the servers, regular backups are made to ensure no data is lost, and copies of backups are replicated to geographically distant data centers. Backups are encrypted, and copies of those encrypted backups will be in secure locations.

30(a).1.6. Security Monitoring

Despite security-oriented design and hardening, it is inevitable that any service provided on the Internet will receive unwanted traffic. It is critical that the SNS and Registry systems be able to detect anomalous traffic, and to correlate events across multiple elements to alert operators and provide key data to differentiate between increased benign traffic and a true attack. The SNS and Registry systems perform this functionality via centralized logging and analysis, detection of anomalous traffic by the network elements, and application-specific alerts. Additionally, all servers are regularly scanned for unauthorized code, and the entire system is periodically swept with network scans. The Registry Operations Center is responsible for determining the frequency of such scans and sweeps, but never less frequent than once per calendar quarter.

All security information is received by, and distributed by (as needed), the help desk⁄call center and the Registry Operations Center. Any distribution of security-related information outside Uniregistry must be via Uniregistry corporate management and not by any operations personnel except with explicit per-case specific approval by corporate management.

30(a).1.7. Attack Mitigation

Industry best practices are used to mitigate the effect of any attack. Such mitigation includes topological containment of the attack (isolating it to some portion of the network) and service continuity using alternate servers or sites.

Significant overprovisioning, load balancing, and firewalls are used to dilute, divert, and deflect the force of brute force attacks. Anycast routing limits the scope of attacks on our name server infrastructure.

30(a).1.8. Personnel Policies

Registry operations personnel are all subject to background checks.

Job duties are arranged, and supported by data⁄system access constraints, so that no person has more access than is needed for the performance of their job duties.

We will have an employee handbook that will define employee duties and obligations. Employees will have to assent, in writing, to that handbook at least once a year.

Consultants, contractors, and other third parties will be required to enter into an appropriate Non Disclosure Agreement that will define their duties and limitations.

30(a).1.9. Security Incident Response

Should a Security Event be detected or reported, the Registry System Security Response Plan will be triggered. This plan defines formal roles for staff, a process for technical analysis of the event, proper communications procedures and event resolution.

30(A).2. INDEPENDENT ASSESSMENT ON SECURITY CONTROLS

Uniregistry has built its platform, policies and procedures following industry best practices and sound commercial guidelines to ensure the highest levels of commercially reasonable security. This encompasses as a minimum: Physical Security, System Security, Network Security, Service Security and Data Security. The fact that Uniregistry is beginning as a registry operator with a clean slate allows for the application of best-practice policies and controls from day one.

That said (and regardless of the level of preparedness shown in the design and implementation of our policies and security controls), it is impossible for any newly formed entity beginning its duties as a registry operator to present an effective, meaningful and Independent Assessment of the effectiveness of security controls; as this is an area that needs to be evaluated on a day to day basis - based on operations which in Uniregistryʹs case, have not yet begun.

30(A).3. ABOUT THIS RESPONSE

This answer is extended in our answer to question 30b.

Frank Taylor Schilling	Managing Director
Michele Ann Schilling	Secretary
Ryan David Smith	Chief Technology Officer

Bret Alan Samuel Fausett	President, Internet Pro APC
John Bruce Berryhill	Principal, Berryhill LLC
Martin Lewis Heimbigner, Jr.	Partner, Tatum LLC
Vernon Michael Jurovich	President, Proforma Inc.

New gTLD Application Submitted to ICANN by: Uniregistry, Corp.

String: hiphop

Originally Posted: 13 June 2012

Application ID: 1-855-7383

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.