Application number: 1-994-3470 for Minds + Machines GmbH

Minds + Machines GmbH

Potsdamer Platz 10
Berlin 10785
DE

+49 30300114802

+49 30300114520 

http:⁄⁄www.mindsandmachines.de

Antony Van Couvering

CEO

+1 9174067126

tas.minds.machines.3@gmail.com

Elaine Pruis

CTO

+1 5098993161

elainepruis@gmail.com

Gesellschaft mit beschränkter Haftung

Amtsgericht Registergericht Charlottenburg, Deutschland

Not Available

Top Level Domain Holdings, Ltd

Antony Van Couvering
Geschäftsführer
Caspar von Veltheim
Geschäftsführer

Caspar von Veltheim
Geschäftsführer
Top Level Domain Holdings, Ltd
Not Applicable

nrw

Not Available

The Minds + Machines GmbH (and Knipp Medien und Kommunikation GmbH as its technical provider) ensured that there are no known operational or rendering problems concerning the applied-for gTLD string ʺnrwʺ.
Since the gTLD string ʺnrwʺ is an ASCII-only string, it is safe to assume that, just like with existing ASCII-only TLD strings like .com, .net or .de, no operational or rendering problems may be expected. In particular, the name consists only of ASCII characters that are already used for existing top level domains; all the characters in the name are even used in the leftmost position of existing TLD labels. In order to confirm this, Knipp Medien und Kommunikation GmbH conducted a thorough research regarding whether operational or rendering issues occurred for any existing ASCII-only top level domain in the past. The results of this research confirmed the assumption.
Since the registry does not support right-to-left scripts on the second level, bi-directional issues (like the ones described at http:⁄⁄stupid.domain.name⁄node⁄683) will not occur.
Moreover, the gTLD string exclusively uses characters from a single alphabet, does not contain digits or hyphens, and it contains characters that are not subject to homograph issues, which means there is no potential for confusion with regard to the rendering of other TLD strings.
Finally, Knipp Medien und Kommunikation GmbH set up a testing environment for the .nrw TLD using the TANGO Registration System, including an EPP SRS, Whois and DNS servers, in order to conduct a series of tests involving typical use cases (like web site operation and e-mail messaging) for a TLD. The tests revealed no operational or rendering issues with any popular software (web browsers, e-mail clients) or operating systems.

Mission
The Internet name space is becoming increasingly overcrowded and reasonable or relevant domain names for registrants and registrants’ businesses are scarce goods. Germany especially, as one of the healthiest economies worldwide, will profit from the expansion of the gTLD market, as the German ccTLD, .DE, is the most sought-after top-level domain of its kind (www.denic.de⁄en⁄background⁄statistics⁄international-domain-statistics⁄). Almost 15 million domain names are already registered under the .DE top-level domain, meaning most of the desired domain names are already registered or priced at levels unaffordable for most. The new geographic top-level domain .NRW for the German state of North Rhine-Westphalia will cater to the need for a stronger online presence of the region for the benefit of its population and businesses.
The goal of the .NRW top-level domain is to establish itself as the recognized choice for registrants who want to market and promote themselves and their websites to, and reach, the Internet-using public, for business, political, personal or any other purpose, through an association with the state of North Rhine-Westphalia; and, as the recognized top level domain name for Internet consumers to look for, to know which people, businesses, information sources or other online resource associates themselves with North Rhine-Westphalia or are trying to communicate with them.

DEMOGRAPHICS AND KEY FIGURES
North Rhine-Westphalia is the most populated and, at the same time, most densely populated state in Germany, with 17,8 million inhabitants. 36% of Germany’s large cities (29 out of 80) are located in the region of North Rhine-Westphalia. North Rhine-Westphalia has the highest GDP--543 billion in 2010--in Germany and therefore is one of the economic and industrial centers of the nation (http:⁄⁄www.nrwinvest.com⁄NRW_at_a_glance⁄index.php). This number accounts for more than 20% of Germany’s total GDP. North Rhine-Westphalia’s purchasing power also ranks amongst the highest in Germany, which makes it a highly desirable place for business (http:⁄⁄www.welt.de⁄wirtschaft⁄article13763660⁄Hier-leben-die-kaufkraeftigsten-Deutschen.html).

74,4% of North Rhine-Westphalia’s population (as of 2011) uses the internet on a regular basis, with a strong upward tendency, making a geographic top-level domain for the region, such as .NRW, ever more important (www.initiatived21.de⁄wp-content⁄uploads⁄2011⁄07⁄NOnliner2011.pdf).

PURPOSE & MISSION
The company aims to offer the people, businesses and organizations of North Rhine-Westphalia, as the most populated state in Germany, the chance to associate themselves, their products or services with North-Rhine Westphalia.

The specific purpose of the .NRW gTLD is to:

 - Provide all those interested, who are from or have any relation to North Rhine-Westphalia, with a convenient and recognizable domain name that associates them and⁄or their information with the state of North Rhine-Westphalia.

 - Provide all those interested, who are from or have any relation to North Rhine-Westphalia, a means of disseminating or seeking information about the issues, news, culture, lifestyle, entertainment, sports or any other topic having to do with North Rhine-Westphalia.

 - Assist all those interested, who are from or have any relation to North Rhine-Westphalia, in selling or purchasing goods or services of any kind, or providing information, with a convenient and recognizable domain name that associates them and⁄or their goods or services with North Rhine-Westphalia.

 - Provide a top-level domain name that provides an identifiable means of communicating with people, organizations and businesses that associate or identify with North Rhine-Westphalia.

 - Provide the Internet-using individual, who is from or has any relation to North Rhine-Westphalia, with an additional choice of available domain names at a competitive price.

The mission of .NRW is:

 - The promotion of North Rhine-Westphalia, its issues, causes, interests, perspectives, positions, policies, supporters and admirers by making domain names ending in .NRW available to all those who are from or have a relationship to North Rhine-Westphalia, who may want to use such .NRW domain names for their own political, business, personal or other legal purposes.

 - The promotion of North Rhine Westphalia by having information of any and all types and for any and all legal purposes available and disseminated from websites and email addresses ending in .NRW for the registrants’ and users’ own purposes having a relationship to North Rhine-Westphalia.

 - The promotion of North Rhine-Westphalia by allowing businesses, not-for-profits and individuals with a relationship to North Rhine-Westphalia to associate their products, services, information and selves with North Rhine-Westphalia.

 - To allow people and organizations from or with a relationship with North Rhine-Westphalia, to promote their association or identification with North Rhine-Westphalia on the Internet and in emails.

 - To provide an identifiable means for people, organizations and businesses from or with a relationship to North Rhine-Westphalia, to communicate with those who associate or identify with North Rhine-Westphalia.

 - To increase the number of people and organizations from or with a relationship to North Rhine-Westphalia that publicly identify themselves via the Internet with North Rhine-Westphalia through their use of .NRW domain names and email accounts by making such .NRW domain names affordable and readily available (subject to compliance with the rules governing .NRW discussed elsewhere in this Application).

PUBLIC BENEFIT
.NRW will be of high social and economic relevance for the region of North Rhine-Westphalia, and hence create value for the state’s strong economy and population. It will also provide transparency for Internet users about .NRW domain holders’ relationship to the state of North Rhine-Westphalia.

The .NRW top-level domain will create a common online identity for North Rhine-Westphalia and its metropolitan regions and large cities, whilst promoting the state in a positive manner. 

The implementation and operation of the .NRW top-level domain will take place in accordance and cooperation with government of North Rhine-Westphalia.

The government of North Rhine-Westphalia fully supports the implementation and operation of the .NRW top-level domain. The government, like us, strongly believes in the benefits of the .NRW top-level domain, for the population as well as the economy of North Rhine-Westphalia. Therefore the government endorses our application to manage and operate the .NRW top-level domain in all respects. The implementation of the .NRW top-level domain shall be carried out in close cooperation with the state of North Rhine-Westphalia.

REGISTRANT BENEFIT
Over the past decade, the market for domain name registrations has grown at a tremendous pace. From 2000 to 2010 domain name registrations increased from 40 million to 200 million domain names registered globally. 2011 experienced a growth of approximately 9%, significantly higher than the previous year’s 6% growth, ending third quarter 2011 with approximately 220 million domain names registered globally. Approximately 60% of these are gTLDs, while the remaining 40% are comprised of ccTLDs. More specifically, gTLD growth was approximately 8% in 2011, while ccTLD growth exceeded 11%.

Taking into account the new opportunities available with new gTLDs, growth is expected to continue in all sections of the domain name industry. It will allow registrants to reach more targeted audiences and increase their web presence. Additionally, it will allow registrants to more closely identify with a particular market segment.

Existing TLDs, such as .COM and .NET, do not provide adequate solutions for many registrants. Domain names that relate to the registrants’ business, interests, or associations are often already registered, priced exorbitantly high, or available options are unsuitable. Additionally, other options, such as ccTLDs, do not provide adequate alternatives, as a registrant may not have any geographic relation or meet the criteria associated with other gTLDs such as .MUSEUM or .AERO. Therefore, the only available opportunity to pursue a relevant and useful domain name registration may be through a brand new registration of a gTLD.

At present, no specific NRW domain name, or useful top-level alternative domain name, exists for the people, organizations and businesses that associate themselves with North Rhine-Westphalia, or people, organizations and business that want to communicate with them. Those wanting a domain name that indicates some level of association with or recognition of North Rhine-Westphalia could seek a second level domain name such as “.COM,” “.DE” or “.INFO,” but such domain (or similar names) are not readily available under the limited number of existing gTLDs, and more importantly only provide a secondary (at best) or weak (at worst) relationship between the domain name and North Rhine-Westphalia, which we believe would be the primary goal of registrants of such North Rhine-Westphalia-related names. From a competitive perspective, registrants that want a domain name that effectively and efficiently shows an association with North Rhine-Westphalia, or registrants that want a domain name that allows them to identifiably communicate with people who associate or identify with North Rhine-Westphalia, face a domain name marketplace that provides them with few if any options for their purposes. The .NRW top-level domain will resolve this problem by providing registrants with an efficient, effective, prominent, instantly understood way of showing their association with the state of North Rhine-Westphalia, and provide those registrants who desire it a domain that can effectively communicate information to Internet users in an identifiable way, while at the same time providing competition with the existing TLDs and new gTLDs that will be approved by ICANN, thereby increasing consumer choice.

We believe that the .NRW top-level domain will add significantly to the competition and differentiation in the top-level domain space, both for registrants and Internet consumers. With respect to competition, registrants are presently extremely limited in their choice of domain names that allow them to efficiently and effectively associate themselves with North Rhine-Westphalia. The availability of useful, effective, straight-forward domain names on existing top-level domains, such as .COM, .NET and .ORG, are few and far between, or may be for sale at prices that are out of reach for most. .NRW will allow registrants to obtain useful, effective, straight-forward domain names rather than be forced to purchase, for example, their fifth, sixth or even later choice .COM or .NET name, which may well barely relate to the registrant’s purpose or use of the domain name and⁄or may be confusingly similar with numerous other .COM or .NET domain names. In addition, some existing generic top-level domain names, though newer, such as .XXX, may be inappropriate for most registrants for content associational reasons, while country-code top-level domains, though numerous, are not useful or appropriate for many registrants for geographical associational reasons. Thus, .NRW will increase competition for registrants that are from or have a relationship to North Rhine-Westphalia who want a domain name that clearly, effectively and efficiently associates them with North Rhine-Westphalia for their domain name purposes as well as for those registrants who want to reach Internet users who identify with North Rhine-Westphalia.

.NRW will also increase pricing competition in the top-level domain name space by assuring that .NRW domain names are priced at levels that are appropriate to the vast majority of potential registrants to whom .NRW is targeted.

INTERNET USER BENEFIT
Internet consumers benefit from this increase in competition, as less confusing .NRW domain names will make it easier for them to know that the owner of the second-level domain name is from or with a relationship to North Rhine-Westphalia.

Likewise, .NRW will significantly help increase differentiation in the top-level domain space. Existing leading generic top-level domains names, such as .COM, .NET and .ORG no longer require and no longer represent any real differentiation in association, purpose or content. Newer top level domains, such as .XXX, .AERO and .MUSEUM, do represent differentiation, but are either inappropriate or unavailable to most prospective registrants at whom .NRW is targeted. .NRW will further increase differentiation by allowing registrants to be associated, and consumers to know that the registrant is associated with North Rhine-Westphalia.

The goal of .NRW is to provide users with a top-level domain name that easily allows them to recognize that the registrant seeks to have its second-level domain name (and content) associated with North Rhine-Westphalia. We believe this will be of substantial benefit to the Internet user community, as it will allow them to more easily and more readily understand the purpose or motives of the registrant’s website or email, allowing for better, more efficient and more effective use of their time online.

OUTREACH AND COMMUNICATIONS
Outreach to targeted potential registrants will be important to .NRW achieving its projected benefits by allowing it to cost-effectively and quickly market to the most likely potential registrants, and to promote the ways in which .NRW will allow them to associate themselves with the state of North Rhine-Westphalia, and how their association with .NRW helps further their interest and that of North Rhine Westphalia. To achieve this outreach, we intend to leverage our existing relationships with groups with an association with North Rhine-Westphalia, as well as engage in advertising, promotion, social media outreach, and other methods of reaching potential registrants, that are from have a relationship with North Rhine-Westphalia. .NRW believes that outreach to people and organizations that already identify with North Rhine-Westphalia will give it the best chance of launching the top-level domain as strongly as possible, giving it the best chance of long-term viability, and thus the best chance of providing its projected benefits to registrants of a positive association with North Rhine-Westphalia, while at the same time promoting North Rhine-Westphalia.

Communications will help .NRW keep in touch with its registrants, to understand how they would like to see .NRW develop, and to understand how we can improve our policies, registration rules, or other aspects of our operations or administration.

We plan to minimize social costs primarily through clearly written, widely disseminated, and easy-to-understand policies. Our Acceptable Use Policy clearly delineates unacceptable behavior and prohibited content by registrants using domain names in the .NRW zone.

This applicant, like most organizations, takes its good reputation seriously. We are fully cognizant, for example, that artistic, political, economic and social issues, all of which can be associated with .NRW, often provoke heated debate and are at times controversial. However, we recognize and support the free speech rights of both registrants and Internet users as fundamental rights, and believe that such free speech rights are important to the success of the .NRW business plan. We also acknowledge that any plan to stifle free speech would be more harmful to .NRW’s reputation and business success than any attempt by us to govern speech. That said, to protect .NRW’s reputation and the associational benefits it offers registrants and Internet consumers, we will actively promote and enforce our Acceptable Use and Abuse Prevention policies and procedures, which we believe will effectively combat improper or unlawful unprotected speech and online conduct. We believe that these mechanisms will be effective in assuring the reputation of the .NRW top-level domain, its registrants, and Internet Users, as well as the public.

The company will implement a registration policy for the .NRW top-level domain in the interest of the North Rhine-Westphalian population and its government. Only Internet users from or with a relationship to North Rhine-Westphalia (e.g. a place of business or residence) can register their own .NRW top-level domain. The .NRW top-level domain is targeted solely at the North Rhine-Westphalian business community and population. Nevertheless the registration procedure will be done in a transparent and non-discriminatory way.

This intention ensures the accomplishment of our goal to support the population, organizations and businesses of North Rhine-Westphalia. At the same time, Internet users will gain the certainty that the content, product or service offered on the website has a close relationship to North Rhine-Westphalia.

Another goal of .NRW in terms of user experience is to protect third-party rights and to prevent abusive uses. We intend to achieve this goal by crafting our Naming Policy, Acceptable Use Policy, and other policies to be readily understandable and easily accessible, and by making sure that our mechanisms for enforcing rights and preventing abuse (such as our Complaint Resolution Service) operate effectively, efficiently, and fairly, as well as by ensuring that they work symbiotically with other ICANN-mandated rights protection mechanisms such as the UDRP.

We have crafted a draft framework for registration of .NRW domains that fully support the goals, mission and purposes set forth above. Our draft registration framework is based on advice from ICANN, WIPO, applicable laws, and a variety of other expert sources. Specifically, the .NRW draft framework includes these interrelated sets of agreements setting forth our policies and regulations, all of which registrants must agree to be bound by:

- The Registrant Agreement, which registrars contracted with .NRW must present to registrants, is a collateral agreement to the Registrar Registry Agreement (detailed below), and will bind registrants to .NRW’s Acceptable Use Policy (as detailed below), .NRW’s Privacy & Whois Policy (detailed below), ICANN-mandated rights protection mechanisms (including the Universal Dispute Resolution Policy (“UDRP”), and the Complaint Resolution Service;
- The Acceptable Use Policy (“AUP”), which details the proper use of domain names that end in .NRW, which is incorporated by reference in the Registrant Agreement that registrants must agree to;
- The Privacy and Whois Policy, which describes how a registrant’s personal data is to be used, which is also incorporated by reference in the Registrant Agreement;
- The Registrar-Registry Agreement, which is the contract between .NRW and its ICANN-accredited registrars which sets forth, inter alia, the duties and obligations of the registrar with respect to .NRW registrants and the .NRW registry; and
- The Naming Policy, which sets out .NRW’s policies governing prohibited, blocked or reserved domain names.

These agreements and policies are designed to ensure transparent and non-discriminatory policies for the registration of .NRW names; fair and competitive pricing; protection of personal data and privacy; adherence by registrars and registrants to the AUP; protection of trademarks, the names of natural and legal persons and other property rights; prevention of the registration of illegal terms; and the prevention violations of the law. Moreover, our policies promote competition among registrars, combat abuse of the DNS, address cybercrime, protect intellectual property rights, and align the .NRW top-level domain with applicable regulatory and legislative environments and Internet registry best practices.

These policies will effectively support the key mission, purposes and goals of the .NRW top-level domain, which is to allow registrants that are from or have a relationship to North Rhine-Westphalia and who want to associate themselves with North Rhine-Westphalia, while at the same time protecting third-party rights and preventing abuse.

The .NRW top-level domain will be marketed to registrants that are from or have a relationship to North Rhine-Westphalia who want to associate themselves, their products, services, thoughts, ideas or anything else in a positive way with the .NRW, as well as to those who want to communicate with them in an easily identifiable way. Therefore, we believe that the great majority of registrants who apply for a .NRW domain name will do so because of its association with North Rhine-Westphalia or because they want to reach those who associate with North Rhine-Westphalia, and not for other reasons. In these ways, the .NRW top-level domain will bring a special association with North Rhine Westphalia to the top-level domain name space.

With respect to protecting registrant privacy and confidential information, we will comply with applicable ICANN rules, including Whois policies, and all applicable laws, rules and regulations of appropriate jurisdictions. Registrant privacy and use of confidential information are set forth in our Privacy & Whois Policy. Information concerning updates and changes to the Privacy & Whois Policy will be promptly and prominently displayed on the .NRW web site.

Our rules concerning applications for the same domain name establish clearly delineated rules, and will be published well in advance. They provide adequate safeguards for the rights of all participants as well as expeditious and cost-effective challenge procedures in the event of disputes.

During the Sunrise period and Landrush periods, multiple applications for the same name will be resolved by auction. UDRP or URS will be used if there are disputes as to rights to a name.

After Sunrise and Landrush, domain names will be allotted on a first-come, first-serve basis. All domains are subject to UDRP and URS challenges.

At all times, .NRW’s Complaint Resolution Service will be available to registrants as well as to the public in the case of alleged prohibited use or content.

.NRW does not envision special discounts for different classes of registrants, but may consider such offers in the future. We may offer introductory discounts for first-time registrants in .NRW. Bulk registration discounts are not being considered at this time.

.NRW plans to make contractual commitments to registrants regarding the magnitude of price increases. .NRW will contract with its registrars that any percentage increase in renewal and first registration fees will be applied uniformly across all registrations, and that notice of any price increases will be provided on the registrar’s website and by the registrar to registrants via email six months or more in advance.

.NRW’s back-end registry services provider will also be required to employ industry standard procedures to prevent the unauthorized or illegal access of registrant privacy or confidential information.

With respect to users, .NRW’s Registration Agreement will require that all registrants must comply with any and all applicable laws, rules or regulations concerning user privacy and confidential information for applicable jurisdictions, and that failure to do so may result in suspension or loss of their .NRW name, and may in addition result in legal actions by appropriate authorities.

No

Not Available

Yes

--PROPOSED MEASURES FOR PROTECTION OF GEOGRAPHIC NAMES AT THE SECOND AND OTHER LEVELS IN THE APPLIED-FOR GTLD--

We have accepted the advice of the Governmental Advisory Committee (GAC) that we should adopt appropriate procedures to block names with national or geographic significance at the second and other levels, and will do so in the manner described below:

The country and territory names contained in the following internationally recognized lists will be initially reserved at the second level, as follows:

The short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union; on the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and on the list of United Nations member states in the six official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

Procedurally, the geographical names contained in these lists, as described in Specification 5 of the New gTLD Agreement, will be added to the registry software system “prohibited word” function. This function, part of Espresso, our registry platform, allows strings to be blocked from registration. Upon an attempt via the EPP or web interface, the registration will not be allowed. Any attempt to register a domain containing those geographical names will be automatically denied, as they were similarly blocked in the .INFO TLD. If a Government or public authority decides to register a geographic name which has been blocked by the process describe above, the .INFO procedure for notice, authentication, and registration will be substantially adhered to, as follows:

 1. The Government or public authority concerned informs the GAC Secretariat of their request to register the name, and the designated beneficiary.
 2. The GAC Secretariat authenticates the request and transfers it to the ICANN staff and to the registry operator.
 3. The registry operator verifies the availability of the name and issues an authorization number that is transmitted directly to the designated beneficiary in the country concerned.
 4. The designated beneficiary (the Registrant) registers the name, paying the normal fee, with an ICANN-accredited registrar contracted with the registry operator using the authorization number as their authority.

The registry operator may at some point seek agreement with the applicable governments to release these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.

For protection of geographic names at other levels, we have a complaint mechanism in place and any geographic entity may register a complaint if they feel their national rights have been violated.

We believe that the measures outlined above incorporate GAC’s advice and serve as a pledge to block, at no cost to governments, geographically significant names and allow a means of challenging any abuse of the use of a geographically significant name.

1. Overview

Knipp Medien und Kommunikation GmbH will provide the technical registry services for the operations of the Minds + Machines GmbH. The TANGO Registration System offers the usual registry services for the .nrw TLD: Receipt of data from registrars concerning registration of domain names and name servers via EPP (SRS; see also answer to Question 24, SRS Performance); Dissemination of top-level domain (TLD) zone files (DNS; see also answer to Question 35, DNS service, configuration and operation of name servers); Dissemination of contact or other information concerning domain name registrations (port-43 Whois, web-based Whois; see also answer to Question 26, Whois service); Internationalised Domain Names (see also answer to Question 44, Support for Registering IDN domains); DNS Security Extensions (DNSSEC; see also answer to Question 43, DNSSEC). These services are introduced below. For more detailed descriptions, please refer to the answer to the respective question in the gTLD Applicant Guidebook. Additional benefits offered by the registry are full support for Internet Protocol version 6 (IPv6), data escrow, registrar reports and support for Sunrise and Landrush phases. All of these are compliant with the new gTLD requirements. No further registry services according to the definition in the gTLD Applicant Guidebook are offered for the .nrw TLD.

The Shared Registry System (SRS) is the central coordinating instance in the overall system concept. It is the authoritative source of the domain, host and contact data, provides client⁄server-based access methods for the registrars and internal personnel to this data, is responsible for the zone generation, performs accounting and reporting, and feeds the Whois servers.

The SRS is responsible for managing the domain registrations by accepting requests for the creation, update and deletion of domains and related information from the registrars, who act on behalf of the registrants.

The Knipp Medien und Kommunikation GmbH and its developers have ample experience in designing, developing and operating shared registry systems. The TANGO Registration System is compliant with established standards like Internet Engineering Task Force (IETF) Requests for Comments (RFCs) and can be customised for the specific needs of a top level domain, ensuring Internet Corporation for Assigned Names and Numbers (ICANN) gTLD standards compliance.

As a technical provider for CORE, Knipp is responsible for the technical operation of the .cat and .museum TLDs for the puntCAT and MuseDoma registries. Therefore, Knipp has the knowledge and experience that are necessary to provide the mentioned registry services. Since the software development is handled exclusively in-house, the .nrw Registry Services do not depend on any external companies or developers. Software development at Knipp is always based on principles like efficiency, scalability and security by design.


2. Infrastructure Design


2.1 Goals

The design of the Minds + Machines GmbH infrastructure achieves three goals:


2.1.1 High Availability

The resolution of domain names by the Domain Name System (DNS) infrastructure is the most critical part. If it fails, not only a large fraction of Internet users is affected, but other Internet infrastructure depends on the domain name resolution as well, causing a cascade of failures.

The shared registry system itself is also in the focus. While theoretically, a short outage would not have a direct and larger impact to the TLD users, a longer outage can become problematic, especially in the light of DNSSEC: If the registry is unable to re-sign the zone in time, the zone will become bogus and the effect will be similar to a failure of the whole DNS infrastructure.


2.1.2 Scalability

The aspects of scalability must be observed for two reasons: The infrastructure must grow with the demand; economic considerations let it seem unreasonable to launch with oversized hardware equipment. The software design must be able to cope with increasing demand, it must allow the long term upgrade of the infrastructure. Scalability must also be provided for unforeseeable load peaks. The infrastructure must be resilient and one step ahead; spare resources must be available.


2.1.3 Security

In an increasingly adverse environment, security is a cardinal goal. Various attack vectors need to be addressed. For example, the public infrastructure must be protected against pure (distributed) denial of service attacks and exploits of bugs in devices, operating systems and application software, and the SRS must be protected against intrusion by third parties with the intent of deletion or manipulation of data or stealing private keys used for DNSSEC.


2.2 Design Principles

The design principles that follow these goals are as follows:

* Shared Registry System (SRS)
** The SRS (actually all services except the name servers) is run on two sites, a primary and a secondary site. These sites are geographically separated for an event of force majeure that makes one of the sites unavailable.
** Fail-over strategies are used systematically, either by the software itself or by employing cluster technologies where applicable.
** Systematic data replication⁄backup⁄escrow is ensured.
** Modularisation of the software and avoidance of monolithic structures improves scalability and maintainability.
** Intrinsic support for multiple instances of software components to distribute load is guaranteed.
** State-of-the-art security technology reduces chances for attackers to a minimum.
** Some components like the Extensible Provisioning Protocol (EPP) interfaces may run in multiple instances. Incoming requests are distributed to these instances with the help of load balancers. Excluding instances one by one allows maintenance in respect to both hardware and software without interrupting the actual service.
* DNS Infrastructure
** Diversity in software and hardware increases security.
** Use of Anycast networks ensures high availability.


3. Features


3.1 Receipt of Data from Registrars

The SRS receives data from the registrars, writes the data into the database and passes on TLD zone files to the DNS services. The registry has a Whois function to make information about contacts and domain registrations available to the general public. DNS and Whois are updated dynamically. The registry TLD name servers receive DNSSEC-signed master zone data.

The .nrw TLD will be operated as a so-called ʺthickʺ registry, i.e. the data for domain registrants, administrative contacts, technical contacts and billing contacts is stored in the registry repository. Registry policy mandates that each domain must be associated with exactly four contacts, one contact of each type. In contrast to a ʺthinʺ registry (which doesnʹt store contact information), this allows the registry Whois service to provide contact information itself, i.e. it doesnʹt rely on registrars to operate their own Whois services for the inquiry of domain contact data.

Registrars can provide the data necessary for the registration of domains, contacts and name servers (hosts) in two ways. Firstly, using the EPP interface of the TANGO Registration System, which allows completely automatic processing of requests. Secondly, there is the option of using a password-protected web interface (ʺControl Panelʺ). The Control Panel offers copious amounts of information and many tools for registrars and registry administrators. Registry objects can be inquired and modified, creating new objects is possible just as easily. In addition, automatically generated reports for registrars are made available for download. Each report contains detailed information about the registry objects of the respective registrar. The Control Panel also allows the administration of registrars. Such administrative functions are of course limited to users belonging to the registry. These can also - their privileges permitting - inspect the tariffs and make corrective entries in the billing system.


3.2 Internationalised Domain Names

The TANGO Registration System supports internationalised domain names (IDN, see RFC 3490, 5890-5894) in several ways.

In the extensible provisioning protocol (EPP), there are various XML elements that expect a domain name. The EPP implementation of the TANGO Registration System accepts domain names in A-label notation (punycode) as well as in U-label notation (unicode). The former notation is preferred; all EPP responses use A-labels, even if the respective request used U-labels.

For more information about IDN support, please refer to the answer to Question 44, Support for Registering IDN Domains.


3.3 DNSSEC

Support of the DNSSEC extension according to RFC 5910 allows to specify the DNSKEY data. The TANGO Registration System calculates the delegation signer (DS) records from the DNSKEY data and adds them to the zone file. Further information about the DNSSEC implementation can be found in the answer to Question 43, DNSSEC.


3.4 IPv6 Support

The Minds + Machines GmbH infrastructure supports IPv6 on all levels: Firstly, the name servers use IPv6 addresses on the DNS protocol level (port 53), i.e. domain names can be resolved by using the IPv6 protocol. Secondly, the registry software is able to assign IPv6 addresses to in-zone hosts as provided in the EPP Host Mapping (RFC 5732) and to publish these addresses via AAAA records in the zone. Thirdly, registrars can connect to the registry by using the EPP transport protocol via IPv6. Fourthly, the Whois service (both port 43 and web interface) can be accessed via IPv6. Fifthly, the registrar web interface can be accessed via IPv6. Details about the IPv6 capabilities can be found in the answer to Question 36, IPv6 Reachability.


4. Zone Management

Whenever the authoritative data of a domain or host is altered, the change is forwarded to the DNS component and other components. Upon reception of this change, the DNS-specific database tables are updated. The structure of these tables directly corresponds to the structure of the zone file, so that the zone file can be generated with little effort.

The generated zone is then fed into the DNSSEC signing component. Since the zone changes only marginally between the runs, the signing component re-uses RRSIG signatures and NSEC3 name mappings from previous runs. This reduces the run time of the signing process by an order of magnitude on average.

In the next step, the zone is delivered to the ironDNS system, which manages the distribution of the zone to the name servers independently. For more details about this process, please refer to the answer to Question 35, DNS Service.

The whole process is covered by integrity checks. The zone is inspected by heuristic rules, for example, the change in size between the previous and new zone is determined and checked against limits. If there is any evidence that the zone may contain problems, the deployment process is halted and manual inspection by the support team is requested. Where applicable, the distribution is accompanied by safeguards, like cryptographic digests, to allow the detection of changes or truncations.


5. Whois service

The TANGO Registration System contains a public service that can be used to inquire data of registry objects (i.e. domains, contacts, hosts and registrars), the Registration Data Directory Services (RDDS). At the moment, this is implemented as a Whois service. Details regarding the Whois service can be found in the answer to Question 26, Whois service. Abuse of this service is effectively prevented, for details refer to the answer to Question 28, Abuse Prevention and Mitigation.


6. Escrow and Reports

The SRS also handles the monthly reports to ICANN and the generation of escrow files according to ICANNʹs specifications. The reports and escrow files are automatically sent to ICANN and the escrow provider, respectively.

As a technical provider for CORE Internet Council of Registrars, Knipp Medien und Kommunikation GmbH designed, developed and still operates ICANN-compliant escrow services as part of COREʹs shared registry system, which is used to supply registry backend services for the .museum and .cat registries. In this function, Knipp Medien und Kommunikation GmbH has continuously provided (and still provides) reliable registry data escrow services for these registries, helping CORE to be in full compliance with the escrow specifications of the respective ICANN registry agreements.

In the same fashion, Knipp Medien und Kommunikation GmbH also developed and still operates a system that produces registrar escrow files for COREʹs registrar activities, in full compliance with ICANNʹs RDE requirements.

Fully automated daily processes are in place that create the full or incremental XML escrow files as required, then split, sign and encrypt them according to the requirements from ICANN and the escrow agent, and finally transfer the resulting data to the escrow agentʹs server. The escrow files contain the main SRS data, zone data and RDDS⁄Whois data. Knipp Medien und Kommunikation GmbH as a vendor for CORE also provides access to full zone data for the .museum and .cat TLDs to eligible parties upon sign-up to this service. Access is granted to authenticated users via an SSL⁄TLS-secured web interface.

All registry agreements with ICANN require the registry operator to submit a monthly report about the registryʹs activities, inventory and performance to ICANN. Knippʹs registry system is able to create such a report containing (among other things) data about: domain⁄host inventory statistics, domain transfer statistics and domain renewal⁄deletion⁄restore statistics per registrar; service availability, outage durations and response times for SRS, DNS and Whois; Whois request statistics.

In addition, the following reports may be created for each registrar: Inventory report: domain, contact and host objects sponsored by the registrar on a specific date; Transfer report: transfers in progress, completed or rejected on a specific date; Autorenewal report: domains being automatically renewed on a specific date; Billing report: detailed information about every single billing operation that has been performed on the registrarʹs account (including refunds).


7. Support for Sunrise and Landrush Phases

A common problem that arises during the initial launch of a new top level domain (and, potentially, subsequently when new features like IDNs are introduced) is to ensure that trademark owners or otherwise eligible parties can claim their names in an organised manner that can be audited in case of legal disputes. To this end, registries usually offer a so-called ʺSunriseʺ phase, i.e. a certain period of time during which only eligible parties are allowed to register domain names. Eligibility has to be proved by providing information about a trademark related to the domain name, for example. Such additional information is provided by the registrars during registration of the domain name, with the help of a special EPP extension (see answer to Question 25, Extensible Provisioning Protocol, for details).

The validity of a Sunrise domain name application is checked by an external service provider, the so-called Trademark Clearinghouse. At the time of writing, ICANN has issued a request for information for providers to perform the Trademark Clearinghouse functions. It is envisaged that the TANGO Registration System will use a suitably defined interface of the Trademark Clearinghouse to submit requests according to the trademark data submitted by domain name applicants.

To facilitate the handling of Sunrise applications, the TANGO Registration System is equipped with a built-in issue system that offers registry personnel a convenient web interface to review domain name applications and to approve or reject them accordingly.

The issue system allows searching for applications by various criteria (e.g. domain name or current workflow⁄approval state). It offers a two-level review workflow that allows the delegation of pre-selection tasks to the first level support staff, after which a final decision - if still required - can be made by second level personnel. All application details, including registrant information and all supplied trademark information is conveniently displayed. The issue system fully tracks and documents application status and history, allowing for a complete audit in case of legal issues. Furthermore, it is fully integrated with the registry backend, i.e. it automatically notifies the SRS about the reviewersʹ decisions and immediately activates the respective domain in case of an approval.

The issue system was first used during puntCATʹs elaborate multi-phase Sunrise period in 2006 and proved to be an invaluable tool for efficiently organising a TLD roll-out process.

Another problem registries are facing, mostly during initial launch phases, is the unbiased allocation of domains in case of multiple competing valid applications for the same name. This is predominantly an issue during the so-called ʺLandrushʺ phase (i.e. the beginning of a TLDʹs general availability (GA) when anybody may register a domain), but it may also apply to Sunrise cases in which multiple applicants present valid trademarks or similar proof of eligibility.

In the past, many registries have chosen a simple first-come, first-served approach to handle these situations - the registrar who was able to submit the first registration request after the opening of the GA phase was awarded the name. However, this seemingly fair model not only puts an unnecessary load on the registryʹs server infrastructure, it also gives registrars an unfair advantage if their systems are located closer (in terms of network topology) to the registryʹs SRS. The system also encourages the creation of ʺpseudoʺ registrars just for the purpose of getting more parallel connections to the registry system for fast submission of as many requests as possible.

Consequently, Knipp suggests an alternative, auction-based approach for Landrush situations.

Knippʹs registry system provides the technical infrastructure required to conduct auctions for the assignment of domain names to the highest bidding registrant.

Its core component is an EPP extension that registrars may use to place a bid for a domain name and obtain information about the status of an auction they participate in (refer to the answer to Question 25, Extensible Provisioning Protocol, for more information).

The TANGO Registration System offers built-in support for Sunrise and Landrush phases. In the case of the Minds + Machines GmbH, both a Sunrise phase and a Landrush phase will be supported.


8. Domain Expiration and (Auto-)Renewal Policies

Domains are registered for a certain interval only. The possible intervals are multiples of a year. The system maintains a so-called ʺexpirationʺ date, which represents the date up to which the registrar has paid the fees for the respective domain. This date is also published on the public Whois servers and is included in reports generated for the registrars.

Domains must be registered at least for a year. The registration period can be extended at any time by issuing a ʺrenewʺ request to the registry. However, the resulting expiration date must be not beyond 10 full years in the future.

Since usually the registrars use the same intervals for their customers, there is always the problem that some customers make up their decisions whether to keep a domain or to delete it at the very end of the registration term. To accommodate the registrars with this problem, it is common practice among the registries to grant a so-called grace period, which starts at the expiration date. During this 45 day period, the registrar may delete the domain without paying any fees for the already started next term. If after 45 days the domain has neither been deleted nor renewed by the registrar, the registry itself automatically renews the domain by one year.


9. Billing

The registry maintains an account for each registrar. All registrations, transfers, renewals and other billable operations have to be prepaid, and corresponding fees are deducted from the registrarʹs account.

Whenever a billable operation is attempted, the registrarʹs account is first checked for sufficient funds. If the account is lacking the required funds, the operation is rejected. A corresponding result code is returned if the rejection affects a realtime EPP command, as opposed to e.g. an internal autorenew operation that was not directly triggered by a registrar command. However, the autorenewal of expired domains is treated differently; to avoid accidental domain deletions, autorenewals are continued even in case of insufficient registrar funds. Non-billable operations (like all read-only commands) and activities that trigger refunds are always executed, regardless of the registrarʹs account balance.

If sufficient funds are available, the operation is executed and the registrarʹs account is charged with the corresponding fee (if the operation was completed successfully).

Each registrar may provide an account balance threshold value. The billing subsystem will automatically send an e-mail containing a ʺlow account balance warningʺ to the registrar whenever the registrarʹs funds drop below the configured threshold value.

Some commands, like domain deletions or transfer cancellations, result in refunds if corresponding grace periods apply. The affected registrarʹs account is immediately credited for each refund.

The billing subsystem utilises its own database, containing tables for registrar accounts (including current balance and warning threshold), tariffs for billable operations along with their validity periods and book entries (each one representing a single credit or debit).

The SRS component responsible for actual registry operation communicates with the billing component. Any billable or refundable event (such as domain creation, domain deletion within grace period, request for domain transfer, domain renewal or autorenewal) results in the lookup of a suitable tariff in the tariff table, the creation of a corresponding record in the book entry table and the update of the registrarʹs account.

The entire implementation is carefully designed to ensure billing accuracy. The checking for sufficient funds as well as the processing of book entries representing the billable events are always done within the same database transaction that performs the actual billable repository change, thus ensuring transactional integrity and account consistency.


10. OT+E and Staging Environment

In addition to the production registry system, Knipp Medien und Kommunikation GmbH provides an independent Operational Test and Evaluation (OT+E) system to give registrars the opportunity to develop and test their client software in a self-contained ʺsandboxʺ environment that does not interfere with production business.

The OT+E system emulates the behaviour of the production system as closely as possible to allow for realistic testing. It also includes a Whois server, as well as a name server fed from the sandbox data, which facilitates the testing of transfer policy and DNSSEC implementations on the registrar side, respectively.

The OT+E system differs, however, from the production system in some respects to further simplify development for the registrars: Firstly, each registrar is granted two independent identities on the OT+E system. This enables each registrar to test domain transfers easily by creating domains with the first identity and transferring them to the second identity (or vice versa). Secondly, to allow short turnaround times for registrars during their tests, most of the periods and deadlines used by the production system are significantly shortened (or entirely disabled) on the OT+E system. For example, the OT+E system – contrary to the production SRS – uses an Add Grace Period shorter than 5 days to allow registrars to test domain name redemption more easily.

Apart from the mentioned differences, the OT+E system will always run the exact same software as the production system. Both systems are updated at the same time whenever a new release is deployed.

To facilitate a smooth roll-out of major software upgrades, especially those that involve protocol or policy changes requiring changes to client systems, a separate so-called ʺStagingʺ system is operated, on which these new software versions are deployed with appropriate lead time before the same changes are applied to the production and OT+E systems. The actual lead time depends on the nature and the extent of the changes involved.

The SRS is routinely adapted to improved standards and to cope with new technical, capacity and organisational demands.

Knipp Medien und Kommunikation GmbH has gained a lot of experience as the main contractor working on the CORE Registration System for CORE Internet Council of Registrars. This system is a unified registration system for members of CORE, granting access to a multitude of top-level domain registries, currently including .com, .net, .org, .info, .biz, .name, .us, .asia, .eu, .coop and .tel domains, via a single entry point. The activities for CORE provide Knipp with a great deal of expertise and know-how regarding the implementation, operation, maintenance and support of a shared registration system, facing a very heterogeneous user group regarding location, language, enterprise size and structure. The TANGO Registration System has been developed by Knipp with peculiarities of the new gTLDs in mind.

Knipp as a vendor for CORE is also handling the technical operation of the .cat and .museum TLDs on behalf of the puntCAT and MuseDoma registries. This proves that Knipp has the knowledge and experience necessary to provide the offered registry services.


1. High-Level System Description

The Shared Registry System for the Minds + Machines GmbH is a local installation of the TANGO Registration System, developed by Knipp. Consequently, the SRS is compliant with the various relevant standards for EPP (s. Question 25), Whois (s. Question 26), DNS (s. Question 35), DNSSEC (s. Question 43) and IDNs (s. Question 44).

Each registry service is handled by its own server. Overall, the services are set up ensuring n+1 redundancy. It is envisaged that further frontends will be added later, when increasing system usage requires such a step.


1.1 Multiple sites

The Minds + Machines GmbH as a whole is distributed among a set of independent sites. Besides the geographical diversity of the sites, each site is designed to be independent of other sites. A complete failure of one site or of related infrastructure (i.e. upstream providers) does not affect the operation of the others. No networks or vital base services (like DNS resolvers, LDAP or SMTP servers) are shared among the sites.

For the main registry operation, i.e. all services except the name servers, two sites are designated, the primary one in Dortmund, Germany and the secondary one in Amsterdam, the Netherlands. Name servers, as far as operated by the Minds + Machines GmbH itself, are located on other sites. Other name servers operated by contractors can be seen to be operated on other sites as well in this context.

To support scalability of the system, the SRS is modularised into components where possible. Components are allowed to run on different machines, so that the overall load of the system can be distributed hardware-wise. This approach also improves the efficiency of cluster technologies and fail-over strategies within a site.

Some components, for example the EPP interfaces to the registrars, are allowed to run in multiple instances if necessary. With the help of load balancers, the incoming requests are distributed to these instances. By directing the load balancers to exclude an instance, this instance can be maintained with respect to both hardware and software. The latter allows minor patches to be applied to the SRS software without interrupting the actual service.

Each of the two Minds + Machines GmbH sites contains the full set of components that are required for operation and provides for redundancy. Under normal conditions, the primary site is active, while the secondary is inactive (components are in hot standby). In case of failure or maintenance that cannot or should not be compensated by redundant systems on the active site, the inactive site can take over the operation. The full switch-over, however, is not a requirement. Since the system consists of multiple subcomponents, the task of a failed subcomponent on one site can be transferred to the mirror subcomponent on the other site, while the other subcomponents remain on the first site. This gives the administration team freedom and flexibility to react to an incident and to minimise the impact on users. Switching of services is done using HSDNS pointers, see the answer to Q32, System and Network Architecture, for details.

The various sites are interconnected by virtual private networks (VPNs). This ensures the security and confidentiality of the communication. The VPNs are used both for data transferred between the sites as part of the Minds + Machines GmbH operations (e.g. zone files to the name servers, replication data between the databases, data feed of the Whois servers) and for administrative purposes, including monitoring.

In the unlikely event of a simultaneous outage of multiple components that makes it impossible to provide the service at the SRSʹs main operating site (data centre) in spite of the redundancy provided within each site, or in case of natural⁄man-made disaster at that main site, a switch-over to a different site is possible. Thanks to continuous database replication, the other site is equipped with the entire data of the repository.

Figure Q24-F1 presents a ʺbird viewʺ on the registryʹs sites, the services hosted at these sites (as described above), as well as the connections between them. The meanings of the graphical elements and symbols is described in Figure Q24-F2 (which provides a legend for all graphics attached to the answers throughout this gTLD application).

Figure Q24-F3 shows the overall structure of the registry systems per site. The various depicted resources and the relationship between them are described in detail in the answer to Question 31, Technical Overview of Proposed Registry, et seqq.


1.2 Software Development

Like all crucial components of Knippʹs registry system, the SRS has been developed from scratch by Knipp staff. The custom-built main server component consists of 100% Java code. While it utilises a couple of proven, open-source third-party libraries and products (such as SLF4J for logging and PrimeFaces for the web applications), the core registry functionality remains fully under Knippʹs control and may thus be customised as needed.


1.2.1 Change Control

All Java code comprising Knippʹs SRS is maintained in a repository managed by Subversion (SVN), the leading open-source revision control system. All code check-ins into this repository — either into the SVN trunk or into dedicated development branches (for larger additions or changes) — are closely monitored by senior developers.

Software releases meant to be deployed on staging, OT+E or production environments (see below and answer to Question 23, Registry Services) are always built from so-called ʺreleaseʺ branches within the SVN repository, i.e. not from the SVN trunk or development branches. Such branches are essentially snapshots of the code known to offer stable functionality with regard to a certain specification of the system. The exclusive use of these release branches ensures that no inadvertent changes from SVN trunk or development branches are affecting code deployed on systems used by registrars or the public.


1.2.2 Quality Assurance

Each release scheduled to be deployed undergoes a series of extensive tests by an internal QA team within Knipp. This includes functional tests, but also stress tests to evaluate the systemʹs behaviour under extreme load conditions.

Any issues found during these tests are reported back to the developers via JIRA, a widely used, enterprise-grade ticketing and issue system. Only after all issues were fixed to the satisfaction of the testers, a release is deployed — usually on the staging system first (also to give registrars an early opportunity to test their client systems against the new version), then on OT+E and production.

In addition to functional and stress testing, Knippʹs developers also write so-called unit tests with JUnit, a widely used Java unit testing framework that greatly facilitates regression testing.


1.3 Synchronisation Scheme

The synchronisation scheme is designed to enable any of the two sites to act as the master. However, in all cases except emergency and short annual fail-over tests, the system in Dortmund is the master. Data is synchronised on database level in real time.

The database software used will be PostgreSQL 9 (current version). There are four database systems altogether: two at the primary site (Dortmund) and two at the secondary site (Amsterdam). At any time, one of these four systems is active. Its data is replicated to the other three systems: locally to the other system at the same site and remotely to the other site, where a local copy is maintained, too.


2. System Reliability, Stability and Performance


2.1 Outage Prevention


2.1.1 Data Centre Precautions

The data centres hosting the system components of the Minds + Machines GmbH have taken various precautions to ensure a continuous operation, such as backup power supply, technical and facility security. Please refer to the answer to Question 31, Technical Overview of Proposed Registry, for more details.


2.1.2 Availability by Design

The general system design includes various features to reduce the risk of outages. These are summarised in the following paragraphs.

The network infrastructure of the SRS is designed to compensate a failure of one of its components. This is achieved by doubling each of these components, i.e. the firewall⁄VPN system, the load balancer and the switches that represent the internal backbone. They are operated in an active-active configuration. All servers within the system are equipped with two Ethernet interfaces for each logical connection. Where applicable, the components themselves are equipped with redundant power supplies. The interconnection between the servers and the network components provides redundant paths between each two nodes without a single point of failure. For more details please refer to Question 32, System and Network Architecture.

For the database system used by the SRS, double redundancy is provided. Firstly, there are two database servers, a primary and a secondary one. The secondary database is operated as a hot-standby solution. Secondly, there are two more database servers at the secondary site. The database data at the active site is replicated to the non-active site.

To process the EPP requests of the registrars, multiple systems are provided, which run the SRS software simultaneously. A load balancer distributes the incoming requests to these systems. An outage of one server does not interrupt the service. Although the available computing power is reduced by such an outage, the provisioned spare capacities ensure that the overall performance does not violate the service level agreement.

In the unlikely event of a simultaneous outage of multiple components that makes it impossible to provide the service, or in case of natural⁄man-made disaster at the ʺmainʺ site, a switch-over to the ʺmirrorʺ site is performed. Thanks to continuous database replication, the mirror site is equipped with the entire data of the repository. Depending on the nature of the main siteʹs failure, a limited data loss regarding transactions that were performed in the last few minutes of main site uptime may occur. Compared to the damage caused by a long-term outage, this is considered negligible.

The actual switch-over procedure consists mainly of the following steps: Complete shutdown of the main site if necessary. Despite the failure, some components may still be in an operative state. To avoid interference with the mirror site, these are deactivated. IP address change of the DNS address records belonging to externally visible servers to the corresponding servers on the mirror site. To facilitate this, a short time-to-live (TTL) setting will be used, and registrars are advised to use solely domain names to connect (not IP addresses). Name servers and Whois servers are reconfigured to use the mirror site as their data source. The registrars are informed about the switch-over, enabling them to adapt or restart their clients if necessary.

The Whois subsystem has the intrinsic ability to run an arbitrary number of Whois instances in geographically diverse locations (all fed from the same data source in a near-realtime fashion). The Whois servers operate their own databases for managing the Whois data. Load balancers are used to distribute the incoming requests to these instances. In such a setup, the outage of a single Whois instance will not disrupt Whois services for Internet users. Additional Whois servers can be added quickly to the existing setup if need be.

The huge number of different name server locations used by Knipp and the involved diversity (in terms of both geography and network topology) provide a high degree of inherent protection against DNS outages. In particular, the use of state-of-the-art Anycast methodology ensures that a server will be able to respond to requests as long as at least one of the sites in its Anycast cloud is available. In addition, reliable facilities with sufficient redundancy are provided at the individual sites hosting the name servers.


2.1.3 Hardware supplies and Software Availability

The data centres will keep spare parts for all critical hardware involved, which allows fast replacement in case of hardware failures. In addition, continuous 24⁄7 phone and on-site support from the vendors ensures the availability of hardware and software, including operating systems. Contracts guarantee that out-of-stock components are delivered within hours.


2.2 Performance Specifications

All components of the registry system (SRS, Whois, DNS) are operated in full compliance with ICANNʹs performance requirements as set forth in Specification 10 of the gTLD Applicant Guidebook. In particular, the SRS will meet the following specifications.


2.2.1 SRS Performance

Upper bounds for the round-trip time (RTT) of EPP requests have to be met by at least 90 per cent of all commands. The upper bound for session commands (login, logout) is four seconds, for query commands (check, info, poll, transfer) it is two seconds and for transform commands (create, delete, renew, transfer, update) it is four seconds. The downtime of the EPP service will be not more than 12 hours per month.


2.2.2 Registration Data Directory Services (RDDS) Performance

The upper bound for the round-trip time (RTT) of RDDS queries and for the RDDS update time has to be met by at least 95 per cent of all queries⁄updates. The upper bound for the collective of ʺWhois query RTTʺ and ʺWeb-based-Whois query RTTʺ is two seconds. The upper bound for the update time (i.e. from the reception of an EPP confirmation to a domain⁄host⁄contact transform command until the RDDS servers reflect the changes made) is 60 minutes. The downtime of the RDDS service will be not more than 8 hours per month, where non-availability of any service counts as downtime.


2.2.3 DNS Performance

The upper bound for the round-trip time (RTT) of DNS queries and for the DNS update time has to be met by at least 95 per cent of all queries⁄updates. The upper bound for the TCP DNS resolution RTT is 1500 milliseconds, for the UDP DNS resolution RTT it is 500 milliseconds. The upper bound for the DNS update time (i.e. from the reception of an EPP confirmation to a domain transform command until the name servers of the parent domain name answer DNS queries with data consistent with the change made) is 60 minutes. The downtime of the DNS service will be zero, i.e. continuous availability of this service is assured.


2.3 Operational Scalability

Operational scalability is primarily achieved by the underlying architecture of the components comprising the TANGO Registration System.

The software used for the processing of EPP commands is designed to run on multiple systems simultaneously. Due to the fact that the software makes extensive use of Javaʹs multi-threading capabilities, it scales well with the number of processors in each system. Therefore, long-term scalability due to increased registry activity can be accomplished by extending the system with additional processors and⁄or machines.

The SRS is dimensioned to run with about ten per cent load during regular operation. The initial system is able to handle the additional load resulting from increased domain numbers. To further cope with temporary unexpected load peaks, Knipp ensures that at least 100 per cent spare capacity is available all the time.

The above measures can be applied to scale the system from handling 10000 names to up to 20 million names and beyond. The initial capacity will be 1 million names and can be increased in steps of at least 1 million names within a mutually agreed time frame.

An important point is fair and acceptable use of system resources by registrars. As far as transaction numbers are concerned, the Minds + Machines GmbH subjects registrars’ access to acceptable use policies that forbid wasteful use of system resources. The registry systematically avoids situations where registrars or potential registrants find themselves under pressure to enter into a race against one another with respect to registry system resources. This applies in particular to launch phases, where a contention resolution mechanism (including the use of auctions) replaces time priority. The Minds + Machines GmbH furthermore imposes acceptable use restrictions to prevent the abuse of grace periods.

Additionally, the number of concurrent EPP connections per registrar is limited to a certain maximum, which is initially set to 10. Rate limiting is also implemented by limiting the EPP requests within a sliding window of one minute to a configurable number, in order to prevent monopolisation of the service by one registrar.

Thanks to these measures, the Minds + Machines GmbH avoids disproportionate demand for registry resources.


3. Employed Hardware

For server and storage systems, products of HP are to be used. Network equipment products of CISCO, HP, Juniper and Foundry are to be used. Employment of upgradable blade and RAID systems as well as ensuring redundancy of network components, power supplies and such increases not only scalability, but also availability and data integrity.

The database server as the central system component is dimensioned to be able to keep the relevant database content in memory to avoid slow disk I⁄O operations. An HP server system with 2 six-core 3 GHz CPUs and 48 GB RAM will be used. All other servers will be equipped with 24 GB of RAM. The database server is connected to a storage attached network (SAN), which is connected to a high-performance RAID system, the HP P6300 EVA 2.4 TB SFF SAS.


4. Resourcing Plans


4.1 Implementation

Since the TANGO Registration System itself has already been implemented, no resources are necessary for the initial implementation. For setting up and configuring database servers, firewalls and so on, the following resource allocations are estimated:

System Administrator: 25 man hours;

Network Operation Center Officer: 25 man hours;

DNSSEC Signing Operator: 5 man hours.


4.2 Ongoing Maintenance

For ongoing maintenance and occasional adaption of the system, the following resource allocations are estimated:

System Administrator: 5 man hours per month;

Network Operation Center Officer: 5 man hours per month;

Software Developer: 2 man hours per month;

Quality Assurance Agent: 1 man hour per month;

DNSSEC Signing Operator: 1 man hour per month.

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.

1. Experience

The EPP interface for registrars of the Minds + Machines GmbH is a part of the TANGO Registration System by Knipp Medien und Kommunikation GmbH. The employees of Knipp have years of experience in operating EPP-based registries. As a vendor for CORE Internet Council of Registrars, Knipp has developed the CORE Registration System, a shared registration system that has been used successfully for several registries.

Since 2006, Knipp handles the backend registry operation for puntCAT (responsible for the .cat top-level domain). Right from the start, the .cat Shared Registration System (SRS) offered an EPP frontend fully compliant with RFCs 3730-3734 (updated to compliance with 5730-5734 in the meantime), using various EPP extensions to cope with puntCATʹs special requirements. The SRS also fully supports the provisioning of DNSSEC data in accordance with RFC 5910; for backward compatibility, the previous DNSSEC EPP extension (RFC 4310) is also supported.

In addition, based on the same technology, Knipp Medien und Kommunikation GmbH as a technical provider for CORE is currently in the process of taking over back-end operations for a country code top-level domain managing between 200,000 and 500,000 domain names. The details of this cooperation cannot be disclosed at the time of writing. While this registryʹs DNS services have already been transitioned to Knipp at this point, the migration of SRS and Whois operations are currently being finalised.

Knipp Medien und Kommunikation GmbH has gained a lot of experience as the main contractor developing the CORE Registration System and as part of the technical operation of CORE Internet Council of Registrars. This system is a unified registration system for members of CORE, granting access to a multitude of top-level domain registries, currently including .com, .net, .org, .info, .biz, .name (with support for domain name and e-mail forwarding addresses), .us, .asia, .cn, .tw, .eu, .mobi, .aero, .me, .tel, .coop, .ch and .li domains, via a single entry point. CORE members can access all supported registries using a single, unified protocol. The CORE Registration System maps the commands issued by the user to the corresponding EPP commands, sends them to the appropriate registry server and translates back the received results. Members do not need to cope with problems regarding registry communication (like different flavours of EPP, SSL⁄TLS certificate handling or Punycode conversion for internationalised domain names) themselves.

Since the CORE Registration System acts as a client regarding all the supported registries, its implementation also allowed Knipp Medien und Kommunikation GmbH to gain considerable experience concerning all client side aspects of (different versions of) EPP. In particular, client-side EPP support had already started with the introduction of EPP by Afilias and Neulevel. On the server side, EPP has been in use since starting the operation of the puntCAT registry some five years ago. At the heart of the EPP implementation lies the so-called Unikit, Knippʹs own EPP toolkit implementation. The Unikit includes code for the client side and for the server side. In the context of the Minds + Machines GmbH, the server-side part of the Unikit will be used.

In the person of Klaus Malorny, Knipp also actively participated in the IETF Provisioning Registry Protocol (provreg) working group and contributed to some RFCs (see Acknowledgements in RFCs 5730-5733 and RFC 5910).

The software implementing the actual shared registry system, including its EPP interface, was entirely built by Knipp, involving an international team of developers — thus demonstrating the software development skills at Knippʹs disposal.


2. Standards Compliance

The EPP interface of the Minds + Machines GmbH, provided by the TANGO Registration System, is fully compliant with RFCs 5730-5734. These define mappings for the provisioning and management of Internet domain names, Internet host names and individual or organisational social information identifiers (ʺcontactsʺ) stored in a shared central repository.

Apart from these standards, the Minds + Machines GmbH also supports the proposed standard for DNSSEC (RFC 5910). This is an EPP extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository.

The proposed standard for an EPP extension for ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN) is fully supported also (RFC 3915). Such 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.

Furthermore, a few proprietary EPP extensions are used by the Minds + Machines GmbH to allow registrars to provide trademark information during the Sunrise phase, auction information during Sunrise and Landrush phases as well as language information. Documentation consistent with RFC 3735 for these proprietary EPP extensions can be found below.

All incoming requests will be validated against the schema definitions in the relevant RFCs and the ones of the proprietary EPP extensions, if applicable. This adds to security and stability, as invalid requests are dismissed early on. The EPP implementation of the Minds + Machines GmbH is compatible with existing toolkits that produce valid EPP requests.

Pending, asynchronous operations are fully supported by the registry implementation. The SRS returns an EPP result code of 1000 if a command has succeeded synchronously, i.e. immediately. In contrast, a result code of 1001 is returned if a command was accepted but requires asynchronous processing before it can be completed.


3. Stability

A stable EPP interface is very important for smooth operation of a shared registry system. To ensure this, the TANGO Registration System contains a multi-threaded, asynchronous communication implementation allowing a high number of concurrent EPP connections.

The incoming requests are filtered by their IP addresses via firewall rules in order to disallow access from unauthorised sites. This increases not only the security of the system, but also its stability, since the load on the EPP servers is reduced.


4. Equal opportunity

EPP access limitations for registrars are enforced by the TANGO Registration System, allowing a certain number of concurrent connections only. This further enhances the stability of the system and is an important ingredient for equal opportunity as well. Registrars cannot effectively hinder their competitors from connecting by simply opening a great many connections themselves.

For the sake of equal opportunity, the Minds + Machines GmbH also avoids first-come, first-served (FCFS) policies where possible. This is why the general availability (GA) phase is the only one using this principle. All popular domain names will probably have been registered already when GA starts (during previously conducted launch phases not using FCFS), so FCFS during GA does not contradict the idea of equal opportunity.


5. Proprietary Extensions

Knipp Medien und Kommunikation GmbH has already shown its ability to design, specify and implement proprietary EPP extensions in the context of the puntCAT registry. There, extensions exist for the specification of promotion codes, sponsor e-mail addresses, application objects (used during the Sunrise phase) and poll messages to notify registrars about application outcomes, for example. In the following, the proprietary EPP extensions planned to be used for .nrw are described.


5.1 Extension for Trademark Information during Launch Phases

The TANGO Registration System used to operate the Minds + Machines GmbH provides a proprietary EPP extension for submitting special data needed during launch phases.


5.1.1 Introduction

This part of this answer describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark. In particular, this extension allows the provisioning of trademark information and the querying of the current status of a domain name application.

In addition, the extension allows the specification of additional information about the application, such as the intended use for the domain name, a URL demonstrating prior use of similar names in other TLDs etc.; the registryʹs Sunrise policy determines whether and how this information is utilised.

An extension to the <poll> command is not included. Registrars are notified of application results via the poll message mechanism already included in EPP.

This extension has been developed along the lines of the Internet draft by Tan and Brown (see http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase-01). Even though that document is currently only a draft, it serves the purpose needed for the Minds + Machines GmbH and is clearly a step forward regarding the standardisation of launch phase handling in EPP. Since this draft does not supply a schema definition at the moment, the TANGO Registration System implements its own, which can be found in attachment Q25-Ext-LP.pdf, Section 1. Once the draft was augmented by a concrete schema definition, the TANGO Registration System will be adapted to utilise it, retaining the custom XML namespace identifier. Once the draft becomes an RFC, a transition will be conducted to adopt the standard.


5.1.2 Object Attributes

This extension for launch phases adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

Since registries usually allow multiple applications for a particular domain name during launch phases, an application object is used internally. Such an object has a unique ID that is returned upon creation and is used to refer to this application in further requests. Within this extension, an <lp:applicationID> element is used to specify this ID.


5.1.2.1 Phase

The <lp:phase> element can be used to distinguish multiple simultaneous launch phases. Its content is a server-defined identifier corresponding to a particular launch phase.


5.1.2.2 Application Status

The <lp:status> element is used to communicate extended status(es) of the application object, beyond what is specified in the object mapping to which this application object belongs.

The following status values are defined: ʺpendingʺ, the initial state of a newly-created application object; ʺvalidatedʺ, the application meets relevant registry rules; ʺinvalidʺ, the application does not validate according to registry rules; ʺallocatedʺ, the object corresponding to the application has been provisioned (one of two possible end states of an application object); ʺrejectedʺ, the object was not provisioned (the other possible end state).


5.1.2.3 Claim Data

An application may have one or more <lp:claim> elements. An <lp:claim> element describes the applicantʹs prior right to the domain name.

The <lp:claim> element has the boolean ʺpreValidatedʺ attribute, which indicates whether a third party validation agency has already validated the claim. When this attribute has a true value, the <lp:pvrc> element must always be present.

Several child elements of the <lp:claim> element are defined. <lp:pvrc>, the Pre-Validation Result Code, is a string issued by a third-party validation agent. <lp:claimIssuer> contains the ID of a contact object (as described in RFC 5733) identifying the contact information of the authority which issued the right (for example, a trademark office or company registration bureau). <lp:claimName> identifies the text string in which the applicant is claiming a prior right. <lp:claimNumber> contains the registration number of the right (i.e. trademark number or company registration number). <lp:claimType> indicates the type of claim being made (e.g. trademark, symbol, combined mark, company name). <lp:claimEntitlement> indicates the applicantʹs entitlement to the claim (i.e. owner or licensee). <lp:claimRegDate> contains the date of registration of the claim. <lp:claimExDate> contains the date of expiration of the claim. <lp:claimCountry> indicates the country in which the claim is valid. <lp:claimRegion> indicates the name of a city, state, province or other geographic region in which the claim is valid. This may be a two-character code from World Intellectual Property Organisation (WIPO) standard ST.3.


5.1.2.4 Additional Application Information

An application may carry a <lp:applicationInfo> element. If present, it contains additional information (beyond the claim) about the application, such as the domain nameʹs intended use.


5.1.3 EPP Command Mapping

This section deals with the specific command mappings for the Minds + Machines GmbH EPP extension for launch phases.


5.1.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: <check> to find out whether an object is known to the server, <info> to ask for detailed information associated with an object, <poll> to discover and retrieve queued service messages for individual clients and <transfer> to get transfer status information for an object.


5.1.3.1.1 EPP <check> Command

This extension does not add any elements to the EPP <check> command or to the <check> response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.2 EPP <info> Command

This extension adds elements to the EPP <info> command and response described in the EPP domain mapping for launch phase processing.

The EPP <extension> element of the <info> command contains a child <lp:info> element to indicate that an application object should be queried. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The <lp:info> element contains the following child elements: <lp:applicationID>, the application identifier for which the client wishes to query, and <lp:phase> (optional), the phase the application is associated with.

When such an <info> command has been processed successfully, the EPP <extension> element in the response contains a child <lp:infData> element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The <lp:infData> element contains the following child elements. <lp:applicationID> contains the application identifier of the returned application. <lp:phase> (optional) contains the phase the application is associated with. <lp:status> (optional) contains the status of the application. One or more <lp:claim> elements (optional) give the submitted data establishing the applicantʹs prior right to the domain name.

If any <lp:claim> element is present, each of them may contain the following child elements. <pvrc> gives the Pre-Validation Result Code. <claimIssuer> contains the ID of a contact object representing the issuing authority. <claimName> contains the textual representation of the right. <claimNumber> contains the registration number. <claimType> contains the type of claim being made. <claimEntitlement> contains the entitlement. <claimRegDate> contains the registration date. <claimExDate> contains the expiry date.

If additional information about the application was specified when the application was created, an <applicationInfo> element will be present containing that information.

Examples of an <info> command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.1. EPP <info> command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.1.3 EPP <poll> Command

This extension does not add any elements to the EPP <poll> command or to the <poll> response described in the EPP domain mapping (s. RFC 5731).


5.1.3.1.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2 EPP Transform Commands

There are five EPP commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes and <update> to change information associated with an object.


5.1.3.2.1 EPP <create> Command

This extension adds elements to the EPP <create> command and response described in the EPP domain mapping for launch phase processing.

The EPP <extension> element of the <create> command contains a child <lp:create> element to indicate that an application object for a launch phase should be created. It identifies the registry launch phase namespace and the location of the registry launch phase schema. The <lp:create> element contains the following child elements: <lp:phase> (optional), the phase the application should be associated with, zero or more <lp:claim> elements to substantiate the prior rights of the applicant, and an optional <lp:applicationInfo> element providing additional information about the application, such as the intended use of the domain name.

When such a <create> command has been processed successfully, the EPP <extension> element in the response contains a child <lp:creData> element that identifies the registry launch phase namespace and the location of the registry launch phase schema. The <lp:creData> element contains a child <lp:applicationID> element, which informs the registrar about the application ID the server has assigned.

Examples of a <create> command and corresponding response can be found in attachment Q25-Ext-LP.pdf, Section 2.2. EPP <create> command, since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.1.3.2.2 EPP <delete> Command

This extension defines additional elements to extend the EPP <delete> command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the <delete> response.

Clients may withdraw an application if permitted by registry policy. To do so, clients submit an EPP <delete> command along with an <lp:delete> element to indicate the application object to be deleted. The <lp:delete> element contains the following child elements: <lp:applicationID>, the identifier of the application to be deleted, and <lp:phase> (optional), the phase the application is associated with.

An example of a <delete> command can be found in attachment Q25-Ext-LP.pdf, Section 2.3. EPP <delete> command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The TANGO Registration System supports the withdrawal of an application using this extension to the <delete> command. Note, however, that support for the withdrawal of an application depends on the Minds + Machines GmbH Sunrise policy, which is described elsewhere.


5.1.3.2.3 EPP <renew> Command

This extension does not add any elements to the EPP <renew> command or to the <renew> response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.1.3.2.5 EPP <update> Command

This extension defines additional elements to extend the EPP <update> command described in the EPP domain mapping for launch phase processing. No additional elements are defined for the <update> response.

Clients may modify an application if permitted by registry policy. To do so, clients submit an EPP <update> command along with an <lp:update> element to indicate the application object to be modified. The <lp:update> element contains the following child elements: <lp:applicationID>, the identifier of the application to be modified, and <lp:phase> (optional), the phase the application is associated with.

An example of an <update> command can be found in attachment Q25-Ext-LP.pdf, Section 2.4. EPP <update> command, since the TLD Application System (TAS) is not well suited to pre-formatted text.

The TANGO Registration System supports the modification of an application using this extension to the <update> command. Note, however, that support for the modification of an application depends on the Minds + Machines GmbH Sunrise policy, which is described elsewhere.


5.1.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-LP.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.2 Extension for Auction Information

The TANGO Registration System used to operate the Minds + Machines GmbH provides a proprietary EPP extension for submitting special data needed for auctions as they occur after launch phases (e.g. Sunrise and Landrush).


5.2.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for special phases, usually at the beginning of registry operation. A typical use case is a ʺSunriseʺ phase during which trademark holders have a prerogative to register a domain name related to their trademark.

Registries usually allow multiple applications for a particular domain name during launch phases. This extension helps to resolve such situations by means of an auction in an automated way. This is not a normal auction, however, insofar as every application has a ʺbidʺ associated with it. Bids cannot be modified after the phase the application belongs to has ended. Among all valid applications for a given domain name, the one with the highest bid wins the auction.


5.2.2 Object Attributes

This extension for auctions adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.

This extension allows the provisioning of auction information in the form of bids. A bid can be made when applying for a domain name. In case there is more than one valid application, an auction mechanism is used as a tie-breaker. The highest bid submitted for the domain name in question will win the auction.


5.2.2.1 Bid

The <auction:bid> element is used to set and inform about a bid for a domain name. Its content is the amount of money the applicant is willing to pay for the domain name in case of an auction. The currency is given in the required currency attribute, specified by the corresponding ISO 4217 currency code.

Note that the amount is given as a non-negative number. This allows to submit a bid of zero in case the applicant is not interested in an auction at all.


5.2.3 EPP Command Mapping

This section deals with the specific command mappings for the Minds + Machines GmbH EPP extension for auctions.


5.2.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: <check> to find out whether an object is known to the server, <info> to ask for detailed information associated with an object, <poll> to discover and retrieve queued service messages for individual clients and <transfer> to get transfer status information for an object.


5.2.3.1.1 EPP <check> Command

This extension does not add any elements to the EPP <check> command or to the <check> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.2 EPP <info> Command

This extension does not add any elements to the EPP <info> command described in the EPP domain mapping. Additional elements are defined for the <info> response.

When an <info> command has been processed successfully, the EPP <extension> element in the response, if present, contains a child <auction:infData> element that identifies the registry auction namespace and the location of the registry auction schema. The <auction:infData> element contains an <auction:bid> element, which informs about the amount and currency of the currently set bid as described above.

An example of an <info> response can be found in attachment Q25-Ext-Auction.pdf, Section 2.1. EPP <info> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example simply retrieves the current bid for the given domain name.


5.2.3.1.3 EPP <poll> Command

This extension does not add any elements to the EPP <poll> command or to the <poll> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.1.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2 EPP Transform Commands

There are five EPP commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes and <update> to change information associated with an object.


5.2.3.2.1 EPP <create> Command

This extension defines additional elements to extend the EPP <create> command described in the EPP domain mapping for auction processing. No additional elements are defined for the <create> response.

The EPP <extension> element of the <create> command contains a child <auction:create> element to indicate that auction information should be submitted. It identifies the registry auction namespace and the location of the registry auction schema. The <auction:create> element must contain an <auction:bid> element, which specifies the amount and currency as described above.

An example of a <create> command can be found in attachment Q25-Ext-Auction.pdf, Section 2.2. EPP <create> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example sets the bid when applying for the given domain name to the specified amount.


5.2.3.2.2 EPP <delete> Command

This extension does not add any elements to the EPP <delete> command or to the <delete> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.3 EPP <renew> Command

This extension does not add any elements to the EPP <renew> command or to the <renew> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.2.3.2.5 EPP <update> Command

This extension defines additional elements to extend the EPP <update> command described in the EPP domain mapping for auction processing. No additional elements are defined for the <update> response.

The EPP <extension> element of the <update> command contains a child <auction:update> element to indicate that auction information should be updated. It identifies the registry auction namespace and the location of the registry auction schema. The <auction:update> element must contain an <auction:bid> element, which specifies the new amount and currency as described above.

Whether all modifications of bids are allowed, only certain ones (e.g. only increases) or none at all depends on the Minds + Machines GmbH auction policy, which is described elsewhere.

An example of an <update> command can be found in attachment Q25-Ext-Auction.pdf, Section 2.3. EPP <update> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example modifies the bid for the given domain name.


5.2.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-Auction.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


5.3 Extension for Language Information

The TANGO Registration System used to operate the Minds + Machines GmbH provides a proprietary EPP extension for internationalised domain names (IDNs).


5.3.1 Introduction

This part of this answer desribes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 5730. This mapping is an extension of the domain name mapping described in RFC 5731. It is specified using the Extensible Markup Language (XML) and XML Schema notation.

This extension serves the purpose of supplying and querying information for internationalised domain names. In particular, the language or script used and domain name variants are addressed.


5.3.2 Object Attributes

This extension for IDNs adds additional elements to the EPP domain name mapping. Only new element descriptions are documented here.


5.3.2.1 Languages and Scripts

This extension allows the specification of either a language tag or a script tag when registering a domain name. The language or script defines the characters allowed for use in the domain name as specified in the IDN tables (see Question 44, Support for Registering IDN Domains). It is not allowed to specify more than one language or more than one script.

For the time being, the Minds + Machines GmbH expects the value of a language tag element to be a an ISO 639-1 language code referring to a supported language. The value of a script tag is expected to be an ISO 15924 script code referring to a supported script.


5.3.2.2 Variants

This extension allows to specify a number of variants of the domain name to be registered together with the supplied domain name.

At the moment, the Minds + Machines GmbH does not support any languages with variants. Nevertheless, the IDN EPP extension already provides a means to specify variants. This feature allows the introduction of further languages with variants in the future without having to extend this EPP extension or even introduce another. An important motivation for the TANGO Registration System to put the language tag and the variants together in one extension is to limit the number of extensions. This improves adoption and acceptance by registrars and reduces their EPP extension-related work, especially if they connect to multiple registries run by the TANGO Registration System, some of which offer variants while others do not.

Until languages with variants are introduced, the variants part of this extension is required to be empty by registry policy.


5.3.3 EPP Command Mapping

This section deals with the specific command mappings for the Minds + Machines GmbH EPP extension for IDNs.


5.3.3.1 EPP Query Commands

There are four EPP commands to retrieve object information: <check> to find out whether an object is known to the server, <info> to ask for detailed information associated with an object, <poll> to discover and retrieve queued service messages for individual clients and <transfer> to get transfer status information for an object.


5.3.3.1.1 EPP <check> Command

This extension defines additional elements to extend the EPP <check> command described in the EPP domain mapping for IDN processing. No additional elements are defined for the <check> response.

The EPP <check> command is used to determine if an object can be provisioned within a repository. This IDN extension modifies base check processing to support language and script tags.

The EPP <extension> element, if present, contains a child <idn:check> element that identifies the registry IDN namespace and the location of the registry IDN schema. If at least one of the checked domains is an IDN, the <idn:check> element must contain either an <idn:lang> element or an <idn:script> element. The <idn:lang> element contains the language whose characters may be used in the checked domain names; the <idn:script> element contains the script whose characters may be used in the checked domain names. The language or script specification applies to all domain names specified in the command. The results of the check (i.e., the domains namesʹ availability for provisioning) are governed by the validity of the names with respect to the specified language or script.

Examples of <check> commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.1. EPP <check> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Two examples are included, one with a language tag (Section 2.1.1), one with a script tag (Section 2.1.2).


5.3.3.1.2 EPP <info> Command

This extension does not add any elements to the EPP <info> command described in the EPP domain mapping. Additional elements are defined for the <info> response.

When an <info> command has been processed successfully, the EPP <extension> element in the response, if present, contains a child <idn:infData> element that identifies the registry IDN namespace and the location of the registry IDN schema. The <idn:infData> element contains either an <idn:lang> element or an <idn:script> element. The <idn:lang> element contains the language that is set for the domain name object; the <idn:script> element contains the script that is set for the domain name object.

The <idn:infData> element also contains an <idn:variants> element, which in turn contains a (possibly empty) sequence of <idn:nameVariant> elements. The <idn:nameVariant> elements represent the variants that are registered together with the actual domain name.

Examples of <info> responses can be found in attachment Q25-Ext-IDN.pdf, Section 2.2. EPP <info> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.2.1), one with a script tag only (Section 2.2.2) and one with a language tag and variants (Section 2.2.3).


5.3.3.1.3 EPP <poll> Command

This extension does not add any elements to the EPP <poll> command or to the <poll> response described in the EPP domain mapping (s. RFC 5731).


5.3.3.1.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2 EPP Transform Commands

There are five EPP commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes and <update> to change information associated with an object.


5.3.3.2.1 EPP <create> Command

This extension defines additional elements to extend the EPP <create> command described in the EPP domain mapping for IDN processing. No additional elements are defined for the <create> response.

The EPP <create> command provides a transform operation that allows a client to create an instance of a domain object. This IDN extension modifies base create processing to support language tags, script tags and domain name variants.

The EPP <extension> element, if present, contains a child <idn:create> element that identifies the registry IDN namespace and the location of the registry IDN schema. The <idn:create> element must contain either an <idn:lang> element or an <idn:script> element. The <idn:lang> element contains the language whose characters may be used in the domain name; the <idn:script> element contains the script whose characters may be used in the domain name.

The <idn:create> element must also contain an <idn:variants> element, which in turn contains a (possibly empty) sequence of <idn:nameVariant> elements. The <idn:nameVariant> elements represent the variants that are to be registered together with the actual domain name.

Note that the Minds + Machines GmbH restricts the number of domain name variants given in the <idn:variants> element to at most 10. Submitting an empty <idn:variants> element is allowed; this will not register any domain name variants.

Examples of <create> commands can be found in attachment Q25-Ext-IDN.pdf, Section 2.3. EPP <create> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. Three examples are included, one with a language tag only (Section 2.3.1), one with a script tag only (Section 2.3.2) and one with language tags and variants (Section 2.3.3).


5.3.3.2.2 EPP <delete> Command

This extension does not add any elements to the EPP <delete> command or to the <delete> response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.3 EPP <renew> Command

This extension does not add any elements to the EPP <renew> command or to the <renew> response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.4 EPP <transfer> Command

This extension does not add any elements to the EPP <transfer> command or to the <transfer> response described in the EPP domain mapping (s. RFC 5731).


5.3.3.2.5 EPP <update> Command

This extension defines additional elements to extend the EPP <update> command described in the EPP domain mapping for IDN processing. No additional elements are defined for the <update> response.

The EPP <update> command provides a transform operation that allows a client to change the state of a domain object. This IDN extension modifies base update processing to support domain name variants.

The EPP <extension> element, if present, must contain a child <idn:update> element that identifies the registry IDN namespace and the location of the registry IDN schema. The <idn:update> element may contain an <idn:add> element and an <idn:rem> element. Each of these contain a (possibly empty) sequence of <idn:nameVariant> elements. Similar to the <update> commandʹs elements <domain:add> and <domain:rem>, these are used to specify the domain name variants that are to be added to and removed from the domain object, respectively. If the EPP <extension> element is missing in the <update> command, no change to the domain name variants will be made.

Note that the Minds + Machines GmbH restricts the number of domain name variants given in the <idn:add> and <idn:rem> elements to at most 10.

An example of an <update> command can be found in attachment Q25-Ext-IDN.pdf, Section 2.4. EPP <update> command, since the TLD Application System (TAS) is not well suited to pre-formatted text. The included example adds some variants to be associated with the given domain name while removing existing ones at the same time (Section 2.4.1).


5.3.4 Formal Syntax

The formal syntax of this EPP extension is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The schema definition is listed in attachment Q25-Ext-IDN.pdf, Section 1. Schema Definition (Formal Syntax), since the TLD Application System (TAS) is not well suited to pre-formatted text.


6. Resourcing plans


6.1 Initial Work

No resources are necessary for the initial implementation, since the TANGO Registration System (including the EPP extensions) has already been implemented.


6.2 Ongoing Work

For registrar support regarding the EPP extensions, the following resource allocations are estimated:

First Level Support: 4 man hours per month.

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.

1. Overview

The TANGO Registration System used by Knipp Medien und Kommunikation GmbH to operate the .nrw TLD will offer Registration Data Directory Services (RDDS) in compliance with Specification 4 of the Registry Agreement, consisting of a Whois Service, Zone File Access and Bulk Registration Data Access.


2. Whois Service


2.1 Interfaces


2.1.1 Port 43 Whois Service

Whois data for .nrw will be accessible via an interface on TCP port 43 at whois.nic.nrw, using the ʺWhoisʺ protocol (as defined in RFC 3912).

While the interface is publicly available, general use is rate limited to prevent data mining and mitigate denial of service attacks. Registrars may request to be exempted from the rate limiting measures by specifying IP addresses or address ranges to be put on a whitelist. Clients sending Whois requests from whitelisted IP addresses have unlimited access to the service.


2.1.1.1 Input Format

The input sent by Whois clients to the port 43 Whois server consists of two parts: the query options (starting with a hyphen character) and the query itself.

By default, the port 43 Whois service searches for domain names and name server names matching the query string. By the following keywords, the search type can be specified explicitly:

* ʺdomainʺ: Search for domains with matching names or IDs.
* ʺnameserverʺ: Search for name servers with matching names, IDs or IP addresses.
* ʺcontactʺ: Search for contacts with matching IDs.
* ʺregistrarʺ: Search for registrars with matching IDs or organisation names.

The remaining tokens in the input are taken as the search parameter. It may contain the percent sign (‘%’) as a wildcard for any number (including zero) of characters or the underscore character (‘_’) for a single character. For data mining prevention and resource protection, the number of objects returned for wildcard searches is limited to 50.

Evidently, the query format resulting from this input format specification is fully compliant with Specification 4, since it allows querying

* domains via: whois example.nrw,
* registrars via: whois ʺregistrar Example Registrar, Inc.ʺ,
* name servers via: whois ʺns1.example.nrwʺ and
* name servers via: whois ʺnameserver (IP Address)ʺ.


2.1.1.2 Output Format

The Whois implementation used by Knipp follows a template-based approach for its output to achieve maximum flexibility with regard to the desired format. Key-value output templates containing well-defined placeholders (e.g., for domain name, registrar name, name servers, or contact fields) for variable data allow customising the output for each response type to meet ICANNʹs demands. To supply values for the placeholders in the templates, the local Whois database is fed with all properties of registrars, domains, contacts and name servers that need to be present in the Whois output. Metadata such as the ʺlast Whois updateʺ date, is also available for use in templates. Thanks to this template mechanism, adjustments for changing requirements over time may be implemented easily.

Additionally, the Whois implementation supports internationalised output. If a contact uses ʺlocalisedʺ address fields in addition to ʺinternationalisedʺ data (as supported by RFC 5733), some data fields may contain non-US-ASCII characters. Also, internationalised domain names (IDN) allow the use of non-US-ASCII characters.

The results of a Whois query are encoded using either the US-ASCII character set, or, if a valid character set has been specified via the -C query option, the selected character set. If the output contains characters for which no encoding exists in the selected character set, they are replaced with a question mark, and a warning comment is added to the beginning of the output. Please see the answer to question 44 for more information about IDN support.

The format for values such as dates, times and phone⁄fax numbers in the Whois output conforms to the mappings specified in the EPP RFCs 5730-5734, since the SRS enforces compliant values for requests from registrars, stores them as received and feeds them to the Whois instances unmodified.

Overall, this means that the response formats for domains, registrars, and name servers, as described in ICANNʹs Specification 4 of the Registry Agreement, are fully supported by the Whois implementation used by Knipp.


2.1.2 Web-based Whois Service

The web Whois service operated at whois.nic.nrw shares the same functionality as the port 43 service, but receives query input via an HTML form. The output format is the same as for the port 43 service.

To prevent the Web interface from being abused for data mining, a CAPTCHA test (ʺCompletely Automated Public Turing test to tell Computers and Humans Apartʺ) must be passed upon each web Whois query before any response data is displayed.


2.2 Searchable Whois

Knippʹs Whois implementation offers search capabilities in accordance with Specification 2, Section 1.8. They allow complex searches for Whois database records based on the content of various data fields, thereby considerably exceeding common Whois query functionality.

This provides powerful means of information retrieval, such as finding all domain names registered by a certain person or company. When made available to unauthorised parties, this data may be abused for undesirable activities such as data mining (e.g. for advertising purposes) or social profiling. Restrictions must be imposed to prevent such abuse.

Consequently, this feature is offered exclusively on the web-based Whois interface (not the port 43 Whois), and is only available to authenticated users after they logged in by supplying proper credentials (i.e., user name and password). The Minds + Machines GmbH will issue such credentials exclusively to eligible users and institutions that supply sufficient proof of their legitimate interest in extended Whois searches, like e.g. law enforcement agencies. Authorisation policies and procedures are established in close collaboration with ICANN, and in compliance with any privacy laws and policies that may apply.

The search capabilities offered meet and exceed the requirements of Specification 2:

* Searches using the wildcards ʹ%ʹ and ʹ_ʹ (with semantics as described above) are possible on the following fields (thus allowing partial matches):
** domain name
** contact data (across all contact types, including the registrant):
*** name
*** organisation
*** address fields (street, city, state⁄province, postal code, country code)
* Exact match searches are possible on the following fields:
** registrar ID
** name server name
** name server IPv4 or IPv6 address (if stored in the registry for glue records)
* Multiple such search criteria may be joined by the logical operators (listed in descending precedence):
** NOT
** AND
** OR

The web interface offers a graphical editor for convenient creation of complex searches, allowing to group sets of search criteria in order to override the defined precedence of operators (thus providing the equivalent of parentheses in classic boolean expressions).

The search results are presented as a list of domain names matching the criteria. If more than 50 results are found, only the first 50 matches are presented on the initial result page, along with an indication of the total number of matches. Links allow the user to navigate through pages of search results.


2.3 Whois Data Distribution

The Whois implementation used by Knipp is written as an autonomous system component running in its own server instance, i.e. it is not part of the server running the SRS component. Multiple Whois instances, all serving the same SRS data, are run in parallel; these instances may be located in diverse locations (both geographically and in terms of network topology).

All instances of the Whois service operate on their own databases. This ensures a load decoupling between the SRS and the Whois servers - high request rates on the Whois servers will not affect the main registry systemʹs performance, and vice versa.

The database of a Whois server is continuously synchronised with the registryʹs database via a VPN connection. A special communication protocol (ʺWhois feedʺ) is used to supply information about objects that have been created, modified or deleted in the SRS to all connected Whois servers.

As soon as changes to the registryʹs database have been made persistent, these changes are forwarded to all Whois servers. The Whois servers update their own databases with the data and publish the new information. This way, changes to the registry will become visible on the Whois server typically in less than a minute, resulting in an RDDS update time well under the 60 minutes permitted by Specification 10.

The Whois feed protocol has been carefully designed to allow a graceful recovery from temporary SRS⁄Whois disconnections. In case of a communication problem or a maintenance of the Whois instance, changes that occurred since the last successful update are automatically identified and transferred.


2.4 Network Structure

The Whois network structure (for queries and the feed) is depicted in Figure Q26-F1.

The green path shows how a Whois instance is continuously fed with data from the SRS. To obtain updates, a Whois server instance (D) in the Demilitarised Zone (DMZ) maintains a TCP connection to the EPP backend (B) in the Trust zone through a firewall (C) which separates the two zones. The EPP backend fetches the required data from the primary SRS database (A) and sends a corresponding feed data stream to the Whois instance.

The yellow path illustrates the data flow of Whois queries. A port 43⁄web query coming in from the Internet enters the Untrust zone via a network router (1) and passes a firewall (2) into the DMZ. A load balancer (3) dispatches the request to one of the available Whois instances (4), which processes the requests and sends the response back to the Whois client or web browser.

As the server hardware and network setup planned for the Whois subsystem is part of the overall registry infrastructure, it shares its design principles and implementation. Please see the answers to Questions 31 and 32 for further details.


2.5 Inner Workings of a Whois Server Instance

The inner structure of a Whois server instance is depicted in Figure Q26-F2. It shows how incoming port 43 or web traffic from a load balancer (at the top) is processed internally.

Port 43 queries are handled by the RFC 3912 protocol implementation. A rate limiter component ensures that query limits are enforced for connections not originating from whitelisted IP addresses. Non-blocked requests are passed on to a query evaluator component, which parses the request, fetches required data from the instanceʹs local database engine and prepares the response based on the configured output templates. A separate statistics collector module gathers query statistics (such as query type and response time) in dedicated database tables; this data is used to create monthly ICANN reports.

Web-based queries are handled in a similar fashion. Clients connect to the Whois web frontend; if both the CAPTCHA and the rate limiter component are passed, the query from the web form is processed and answered (as well as included in statistics) just like port 43 requests. For this purpose, the web application container hosting the web Whois has direct access to the local database engine, i.e. it does not utilise the port 43 implementation, but processes requests autonomously. In contrast to the port 43 server, the web Whois also contains an LDAP authentication component; it is used to validate the credentials of users logging in for accessing the extended search features described above.

The bottom of the diagram shows the Whois feed client component, which is responsible for maintaining a connection to the Whois feed service of the EPP backend, processing the feed data and updating the local Whois database.


2.6 Whois Data Privacy Measures

The Whois server implementation used by Knipp is designed to support various levels of privacy regarding the content of query responses.


2.6.1 Consideration of EPP Data Disclosure Preferences

The EPP 1.0 standard, particularly its contact mapping as described in RFC 5733, provides means for registrars to specify their preferences concerning the handling of contact data submitted to the registry. Using optional 〈contact:disclose〉 elements when creating or modifying contacts, the registrar is able to identify contact fields that require special handling regarding their disclosure to third parties.

The Whois service is designed to respect the data disclosure preferences specified by registrars using these mechanisms. Unless registry policy dictates otherwise, contact fields will be included in or excluded from the Whois output according to the respective disclosure setting. The governing registry policy will be carefully tuned to be in line with applicable data protection laws.


2.6.2 Web Whois

The Whois serverʹs web interface uses the same output restrictions as the port 43 interface.

The CAPTCHA mechanism used to let only humans (as opposed to machines) access the Web whois provides protection against Whois data abuses like data mining or spam. As an additional guard against spam, any e-mail addresses within the Whois output can optionally be displayed as images only (instead of HTML text).


2.7 Support for Emerging Technologies

Knipp is aware of the shortcomings in todayʹs RDDS technology. The Whois protocol, as defined in RFC 3912, only defines the basic exchange between client and server, without any specification of input and output formats. This has led to a large number of different output formats among registries, posing problems for automated Whois clients.

In September 2011, ICANN’s Security and Stability Advisory Committee (SSAC) published SAC 051, a Report on Domain Name Whois Terminology and Structure. It contains recommendations for a domain name registration data access protocol suitable for replacing the current Whois technology. In February 2012, ICANN published a draft roadmap for the implementation of these recommendations. Knipp is committed to participate in this process, and to comply with and fully support any future RDDS technologies (such as an XML-based, RESTful Whois) emerging from it.


2.8 Whois Resiliency and Performance

Thanks to the Whois subsystemʹs intrinsic ability to run an arbitrary number of Whois instances in geographically diverse locations (all fed from the same data source in a near-realtime fashion), it offers considerable resiliency. In such a setup, the outage of a single Whois instance will not disrupt Whois services for Internet users.

The same feature also guarantees a high level of scalability and performance. Should the monitoring system operated by Knipp suggest an increased demand for Whois queries for names in the .nrw TLD, additional Whois servers can quickly be added to the existing setup. The decoupling of SRS and Whois services described above ensures that bursts in Whois usage will not impact SRS performance. Using such scaling measures if need be, even unusual peak volumes can be handled.

Please see the answer to question 34 (Geographic Diversity) for details about the locations planned for .nrw Whois instances.

In the initial setup, each Whois instance is capable of handling up to 500 queries per second. It is assumed that the average load will be at most 100 queries per second, so there is sufficient headroom for future load increases and bursts.


2.9 Compliance with Specification 10 of the Registry Agreement

The technical features described above ensure that the RDDS (Whois) implementation provided by the TANGO Registration System for .nrw will be in full compliance with Specification 10 of the Registry Agreement. RDDS availability, query round trip time (RTT) and update time will be maintained well within the permissible limits.

Due to the unpredictable complexity of searches conducted using wildcards or boolean operators, it is assumed that they are not used in queries for measuring RDDS availability and query RTT. Also, the service levels for these two metrics are only guaranteed for queries returning a maximum of 10 results.


3. Zone File Access

Knipp will enter into standardised agreement with Internet users seeking access to .nrw zone file data by following the procedures laid out in Specification 2, Section 2. For this purpose, the SRS prepares a .nrw zone data file compliant with the specified File Format Standard, which is made available at the ICANN-specified and managed URL (i.e. ftp:⁄⁄nrw.zda.icann.org). Through facilitation of the CZDA provider, users presenting sufficient credentials will be granted access to this data. Full cooperation and assistance will be provided to ICANN and the CZDA provider in this context.

In addition, bulk access to the zone files for .nrw will also be provided to ICANN or its designee, as well as to the Emergency Operators on a continuous basis.


4. Bulk Registration Data Access

As described in the answer to question 38 (Data Escrow), the Escrow module of the TANGO Registration System is capable of creating files containing Thin Registration Data, as well as Thick Registration Data restricted to the domain names of a single registrar. Using this facility, Knipp will grant ICANN periodic access to Thin Registration Data, as well as exceptional access to a failing registrarʹs Thick Registration Data, in a format and on a schedule fully compliant with Specification 2, Section 3.


5. Experience in providing ICANN-compliant Whois services

As a technical provider for CORE Internet Council of Registrars, Knipp designs, develops and operates Whois services as part of COREʹs SRS, which is used to supply registry backend services for the .cat and .museum registries. In this function, Knipp has continuously provided (and still provides) reliable Whois services for these registries, helping CORE to be in full compliance with RFC 3912 and ICANN registry agreements.

The experience gathered from these previous Whois related activities enables Knipp to develop and operate a Whois subsystem for the Minds + Machines GmbH that is fully compliant with all ICANN requirements.


6. Resourcing Plans

The TANGO Registration System already supports the Whois services as described above at the time of writing. Since the system is designed to be highly configurable, the realisation of different privacy policies merely requires changing the respective settings within the system configuration.

This means that no development resources will be needed for the Whois service during the initial setup of the system. However, the staff on duty at Knipp will need to define the related policies and configure the system accordingly.


6.1 Initial implementation

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 1.5 man days
* System Administrator: configuring system for policies: 4 man hours
* First Level Support: training: 2 man hours per person


6.2 Ongoing maintenance

For the ongoing system maintenance, the following resources are allotted:

* System Administrator: system maintenance: 0.5 man days per month
* First Level Support: support: 6 man hours per month
* Second Level Support: access authorisation: 5 man hours per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.

The TANGO Registration System used by Knipp Medien und Kommunikation GmbH to operate the .nrw TLD implements a registration life cycle that conforms with best practices and procedures widely used by existing top level domain registries. While the life cycle fully complies with all relevant EPP RFCs, it also simplifies the processing of automatic domain renewals in order to ease domain data management for registrars.

The attached state diagram (Figure Q27-F1) depicts the typical life cycle of a .nrw domain during the General Availability phase, from its creation to its release. In the following, the various triggers, states and transitions involved in the registration life cycle (denoted by capital letters in parentheses) are described in detail. Blue boxes denote domain states, yellow boxes denote actions caused by registrar commands, grey boxes denote automatic actions by the system, white boxes denote timed conditions reached at some point in the life cycle.


1. Domain Creation

(A) After receiving a 〈domain:create〉 command from the registrarʹs EPP client, the specified domain name is checked for availability and compliance with the registryʹs rules and policies. If these checks are passed, a corresponding domain object is created in the repository. Its expiration date is set according to the registration period specified in the 〈domain:create〉 command (1-10 years) and the EPP commandʹs time stamp.

With its creation, the domain also enters the Add Grace Period (AGP), which lasts 5 days; during this time frame, the registrar may delete the domain for a full refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded). Also, a domain deleted during the AGP will not enter the Redemption Grace Period (RGP), but will instead be released immediately. To indicate the AGP, the domainʹs Grace Period (GP) status according to RFC 3915 is set to ʺaddPeriodʺ; this status is automatically removed after the end of the AGP.

(B) The domain is registered. Provided that at least two name servers are present in the domain and the domain has not been put into status ʺclientHoldʺ or ʺserverHoldʺ, it is published in the TLD zone and carries the EPP status ʺokʺ. If no name servers are associated with the domain, the domain carries the EPP status ʺinactiveʺ to indicate that no delegation information is present. Note that a .nrw domain may either have zero name servers or 2-13 name servers; the case of exactly one name server is prohibited by server policy. In any case, the domainʹs current data is published on the Whois server (according to the disclosure settings set by the registrar).


2. Domain Update

(C) After receiving an EPP 〈domain:update〉 command, the domain is modified in the repository according to the data specified in the command. The domain returns to the registered state (B). Should the update change the domainʹs name servers or its ʺclientHoldʺ status, its publication in the TLD zone is affected according to the condition described in state (B). An update command may set other domain status values, such as ʺclientDeleteProhibitedʺ; see below for a full list of all supported status values. The TLD name servers and Whois servers are updated to reflect the domainʹs new data.


3. Domain Renewal (Automatic or Explicit)

(D) If a domain reaches its expiration date, it is automatically renewed; it will not be deleted, but remains in the registered state. Note that, in order to avoid unduly disruption of the domainʹs operation, this automatic renewal will even take place if the domain carries the status ʺclientRenewProhibitedʺ; this status will only disallow the explicit renewal of domains.

(E) With reaching its expiration date, the domain enters the so-called ʺAuto Renew Grace Periodʺ (ARGP), which lasts 45 days. During this time period, the registrar has the opportunity of deleting the domain name without being charged for the renewal. In order to avoid the necessity of a refund in this case, the TANGO Registration System only charges the registrar with the renewal fee after the end of the ARGP (i.e., when the renewal is final). If the registrar deletes the domain during the Auto Renew Grace Period, nothing has been charged yet, so no refund is required either. Note that this differs from the commonly used practice of charging the renewal fee already at the beginning of the Auto Renew Grace Period, which requires complicated refunds in case the domain is deleted or transferred in this period. During the Auto Renew Grace Period, the domain carries the ʺautoRenewPeriodʺ GP status, which is also displayed in the Whois along with the previous expiration date (now in the past). Only after the end of the Auto Renew Grace Period, the expiration date is increased.

(F) If the end of the ARGP is reached before the registrar deletes the domain, the registrar is charged with the renewal fee. The domainʹs ʺautoRenewPeriodʺ GP status is removed.

(G) After explicit renewal (or final automatic renewal), the domainʹs expiration date is increased. The domainʹs Whois output is changed to reflect this.

(H) If the registrar explicitly renews a domain by sending a 〈domain:renew〉 EPP command, the TANGO Registration System increases the domainʹs expiration date according to the period value specified in the command. Note that a domainʹs remaining registration period may not last more than 10 years; renewal requests that would make a domain exceed this limit are rejected. The registrar is charged with the corresponding renewal fee. The domainʹs ʺRenew Grace Periodʺ is started, which lasts 5 days; during this period, the domain may be deleted for a full refund of the renewal fee. This is indicated via the ʺrenewPeriodʺ GP status, which is automatically removed when the Renew Grace Period ends.


4. Domain Deletion

(I) After receiving an EPP 〈domain:delete〉 command, the deletion of the domain from the repository is initiated.

(J) If the domain is in its AGP when the delete command is received, it will be released immediately, i.e. it will be available for new registrations right away. The domain will not enter the Redemption Grace Period (RGP) in this case, and the registrar receives a refund of the registration fee (as long as the limits specified by the AGP Limits Policy are not exceeded).

(K) The domain is released (i.e., purged from the repository) and available for new registrations. This marks the end of the domainʹs life cycle. If the domain was in its Add, Auto Renew, Renew or Transfer Grace Period when the delete command was received, the related charges are refunded to the sponsoring registrar.


5. Domain Restore After Deletion - the Redemption Grace Period (RGP)

(L) If the domain is not in its AGP when the delete command is received, it enters the Redemption Grace Period (RGP), which lasts 30 days. This means that the domain is not released immediately, but is only put into the EPP status ʺpendingDeleteʺ (which is also displayed in the domainʹs Whois output) and withheld from DNS publication.

The TANGO Registration System fully supports the Redemption Grace Period procedures and protocols, as defined by RFC 3915. During the RGP, the domain may be restored by the previous registrar by sending a 〈domain:update〉 command carrying an EPP RGP extension according to the RFC.

(M) The domain is in the Redemption Grace Period (RGP). During this phase, it is not present in the TLD zone. The domain carries the EPP status ʺpendingDeleteʺ and the RGP status ʺredemptionPeriodʺ according to RFC 3915.

(N) If the domain is not restored by the previous registrar before the end of the RGP, the domain will be scheduled for release. The EPP status ʺpendingDeleteʺ is retained, the domainʹs RGP status is changed to ʺpendingDeleteʺ.

(O) The domain is no longer restorable by the registrar and due for release. It will remain in this state for a time period defined by registry policy; this could, for example, be a variable time period with a random offset in order to make the release date and time less predictable for domain snipers. Once this time period ends, the domain is released and put into the final state (K).

(P) If the previous registrar restores the domain before the end of the RGP (by sending a 〈domain:update〉 command carrying an EPP RGP extension according to RFC 3915), the domainʹs RGP status is changed to ʺpendingRestoreʺ. If the registrar also sends the RGP restore report within 5 days (or along with the update command), the ʺpendingDeleteʺ status value is removed from the domain and the domain will be put back into the registered state (B). If the conditions described under (B) are met, the domain will be re-added to the TLD zone. If, however, the restore report is not received within 5 days, the domain goes back into the RGP (RGP status ʺredemptionPeriodʺ), i.e. into state (M); the RGP is not restarted in this case, but is resumed at the point when the restoration was initiated by the registrar.


6. Domain Transfer

(Q) Upon request by a domainʹs registrant, a registrar (called ʺgainingʺ registrar in this case) may request to transfer a domain name currently sponsored by a different registrar (the so-called ʺlosingʺ registrar) into its own domain portfolio. This is done by sending an EPP 〈domain:transfer〉 command with operation ʺrequestʺ. After receiving such a command, the domain is marked with a ʺpendingTransferʺ EPP status value. 〈domain:trnData〉 EPP poll messages are placed in the message queues of both gaining and losing registrar to inform them about the transfer request. The gaining registrar is charged with the transfer fee.

A request for a domain transfer will only succeed if certain conditions are met. In particular, the provided authorisation information must be correct, and the domain must not have the ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status values set. Note that the status ʺserverTransferProhibitedʺ is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer. This is common practise among registries and avoids the problem of ʺregistrar hoppingʺ, i.e. frequent registrar changes (after e.g. hijacking a domain name) in order obstruct takedown procedures.

(R) The domain transfer is pending. The TANGO Registration System waits for either the transfer to time out (after 5 days), or for the reception of an approval, rejection or cancellation before the time-out. The losing registrar may approve or reject the transfer by sending an EPP 〈domain:transfer〉 command with operation ʺapproveʺ or ʺrejectʺ, respectively. The gaining registrar may cancel the transfer by sending an EPP 〈domain:transfer〉 command with operation ʺcancelʺ.

(S) The transfer was completed successfully, either by approval of the losing registrar or by time-out (which by default automatically approves the transfer; this behaviour is configurable). The ʺpendingTransferʺ EPP status value is removed from the domain. The domain is assigned to the gaining registrar and removed from the losing registrarʹs portfolio. 〈domain:trnData〉 poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). A successful transfer starts the domainʹs ʺTransfer Grace Periodʺ (TGP) which lasts 5 days; during the TGP (which is indicated by the ʺtransferPeriodʺ GP status), the domain may be deleted by the gaining registrar for a full refund of the transfer fee.

(T) The transfer was unsuccessful, i.e. it was rejected by the losing registrar or cancelled by the gaining registrar. The EPP status ʺpendingTransferʺ is removed from the domain. 〈domain:trnData〉 poll messages are placed in the message queues of both gaining and losing registrar. The domain returns to status (B). The transfer fee previously charged to the gaining registrar is refunded.


7. EPP and Grace Period Status Values

As described above, the .nrw domain life cycle involves various EPP Domain and Grace Period status values and uses them in compliance with RFCs 5730-5733 and 3915 (note that RFC 5910 does not specify any status values). This section provides an overview of the status values and describes whether and how they are used in the life cycle.

In general, status values starting with ʺclientʺ may only be set or removed by the registrar, while all other status values (including those starting with ʺserverʺ) may only be set or removed by the registry, either automatically or manually by registry staff.


7.1 EPP Domain Status Values (from RFC 5731)

* clientDeleteProhibited: Indicates that the domain cannot be deleted by a 〈domain:delete〉 command.
* clientHold: Indicates that the domain is not published in the .nrw zone.
* clientRenewProhibited: Indicates that the domain cannot be renewed by an explicit 〈domain:renew〉 command; the status does not prevent automatic renewal.
* clientTransferProhibited: Indicates that the domain cannot be transferred.
* clientUpdateProhibited: Indicates that the domain cannot be modified.
* inactive: The domain has no delegation information, i.e. no name servers are associated. The domain is not published in the .nrw zone.
* ok: The domain is active, i.e. it resolves, has no pending operations or prohibitions, and carries no other status values.
* pendingCreate: Indicates that the domainʹs creation is pending, i.e. that an asynchronous process is in progress to finish the domainʹs creation. This status is supported, e.g. for use during launch phases such as Sunrise and Landrush (to indicate that a domain applicationʹs asynchronous review is pending).
* pendingDelete: Indicates that the domain is being deleted; depending on its RGP status (see below), it may be restorable or not.
* pendingRenew: Indicates that the domain is pending a renewal. While supported by the TANGO Registration System, this status not used in the designated .nrw domain life cycle.
* pendingTransfer: Indicates that the domain is in the process of being transferred from one registrar to another registrar.
* pendingUpdate: Indicates that an update to the domain is pending, i.e. that an asynchronous process is in progress to finish the domainʹs modification. While supported by the TANGO Registration System, this status not used in the designated .nrw domain life cycle.
* serverDeleteProhibited: Indicates that the domain cannot be deleted.
* serverHold: Indicates that the domain is not published in the .nrw zone.
* serverRenewProhibited: Indicates that the domain cannot be renewed by an explicit 〈domain:renew〉 command; the status does not prevent auto-renewal.
* serverTransferProhibited: Indicates that the domain cannot be transferred. This status is automatically set and maintained for 60 days by the SRS after a domain is first created, as well as after each successful registrar transfer.
* serverUpdateProhibited: Indicates that the domain cannot be modified.


7.2 EPP Grace Period Status Values (from RFC 3915)

* addPeriod: Indicates that the domain is in the Add Grace Period.
* autoRenewPeriod: Indicates that the domain is in the Auto Renew Grace Period.
* renewPeriod: Indicates that the domain is in the Renew Grace Period.
* transferPeriod: Indicates that the domain is in the Transfer Grace Period.
* pendingDelete: Indicates that a deleted domain is scheduled for release, i.e. it can no longer be restored by the registrar.
* pendingRestore: Indicates that a request to restore a deleted domain has been received, and that the registry awaits the restore report from the registrar.
* redemptionPeriod: Indicates that a deleted domain is in its Redemption Grace Period, i.e. it may be restored by the registrar.


8. Consistence with Commitments to Registants

The registration life cycle described above is consistent with the registryʹs commitments to registrants, as laid out in the answer to Question 30a. In particular, the handling of auto-renewals and the Redemption Grace Period ensures the ʺProtection of Investmentʺ part of that commitment, since it protects the domain from vanishing unintendedly.

Responsible editor adds special sunrise content here.


9. Resourcing Plans

The TANGO Registration System already supports the life cycle described above at the time of writing. Since the system is highly configurable, the adjustment of any variables and flags defining the process (such as name validity policies, or the durations of involved grace periods and time-outs) merely requires changing the respective settings within the system configuration. No coding is required for this, which means that no special developing resources will be needed. However, the staff on duty at Knipp Medien und Kommunikation GmbH will need to define the related policies and set up the system to support and maintain the desired registration life cycle.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 3 man days
* System Administrator: configuring system for policies: 4 man hours
* First Level Support: training: 3 man hours per person

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 4 man hours per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp in the past over the course of 12 months.

28.1 --ABUSE POINT OF CONTACT--
Strong abuse prevention is an important benefit to the Internet community. Minds + Machines GmbH (M+M GmbH) agrees that a registry must not only aim for the highest standards of technical and operational competence but must also act as a steward on behalf of the Internet community in promoting the public interest. One of those public interest functions for a responsible domain name registry includes working towards the eradication of abusive domain name registrations, including, but not limited to, those resulting from:
 * illegal or fraudulent actions 
 * spam
 * phishing
 * pharming 
 * distribution of malware 
 * fast flux hosting 
 * botnets 
 * distribution of child pornography 
 * online sale or distribution of illegal pharmaceuticals

The sister company Minds + Machines LLC (M+M LLC) provides the staff to handle abuse prevention and mitigation. Roles and responsibilities refer to M+M LLC staff. The Compliance Administrator (CA) serves as the primary Abuse Point of Contact (as required by ICANN). CA will be responsible for overall policy development and enforcement.

CA will administer the complaint resolution process, and communicate with registrars (with the assistance of the Registrar Liaison), with law enforcement, the World Intellectual Property Organization and industry organizations such as the Anti-Phishing Working Group and the Registration Abuse Policies Working Group. M+M LLC’s Chief Technical Officer (CTO) will also serve as the secondary Abuse Point of Contact. The CA, CTO or other personnel will be reachable on a 24⁄7 basis to deal with any alleged abuses that require immediate attention, whether from law enforcement or otherwise.

All of the M+M LLC staff will be trained to (i) respond to communication concerning abuse via the published (the required abuse point-of-contact) and restricted (only available to law enforcement and the customers) contact details; (ii) perform sufficient verification to distinguish genuine claims from the malicious and from false positives; (iii) enter the details into the abuse tracking and monitoring system; (iv) identify and contact the registrar of record, inform them of the complaint, initiate a prompt investigation of the complaint and note any information received back from the registrar; and (v) report progress to the complainant at appropriate times.

Primary and secondary Abuse Points of Contact, as well as designated employees, will be supplied with pagers and smart phones, and create an “on call” roster to assure 24x7 availability of abuse prevention and mitigation resources.

The .NRW website will prominently display and provide easy access to policies, resources available for handling complaints regarding abuse, and how to contact the designated Abuse Point of Contact. The Abuse Point of Contact staff will provide timely responses to complaints.

An abuse and complaint tracking and monitoring system will be set up as part of the registry software and maintained by Minds + Machines on our behalf. No further resourcing or provisioning will be required to maintain this effective 24x7 system.

28.2 --ABUSE PREVENTATION AND MITIGATION PROGRAM--
The abuse prevention and mitigation program (the “Program”) is based on best practice policy recommendations developed by the Council of Country Code Administrators (CoCCA), on lessons learned from previous new gTLD launches, on the operating experience of TLDs such as .COM, and on participation in policy working groups and debate at ICANN. All policies are consistent with and conform to ICANN consensus policies where applicable. Twenty‐five ccTLDs use the CoCCA policy framework to ensure protection of the registry, and to minimize abusive registrations and other activities that affect the legal rights of others. We have updated the best parts of these policies to the new gTLD environment to protect the specific needs of the registry and the registrants, and the rights and needs of third parties. Wherever applicable, we follow the recommendations of NIST SP 800-83 Guide to Malware Incident Prevention and Handling.

The Program is comprised of policies, procedures and resource allocation that aim to prevent and mitigate abusive practices at all levels of registry operations and domain name use.

The Program aims to: (i) prevent the registration of names that violate policies; (ii) provide efficient procedures for the reporting and removal of names that violate policies if they are registered; (iii) provide efficient procedures for the reporting and removal of domains which engage in abusive or unlawful practices; and (iv) secure and protect domain name ownership and Whois information.

The Program is designed to provide for the transparent and non-discriminatory registration of domain names; to protect Whois data and privacy; to ensure adherence by registrars and registrants to the Acceptable Use Policy (AUP); to protect trademarks and prevent registration of blocked and reserved names; to prevent the registration of illegal terms and inappropriate names; to prevent violations of the law; to combat abuse of the DNS; to address cybercrime; to protect intellectual property, and to align use of the registry with the applicable regulatory and legislative environments. We note that while as a registry operator we cannot remove prohibited or unlawful content from the Internet, we can and will seek to ensure that the network is not part of the abuse or publication chain.

The Program is balanced between the need to prevent abusive registrations and uses, the need to properly implement ICANN policies and follow applicable laws, and the need to respect the legal rights of registrants and others. The goal is to encourage legitimate use while discouraging abusive or illegal use. We recognize the importance for the overall health and reputation of the registry that we handle abusive registrations and use quickly, fairly and impartially.

The Program will be administered to (i) ensure that registrars adhere to registration policies; (ii) enforce the policies with registrars and registrants; and (iii) prevent any violations as effectively and efficiently as possible. The means for enforcing policies and procedures will be the comprehensive contract, which sets out penalties for non-compliance; and the registry software TANGO that is provided by Knipp Medien und Kommunikation GmbH, through which some regulations and procedures will be enforced (for instance, blocking reserved names and displaying Trademark Clearinghouse notices and warnings).

The Program employs a model that includes registry-level suspensions for AUP and other policy violations; and also provides that the use of a domain is subject at all times to the AUP’s provisions concerning cybercrime, prohibited content, intellectual property abuses and other issues of importance to the Internet, security, intellectual property, legal and law enforcement communities.

Below we describe various agreements and policies, each of which will be a part of the Program:

 (1) REGISTRANT AGREEMENT - The Registrant Agreement, which must be presented to the registrant for agreement by the registrar as a condition of registration, binds the registrant to ICANN-mandated rights protection mechanisms, including the Uniform Dispute Resolution Policy (“UDRP”), AUP, Privacy Policy, Whois Policy, and the Complaint Resolution Service. At the time of registration, registrars will be contractually required, pursuant to the Registry-Registrar Agreement, to bind registrants to these agreements.
 (2) REGISTRY-REGISTRAR AGREEMENT (RRA) - The primary mechanism for ensuring that registrars adhere to registration guidelines, meet the obligations set forth in the policies and pass them on to registrants will be through the RRA we will sign with registrars. The terms of the RRA adhere to ICANN policies and contain additional abuse safeguards. The RRA includes provisions that must also be included in the contract between registrars and registrants. Registrars may include additional provisions, but those provisions may not conflict with the language provided by us, and registrars must include the terms and conditions in their entirety, and legally bind registrants to them. It is by this mechanism that registration and use policies, regulations and procedures will be passed on to registrants. The RRA contains provisions to combat abusive registrations or use as required by ICANN policies, applicable laws, and the registryʹs Acceptable Use Policy.

 (3) ACCEPTABLE USE POLICY (AUP) - The AUP is incorporated into the Registrant Agreement. It defines the acceptable use of second-level domains, and is designed to ensure that the registry is used for appropriate and legal purposes. It specifically bans, among other practices, the use of a domain name for abusive or illegal activities, including (i) illegal, fraudulent, misleading, or deceptive actions or behavior; (ii) spamming (the use of electronic messaging systems to send unsolicited bulk messages, including email spam, instant messaging spam, mobile messaging spam, the spamming of Web sites and Internet forums, and use of email in a Distributed Denial of Service (DDoS) attack); (iii) phishing (the use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data); (iv) pharming (the redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning); (v) willful distribution of malware (the dissemination of software designed to infiltrate or damage a computer system without the owner’s consent--e.g. computer viruses, worms, keyloggers and Trojan horses); (vi) 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); (vii) 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 DDoS attacks); (viii) distribution of obscene material, including but not limited to child pornography, bestiality, excessive violence; (ix) illegal or unauthorized access to computer networks or data (illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another party’s system, often referred to as “hacking,” or any activity that may be used as a precursor to an attempted system penetration, such as port scanning, stealth scanning, probing, surveillance or other information gathering activity); (x) deceptive or confusing uses of the domain or any content provided thereon with respect to any third party’s rights; (xi) disrupting the registry network or the provision of any content capable of disruption of computer or systems or data networks; (xii) providing circumvention technologies, technical information or other data that violates mandatory export control laws; (xiii) spoofing (forging email network headers or other identifying information); and (xiv) distribution of any other illegal or offensive material including hate speech, harassment, defamation, abusive or threatening content, or any other illegal material that violates the legal rights of others including but not limited to rights of privacy or intellectual property protections.

 (4) PRIVACY AND WHOIS POLICY - The Privacy & Whois Policy is incorporated into the terms and conditions presented to potential registrants. It is designed to prevent abuse by: (i) requiring that registrants provide us with accurate information to be included in their “thick” Whois listing; (ii) by requiring that registrars proactively require registrants to verify and⁄or modify their Whois information to ensure its accuracy on an ongoing basis as per ICANN policy; and (iii) making the failure to provide or maintain complete and accurate Whois information a material breach of the Registrant Agreement, which will allow us to cancel any registration for which the Whois information is not accurate or complete.

(5) EXPIRED DOMAIN DELETION POLICY – As per ICANN policy, the Expired Domain Deletion Policy sets out how a domain name is registered and renewed, and includes policies and procedures for redemption and grace periods.


 (6) NAMING POLICY - The Naming Policy sets out policies governing prohibited, blocked, and reserved names and eligibility criteria for registrants. It also provides registrants with information regarding trademark and third party rights in names, and offers guidance on choosing a domain name that comports with the policies, regulatory and legal policies, and the rights of third parties. This Policy will provide registrants with the list of blocked and reserved names; explain the rights of trademark holders and the role of the Trademark Clearing House in the registration process; and explain the policies concerning “typosquatting” - misspellings, “typos” or other names that give false or misleading impressions.

A plain language version of the policies will be made available to registrars and potential registrants. Registrants will be required to give their informed consent to be bound by the policies during the registration process, but we recognize that registrants may not fully understand what they are agreeing to when they register a domain name, because the contractual language might be difficult. As an example, registrars will present the registration policies to the registrants and secure their agreement prior to registration. The registration policies are many pages long and contain words and concepts that may not be familiar to an average Internet user. Since registrants cannot adhere to policies if they cannot understand them, we will also ask registrars to provide a prominent link to a “plain-language” overview of the policies posted on the website. This link will set forth the major terms and conditions in non-legal terms in order to make them understandable to the average registrant. While contracts will be the official and legally binding agreements, we believe the plain-language overview will be very useful for conveying to registrants the major points of their obligations with regard to their domain name itself and their use of that domain name.

The policies, the plain language overview and a Frequently Asked Questions page that compiles all the major aspects of the policies will be prominently available on the website together with explanations and links to the Uniform Rapid Suspension (URS) Service, the UDRP, and the Complaint Resolution Service, with instructions and facilities for reporting alleged abuses to us directly.

28.3 --ANTI-ABUSE MEASURES PRIOR TO REGISTRATION--
The Program will include policies and procedures designed to prevent abusive registrations and use from the start by providing users with guidelines for choosing names, informing them of the proper and improper use of those names, and the consequences of abuse. The anti-abuse measures prior to registration include:

 (1) Implementation of the Trademark Claims Service (TCS): In the case where a potential registration is an exact match to an applicable trademark in the Trademark Clearing House, the TCS automated notification service will inform registrants that the name they may be about to register may be a violation of the trademark rights of a third party, and that their registration may be subject to challenge and possible cancelation. We will not, however, reserve or block domain name registration of terms, or confusingly similar terms, which might infringe intellectual property or other rights. The Naming Policy will however advise registrants that prior to registering the name, it is the registrants’ responsibility to determine whether or not any particular term might infringe the intellectual property or other legal rights of an entity or individual. The Policy will also encourage registrants to perform a trademark search with respect to the term comprising the domain name prior to registration, and inform the registrant that it is solely liable in the event that the name constitutes an infringement or other violation of a third party’s rights, which may include criminal liability for willful, fraudulent conduct.

 (2) Preventing numerous attempts to register reserved or blocked names: The policies provide that registrants who repeatedly try to register reserved or blocked names, or names that infringe the rights of others, will be banned from registering domain names. Further, any domain names registered to them will be cancelled or transferred, as provided for in the Registrant Agreement and AUP. We specifically inform such users that we reserve the right to refer them to appropriate legal authorities.

 (3) Blocking⁄flagging certain names: We will be able to enforce many of the registration policies at the point of registration through the TANGO platform. For example, the TANGO platform can block certain prohibited names from registration. In addition, domain names that are doubtful--for instance names that contain within them blocked or reserved names--or portions thereof--may be flagged for further review before they are delegated. We believe that a robust implementation of registration policies through the registry software is the best first line of defense against certain types of violations. The TANGO Registration System provides the following general means to make sure that no .nrw names are registered which are for other reasons deemed invalid, reserved, blocked, illegal, offensive or unsuitable. For the most part, this is achieved by the deployment of a complex rule engine that checks each registered name at the time of registration for compliance with a configurable set of rules. Among other things, these rules include

* a test to ensure that the domain name has the proper number of labels (which is two for a traditional registry that allows only second level domains to be registered),
* a test to ensure that no hyphens occur in position 3 and 4 of any of the domainʹs U-labels (to protect ʺxn--ʺ and future ACE prefixes),
* a test to disallow hyphens at the beginning or end of the name,
* a test to find ASCII characters which are neither a letter, nor a digit or a hyphen,
* a test to find invalid IDN characters, i.e. characters not contained in any of the supported IDN tables,
* a test to disallow reserved geopolitical names,
* a test to disallow registry reserved names,
* a test to disallow ICANN reserved names,
* a test to disallow otherwise reserved or unsuitable names.

Please refer to the answer to Question 44 (Internationalized Domain Names) for more information on the rules governing valid IDNs in the .nrw TLD.

For the tests checking for reserved names, custom lists of labels can be conveniently maintained by the M+M GmbH to define the disallowed names for each category. Additional categories can also be added as required for enforcing specific policies of the .nrw TLD.

The rules are stored in database tables (rather than static configuration files), which means rules can be added, deleted or altered by authorized registry personnel without requiring a shutdown or restart of the .nrw SRS.


a) Compliance with Specification 5 of the Registry Agreement
The rule engine is the central system component ensuring that the M+M GmbH will operate the .nrw TLD in full compliance with Specification 5 (ʺSCHEDULE OF RESERVED NAMES AT THE SECOND LEVEL IN GTLD REGISTRIESʺ) of the Registry Agreement. Unless the M+M GmbH is otherwise authorized by ICANN and the Government Advisory Committee (GAC) in writing, the rule engine for .nrw will be set up to prohibit the registration of the labels and label types listed in Specification 5 by registrars.


b) Pattern Matching and Fuzzy String Comparison
In addition to the pre-registration checks described above, the rule engine also supports testing registered domain names against a set of configurable string patterns, as well as for their similarity to a set of disallowed strings. The former is implemented by matching names against regular expressions, the latter by calculating the so-called ʺLevenshtein distanceʺ between the registered name and a given disallowed string (which is a measure for their similarity). Prior to performing any of these checks, the registered name is subjected to a number of normalisations in order to maximise its comparability; this includes the mapping of IDN characters with accents to their ASCII counterparts where feasible, the removal of hyphens and the removal of digits.

If a name matches a regular expression, or if the calculated Levenshtein distance falls below a certain threshold, the name is still normally registered, however it is also internally flagged for review. Due to the fuzzy nature of the pattern and Levenshtein matching, a name flagged via these checks may not necessarily be invalid or illegal; this is why the flagged names need to be reviewed manually by the .nrw support staff. Flagged names automatically create tickets within the support teamʹs issue system, which starts a workflow that ultimately decides whether the name is permissible (in which case the flag is removed) or invalid⁄illegal (in which case the name is deleted and the registrar gets notified).


c) Handling of IDNs

In the context of abuse prevention, the proper handling of Internationalised Domain Names (IDNs) becomes an important aspect.

If different IDN scripts were allowed to be mixed within one domain name, so-called homographs could be used to make users believe they are looking at a certain web site while it is actually a different one which name just has an identical or very similar visual representation. For example, since the Cyrillic letter ʺErʺ (ʺрʺ in Cyrillic script) in lower case has the same visual appearance as the Latin lower case letter ʺpʺ, mixing Latin and Cyrillic scripts would allow the creation of a domain name like ʺрayрal.nrwʺ, a homograph of the Latin-only name ʺpaypal.nrwʺ which, despite being a different word, looks exactly the same. Such a domain name could thus e.g. be used for spoofing or phishing attacks. The M+M GmbH prevents such abuse by implementing an IDN policy that disallows the mixing of scripts; within each label of a registered .nrw, only characters from a single script may be used.

Likewise, the Cyrillic-only second level domain ʺрор.nrwʺ looks identical to its Latin-only counterpart ʺpop.nrwʺ. If only the rule described above (no mixing of scripts) would apply, these two names could coexist for different registrants, and could thus be abused to confuse users. However, the special way the M+M GmbH handles such IDN variants while considering respective IDN tables and canonical forms of domain names, as described in detail in the answer to Question 44 (Support for Registering IDN Domains), prevents this situation; only one of these two domains may exist at the same time.

The M+M GmbH is aware that even within the same script (e.g., Latin), the use of diacritics may potentially cause similar confusion among users, e.g. if the ASCII-only name ʺpaypal.nrwʺ and a very similar one with diacritics (like ʺpáypàl.nrwʺ) are coexisting as completely separate registrations. However, after thorough consideration, it has been decided that the benefit of allowing situations like this is higher than the potential damage; in many languages, words with completely different meanings are created just via the use of diacritics, so quite useful domains would become blocked if diacritics would be considered for calculating a nameʹs equivalent variants. Consequently, the M+M GmbH does not perform this kind of blocking, but allows the names to coexist in such cases. Should the M+M GmbH receive reports about names utilising diacritics for abusive behaviour, other countermeasures described in this chapter will be applied to stop the abuse.


28.4 --POST-REGISTRATION ANTI-ABUSE MEASURES--
Even with policy implementation, oversight, and automated anti-abuse features, abuse registration and use may occur. In addition, innocuous domain names may be used for abusive purposes, such as phishing or spamming. Therefore, post-registration policies and procedures are designed to effectively and efficiently prevent and mitigate abuses with respect to registered domain names themselves and also their use.

 (1) Suspension⁄Cancellation: The policy framework allows us to suspend or cancel registrations that violate certain terms of the Registrant Agreement and related policies. We reserve the right to cancel or suspend any name that in our sole judgment is in violation of the terms of service. With cancelation, to the extent permitted by applicable law, we may publish notice of the cancelation on an anonymous basis, along with a rationale for the decision.

We believe that this step is important for several reasons: (i) It will help us keep the trust of Internet users, who will see that our actions are not arbitrary; and (ii) it will provide valuable additional information to users about which names are considered violations, by providing examples of names that have been canceled because they are offending terms.

In the case of clear-cut violations of the policies, we will take immediate action without refund of the registration fee.

 (2) Putting domain names in a “pending” status: In certain cases where we determine that a registration may be in breach of the policies, we may put a registration in “pending” status, in which the registration itself is not affected, but in which the domain name will not resolve. Names in a “pending” state can be restored to operational status. In this case, we will inform the registrant of the initial determination and provide the registrant with a speedy mechanism, such as the Complaint Resolution Service, to assist us in resolving the issue, or to appeal the decision.

 (3) Infringement of trademarks: With respect to registrations that infringe trademarks, ICANN has policies and procedures in place that provide a wide net of protections. These policies provide for very quick cancelation of obvious infringements via the Uniform Rapid Suspension (URS), and for less obvious violations, the UDRP. These policies are the result of many years’ experience and extensive negotiations with the trademark community. Additionally, these mechanisms are reasonably well understood by both trademark holders and registrants. We believe that abiding by ICANN’s established policies for dealing with alleged trademark infringing registrations provides the best level of protections for both trademark owners and applicants. We will make the URS and UDRP mandatory procedures for handling such disputes through contracts with the registrars.

A more detailed discussion of the rights protection mechanisms may be found in Question 29: Rights Protection Mechanisms.

 (4) Complaint Resolution Service (CRS): While ICANN has a number of procedures in place to prevent abusive registrations, especially with regard to violations of intellectual property rights, we will in addition implement a CRS. The CRS is a formal process that provides a low-cost, efficient, neutral, and clear-cut mechanism for complaints from the public concerning alleged illegal content, abusive or disruptive use of a domain name (e.g. phishing or spam) or other inappropriate conduct to be fairly adjudicated. The policies provide that the CRS is available to anyone, including rights holders. The CRS is a multi-step process designed to ensure fairness and is analogous to an ombudsperson process. It provides an easy method for lodging complaints while protecting registrants from arbitrary, harassing, or repetitive meritless claims. The CRS is described in detail in Question 29.

 (5) Trademark Claims Service (TCS): In addition to warning potential registrants prior to registration that their choice of domain name may infringe the rights of others, the TCS will inform trademark holders that a potential infringement of their mark has been registered. This will provide the trademark holder with the opportunity to challenge the registration, via the URS, UDRP, or court action. The TCS will provide means to inform trademark holders who have successfully deposited their trademarks in the Trademark Clearing House that a domain name has been registered that exactly matches their trademark.

28.5 --PROMOTION OF WHOIS ACCURACY--
As set forth in the Registrant Agreement, Whois Privacy Policy and related agreements we will take significant steps to collect and maintain complete and accurate Whois information.

To ensure Whois accuracy, the Registration Agreement requires that a registrant provides us with (i) true, current, complete, accurate, and reliable registration information; and requires (ii) that the registrant will maintain, update, and keep their registrant information true, current, complete, accurate, and reliable by notifying their registrar of a change to any such information in a timely manner. The Registration Agreement makes clear that providing true, current, complete, and accurate contact information is an absolute condition of registration of a domain name. Registrants are required to acknowledge that a breach of these provisions will constitute a material breach of the Registration Agreement, and that if any registration information provided during registration or subsequent modification to that information is false, inaccurate, incomplete, or misleading, or conceals or omits pertinent information, we may in our sole discretion terminate, suspend or place on hold the domain name of any Registrant without notification and without refund to the Registrant.

Whois accuracy verification at the point of registration as well as over the life of a registration will be carried out by the ICANN-accredited registrars pursuant to the terms of ICANN policy as embodied in the RRA.

Registrants are required to provide the following information to an accredited registrar, who will then provide it to us: (i) Legally recognized first and last name of the contact person for the registrant (this contact person may be the registrant itself), and if the Registrant is an organization, association, corporation, Limited Liability Company, Proprietary Limited Company, or other legally recognized entity, we require that the contact person must be a person authorized under the applicable law in the applicable territory to legally bind the entity; (ii) valid postal address of the Registrant; (iii) working e-mail address of the Registrant, and (iv) working telephone number for the Registrant, including country code, area code, and proper extension, if applicable. Attempted registrations lacking any of these fields will be automatically rejected by the system.

The Registration Agreement provides that the registrant is responsible for keeping the registrant information up to date and responding in a timely fashion to communications from registrars regarding their registered domain names.

Validation of Whois information prior to registration has not met with success among top-level domains. Historically, in many country-code top-level domains, pre-validation has been abandoned due to depressed user adoption and criticism from end users and industry businesses, such as web hosting companies, ISPs, and domain name registrars. With few exceptions, major registries validate Whois information after the domain name is delegated, if at all. This reduces cost, which keeps prices down and allows for the near-instant registration of domain names by ordinary registrants.

We will not use pre-delegation validation of registrant data. The strong policies against abusive registrations, combined with the easy-to-use CRS and active enforcement response, will better balance the needs of consumers and law enforcement or other users of Whois information than pre-verification, and in addition will result in higher customer satisfaction.

We will discourage illegitimate or abusive registrations by pricing our domain names above the price of .COM or .BIZ, which we believe will discourage various forms of noxious behaviors, as cybercriminals typically register large numbers of domains for their schemes and will therefore face a larger cost of doing business if they attempt to use the registry for their schemes. We therefore propose to price domain names at a wholesale cost higher than existing gTLDs as a way to discourage malicious use of second-level domain names. With fewer illegitimate registrations, we expect that Whois accuracy will be higher.

28.6 --ADEQUATE CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS--
The RRA provides that a registrar must ensure that access to registrant accounts are adequately protected, at a minimum, by secure log-in process that requires username and password authentication, and comport with other security related ICANN registrar accreditation requirements. Registrars must ensure that its connection to the Shared Registry System (SRS) is secure and that all data exchanged between registrar’s system and the SRS is protected against unintended disclosure. Registrars are required to use multi-factor authentication and encryption methods for each EPP session with the SRS using both a server certificate identified by the Registry and the registrar password, which is disclosed only on a need to know basis.

To protect unauthorized transfers of domain names, the registry generates a Unique Domain Authentication ID, or UDAI (also known as an “authorization code” or “auth code”), and provides the UDAI only to the registrant, in a secure manner. A UDAI is a randomly generated unique identifier used to authenticate requests to transfer domain names from one registrar to another. A UDAI is generated when a domain name is registered. Registrars will be obliged to promptly support domain transfers from qualified registrants upon request and may not withhold them to prevent a domain name from being transferred, nor may they require burdensome manual steps (such as requiring a signature) as a condition of transferring a domain name to a new registrar.

Registrars will further be required to identify a duly authorized officer (or similar senior manager) to handle cases where a company or organization wants to make changes but where the original registration was performed by an individual working for the company in his or her own name. For example, a company might hire a web developer to design a web site, and ask the developer to register a domain name, which they may do, but in his or her own name. The purpose of this policy is to prevent mistakes in the case of a transfer of ownership. The instructions on the change of registrant form must ensure (i) that the current authorized registrant is authorizing the changes; (ii) that the prospective registrant is identified and that all relevant contact information has been provided; (iii) that the prospective registrant acknowledges the changes and agrees to be bound by all of agreements and policies; (iv) that the process utilized by the registrar for the change of registrant process is clearly identified to registrants; and (v) that all documentation and correspondence relating to the transfer is retained. Registrars may request a statutory declaration where they have concerns about the authority to effect the change in registrant details if the registrars have concerns about the authority to effect a change in registration or any detail thereof and include an indemnity clause for any costs, losses, or liabilities incurred in the reasonable performance of their duties in processing the registrantʹs request, or in dealing with claims arising from the allocation or use of the name.

28.7 --ORPHAN GLUE RECORDS--
The registry policies and Shared Registration System (SRS) rules do not allow for orphan glue records in the zone. All glue records are automatically removed from the zone when the parent domain is deleted by the TANGO SRS. This automated registry software process prevents what are known as “fast-flux” phishing attacks.

28.8 --Resourcing Plans

The TANGO Registration System already supports the technical abuse prevention and mitigation measures above at the time of writing. No additional coding is required for this, which means that no special developing resources will be needed. Continuous audits and monitoring, as well as timely reactions to reports of malicious activity will be provided by the staff on duty at Knipp Medien und Kommunikation GmbH.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 7 man days
* System Administrator: monitoring setup: 3 man days
* First Level Support: training: 1 man day per person
* Second Level Support: training: 1 man day per person

For the ongoing maintenance, the following resources are allotted:

* First Level Support: 10 man hours per month
* Second Level Support: 20 man hours per month
* System Administrator: 3 man hours per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp Medien und Kommunikation GmbH in the past over the course of 12 months.

--PROTECTION OF LEGAL RIGHTS: A CORE OBJECTIVE--
Ensuring the protection of the legal rights of others is a core objective. We believe that protecting third-party rights enhances the reputation of the registry and encourages registrants. We are therefore committed to the protection of legal rights and have developed a series of mechanisms, including but not limited to, those minimum requirements for rights protection mechanisms as detailed in Specification 7. These mechanisms are intended to prevent infringing or abusive registrations and to identify and address the abusive use of registered names on an ongoing basis and in a timely manner. As part of this commitment, we have developed and will maintain and implement a series of related policies and practices specifically designed to prevent infringing and abusive registrations and uses of domains that affect the legal rights of others. We will take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD.

--OVERVIEW--
As well as implementing all ICANN rights protection mechanisms (RPMs), we will introduce other additional RPMs that go beyond the current ICANN protections.

In order to do so, we have developed a detailed policy framework based on best practices from the ccTLD .NZ, from the Council of Country Code Administrators (CoCCA), and from existing gTLDs. This tapestry of policies provides rules and procedures regarding registrant eligibility; sets out which type of names can be registered and which cannot; defines abusive registration and usage and provides for penalties for non-compliance; describes and implements ICANN-mandated RPMs; and binds registrars and registrants to the major policies.

The major policies are the Naming Policy, which defines which names can be registered, and by whom; the Acceptable Use Policy, which describes permitted and non-permitted uses of registered names; the Whois and Privacy Policy, which helps registrants understand what we can and cannot do with their personal data; and the Complaint Resolution Services (CRS).

Registrants are bound to these policies as a condition of registration through their contracts with their registrars, who are in turn compelled by us to get registrant consent to the policies as a condition of registration.

The Naming Policy first of all defines blocked and reserved names, which include geographical names at the second level, thereby adhering to ICANN rules and protecting the rights of the state of Nort Rhine-Westphalia and governments as a whole. Secondly, it prohibits the registration of infringing names and specifically binds registrants to ICANN RPMs. It contains provisions beyond ICANN RPMs, such as prohibiting multiple attempts at blocked names, either through the same or by using different registrars. The Naming Policy further provides that we may sanction registrants who do not abide by its provisions by revoking names (with or without refund) and in appropriate cases informing law enforcement.

The Acceptable Use Policy (AUP) addresses abusive use of second-level domain names, prohibiting spam, phishing pharming, malware, illegal content and other abusive uses of second-level domain, including abusive registrations, particularly registrations that infringe the rights of third parties. Many best practices concerning infringing registrations that were developed in among ccTLD world have in the gTLD world been superseded by Consensus Policies developed at ICANN. Where ICANN has procedures and policies, we follow them. Therefore, the AUP requires that registrants abide by the terms of the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension service (URS), and the Trademark Claims Services (TCS). Another ICANN-mandated rights protection mechanisms (RPM), the Sunrise Period, will be implemented as described later in this response.

Above and beyond the ICANN-mandated RPMs, the AUP contains provisions that exceed ICANN policy minimums to provide a higher standard of protection for the legal rights of others. The AUP allows us to suspend or cancel names, or multiple names by the same registrant, if an egregious use or pattern of abusive or infringing use is engaged in by a registrant. In addition, the Complaint Resolution Service (CRS) provides means for Internet users to alert us to abusive or infringing registrations.

Additional prevention or mitigation of abusive or infringing registrations include rapid takedown procedures; cancelation or suspension of multiple domain names registered to the same flagrant abuser; higher prices to discourage mass registrants of abusive names; and protection of second-level geographic names.

We first describe the implementation of ICANN-mandated mechanisms, then follow that with a description of the additional policies we plan to implement to prevent registration abuse and rights infringement.

--SUNRISE--
The Sunrise Period is mandated by ICANN, as per Section 6.2 of Specification 10 of the registry agreement. It is a process by which owners of legal rights have the opportunity to register domain names before the process opens to the public or others. Specifically, rights holders may use the Sunrise Service to assert a priority right to register a second-level domain which matches their eligible word mark, as defined in paragraph 7.2 of Specification 10 of the registry agreement. An identical match (as defined in paragraph 6.1.5 of Specification 10 of the registry agreement) is required between the eligible word registered in the Trademark Clearing House (“TCH”) and the domain applied for as a condition of participation in the Sunrise Period. All Sunrise applications will be validated by a third-party verification agent through the ICANN-mandated TCH to check the eligibility of the legal right claimed.

We will offer the Sunrise period for a minimum of 30 days during the pre-launch phase, and according to the terms of the Sunrise Policy. Applications received within that period are treated as filed at the same time. Where there is a contest between valid claimants, allocation will be determined by auction.

The Sunrise policy will provide for a Sunrise Dispute Resolution policy, which will allow a challenge under the four grounds required in paragraph 6.2.4 of Specification 10 of the registry agreement. Other grounds may be added as experience reveals their advantages.

Policy oversight of the Sunrise Service will be provided by the M+M LLC Vice-President of Policy, Peter Dengate Thrush. Peter is an international intellectual property barrister experienced in intellectual property cases, especially involving domain names. He was involved in ICANN’s Working Group A which developed the UDRP, and with the New Zealand Working Group which developed the Dispute Resolution Process for .NZ. Operational oversight of the Sunrise Period will be provided by Minds + Machines US´s CEO and Director of M+M GmbH, Antony Van Couvering. Antony is a veteran of several Sunrise periods as the head of a registrar (NameEngine) specializing in providing services to large brands and other holders of trademarks. We will provide all necessary infrastructure and sufficient resources to support the Sunrise Period.

--TRADEMARK CLAIMS SERVICE--
We will provide a TCS during an initial launch period for eligible marks as defined in paragraph 7.1 of Specification 10 of the registry agreement. This launch period will last at least the first 60 days of general registration, and will be operated according to the terms of Trademark Claims Policy.

The TCS allows a trademark owner to register a claim asserting trademark rights by putting potential registrants on notice of its possible legal claim of the domain name being considered for registration. We will provide notice in the approved format to all prospective registrants of domains that match trademarks in the TCH that their registration may infringe a trademark right. The mandatory form requires a prospective registrant to specifically warrant that: (i) the prospective registrant has received notification that the mark(s) is included in the TCH; (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.

Additionally, the Trademark Claims Notice will provide the prospective registrant with access to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the trademark rights being claimed by the trademark holder. These links (or other sources) will be provided in real time without cost to the prospective registrant. The Trademark Claims Notice will be provided in the language used for the rest of the interaction with the registrar or registry, and will be provided in the most appropriate UN-sponsored language as specified by the prospective registrant or registrar⁄registry.

Oversight of TCS will also rest with the Vice President of Policy (VPP). We will provide the necessary infrastructure and sufficient resources to support the VPP in this role, including adequate computers, connectivity, telephones including cell phones and administrative support.

Responsibility for implementing the customer-facing (registrar) aspects of the Trademark Sunrise Service and TCS will rest with the Registrar Liaison as part of their on-going responsibilities. Responsibility for the technical implementation of the Trademark Sunrise and TCS will rest with the Registry under the contract to provide registry services. TANGO’s engineers will maintain the functionality of the automated Trademark Clearinghouse system. No additional resourcing is required to support these functions, as they are part of the base level requirements for the Registrar Liaison and the CTO. We will pay fees to the TCH for Sunrise and TCS services. At the present time no fees details are available, but we assume that the higher fees we propose to charge Sunrise applicants during the 60-day TCS period will be sufficient to cover the fees likely to be charged by the TCH.

--PHISHING AND PHARMING--
Phishing and pharming are a kind of rights infringement in which the malefactor pretends to be a trusted source by using another’s trademark, brand look-and-feel, or other protected property in order to lure Internet users to perform some action that benefits the perpetrator. These practices are prohibited by the AUP and will result in cancelation of any second-level domain name involved, and possibly in cancelation of additional names registered to the abuser.

--POST DELEGATION DISPUTE RESOLUTION POLICY--
In the Registry Agreement with ICANN, we will agree to participate in all post-delegation procedures and to be bound by the resulting determinations. Because we are fully committed to combatting abusive use and abusive registration of second-level registrations, we do not expect to have occasion to be involved in any proceedings stemming from ICANN’s Post Delegation Dispute Resolution Policy (PDDRP), which deals with registries who knowingly engage in trademark infringement or abet those who do. We will comply with all Consensus Policies adopted by ICANN, including the PDDRP.

--ADDITIONAL ANTI-ABUSE POLICES--
We will be implementing RPMs and anti-abuse measures that go beyond the UDRP, URS, Sunrise, TCS and other ICANN-mandated mechanisms and procedures. These additional measures are detailed below.

--COMPLAINT RESOLUTION SERVICE--
The Complaint Resolution Service (CRS) is an alternative to litigation for resolution of complaints between the registrant of a domain name and a complainant who alleges a registrant or a domain name is in violation of the AUP. The CRS provides a transparent, efficient, and cost effective way for the public, law enforcement agencies, regulatory bodies, and intellectual property owners to address concerns regarding abuse on the system.

The CRS provides a reliable and simple way for the public to inform us if they think there is a problem. Submissions of suspected infringement or abuse are monitored by Registrar Customer Service personnel and escalated according to severity. Upon escalation, we may take immediate action to protect registry system or the public interest or refer the matter to law enforcement if we suspect criminal activity. In the case of a non-critical complaint, the CRS also provides an amicable complaint resolution and adjudication service conducted by an Ombudsperson hired by M+M LLC in cooperation with M+M GmbH. The Ombudsman will be specialized in German⁄European domain law. The CRS is a service intended to supplement parties’ existing legal rights to resolve a dispute in a court of law. Any proceeding brought under the CRS will be suspended upon any pleading to a court, decision-making body, or tribunal, and only re-started if directed to do so by one of those bodies.

The Ombudsperson is a neutral third-party specialist with respect to conflict resolution who will provide informal arms-length mediation and adjudication of any complaints of alleged registrant abuses and violations of the AUP.

If the Ombudsperson takes a decision that a domain name registration should be cancelled, suspended, transferred, modified, or otherwise amended, the Ombudsperson will implement that decision by requesting the Registry to make the necessary changes to the Register. The CRS provides for a right of appeal by registrants if they believe the AUP has been enforced in error.

--PROVISIONS OF THE ACCEPTABLE USE POLICY--
The AUP defines a set of unacceptable behaviors by domain name registrants in relation to the use of their domain names. It is incorporated into the Registrant Agreement. It defines the acceptable use of second-level domains, and is designed to ensure that the registry is used for appropriate and legal purposes.

The AUP specifically bans, among other practices, the use of a domain name for abusive or illegal activities, including:

 (i) illegal, fraudulent, misleading, or deceptive actions or behavior;
 (ii) spamming (the use of electronic messaging systems to send unsolicited bulk messages, including email spam, instant messaging spam, mobile messaging spam, the spamming of Web sites and Internet forums, and use of email in a Distributed Denial of Service (DDoS) attack);
 (iii) phishing (the use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data);
 (iv) pharming (the redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning);
 (v) willful distribution of malware (the dissemination of software designed to infiltrate or damage a computer system without the owner’s consent--e.g. computer viruses, worms, keyloggers and Trojan horses);
 (vi) 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);
 (vii) 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 DDoS attacks);
 (viii) distribution of obscene material, including but not limited to child pornography, bestiality, excessive violence;
 (ix) illegal or unauthorized access to computer networks or data (illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another party’s system, often referred to as “hacking,” or any activity that may be used as a precursor to an attempted system penetration, such as port scanning, stealth scanning, probing, surveillance or other information gathering activity);
 (x) deceptive or confusing uses of the domain or any content provided thereon with respect to any third party’s rights;
 (xi) disrupting the registry network or the provision of any content capable of disruption of computer or systems or data networks;
 (xii) providing circumvention technologies, technical information or other data that violates mandatory export control laws;
 (xiii) spoofing (forging email network headers or other identifying information); and
 (xiv) distribution of any other illegal or offensive material including hate speech, harassment, defamation, abusive or threatening content, or any other illegal material that violates the legal rights of others including but not limited to rights of privacy or intellectual property protections.

--MALWARE--
The AUP prohibits the use of the second-level domains to spread or install malware. Malware is software that is installed without the knowledge of the end user, or without the full understanding by the user of the software’s effects, which are often deleterious or dangerous. It should be noted that malware cannot be spread by the registration of a domain name. Where applicable, we will adhere to and implement the recommendations of NIST SP 800-83, “Guide to Malware Incident Prevention and Handling.” We have documented polices, processes, and procedures to mitigate operating system and application vulnerabilities that malware might exploit, as explained in further detail in our answers to Question 30: Security and Question 32: Architecture. We will implement a malware awareness program that includes guidance to users on malware incident prevention, detection and how to report suspect infections.

As recommended in NIST Special Publication 800-61, “Computer Security Incident Handling Guide,” we have instituted a robust incident response process to address malware, which has four main phases: preparation, detection and analysis, containment⁄eradication⁄recovery, and post-incident activity. In order to be prepared, we will implement malware-specific incident handling policies and procedures. As part of our detection objective, we will review malware incident data from primary sources and monitor malware advisories and alerts to identify likely impending malware incidents. We understand that we can play a critical role in the containment and eradication process of malware, and we will develop strategies and implement procedures, reflecting the appropriate level of risk, to contain and mitigate malware threats. The policies will clearly define who has the authority to make major containment decisions and under what circumstances various actions are appropriate. We reserve the right in contracts, and will not hesitate to use that right, to shut down or block services, such as email, that are used as vectors by malware producers. We also reserve the right and are prepared to place additional temporary restrictions on network connectivity to contain a malware incident, such as suspending Internet access or physically disconnecting systems from network, even while we recognize the impact such restrictions might have on organizational functions. Our strategy for the recovery phase from malware incidents is to restore the functionality and data of infected systems and to lift temporary containment measures. Our strategy for handling malware incidents in the final phase includes conducting a robust assessment of lessons learned after major malware incidents to prevent similar incidents from occurring in the future.

Additionally, we will work with the Anti-Phishing Working Group and other industry leaders, including ICANN working groups on phishing and pharming, to ensure that our practices allow parties to act quickly when a registrant is in violation of the policies. Finally, we reserve the right to immediately terminate any activity deemed, in our sole judgment, to be abusive, in violation of the AUP or related policies, or against the public interest.

--RAPID TAKE-DOWN PROCEDURES--
The AUP and related policies provide for a rapid take-down of abusive domains that are in violation of the policies, including mass domain shutdowns to act against DDoS, phishing abuse, and Botnet exploitation of domain names. Experience has shown that aggressive policy enforcement, combined with user-accessible complaint procedures to shut down obviously abusive names discourages malefactors, who have the option of registering in more loosely administered TLDs, such as .COM or .INFO.

--PROTECTION OF GEOGRAPHIC NAMES--
We will enact measures for the protection of country and territory names. The geographical names contained in the lists described in Specification 5 of the registry agreement will be added to the registry software system “prohibited word” function. Any attempt to register a domain containing those geographical names will be automatically denied, as they were similarly blocked in the .INFO TLD. See our answer to Question 22: Protection of Geographic Names for a more complete description of polices to protect geographic names.

--COMMUNITY FLAGGING--
We will use the common practice of community flagging of abusive uses of domains in order to rapidly detect a possible abuse so that a rapid response may be provided, including a rapid take-down of an abusive domain. Community members can easily flag a domain name as potentially abusive by filing notice through the Complaint Resolution Service. The CRS provides a “community flagging” mechanism that allows Internet users to report suspected violations and has proven to be an effective and speedy policy to prevent unwanted behavior.

--SUSPENDING MULTIPLE DOMAINS FOR FLAGRANT ABUSE--
The Registry reserves the right to suspend all domain names registered to or associated with any user for flagrant or repetitive abuse of any domain name as a means of preventing and curtailing abuse of the systems.

--TRANSFER FEES TO MITIGATE ABUSE--
To create a deterrent to abuse in the registry, we will charge registrants with a processing fee for transferring domains to another registrar or registrant. The transfer processing fee assessed will not be high, but will act as a deterrent by those who register multiple domain names for their schemes.

--QUALIFICATION OF REGISTRANTS--
The TLD .nrw is for registrant with a relation to North Rhine-Westphalia only (i.e. registration of office or address). Registrants will be advised before registration that they agree to the condition of having a relation to North Rhine-Westphalia. Pre-validation of the Whois information by postcode checking will be undertaken by our registry service provider Knipp Medien und Kommunikation GmbH.

Furthermore, our strong policies against abusive registrations, combined with the easy-to-use CRS and active enforcement response, will ensure legitimate registrations. 

We will discourage illegitimate or abusive registrations by pricing our domain names above the price of .COM or .BIZ, which we believe will discourage various forms of noxious behaviors, as cybercriminals typically register large numbers of domains for their schemes and will therefore face a larger cost of doing business if they attempt to use the registry for their schemes. We therefore will price domain names at a wholesale cost higher than existing gTLDs as a way to discourage malicious use of second-level domain names. With fewer illegitimate registrations, we expect that Whois accuracy will be higher.

--IMPLEMENTATION OF POLICY--
The Vice-President of Policy will oversee the management and maintenance of all policies and coordinate their implementation with TANGO’s technical staff and any third-party service provider partners. The VP of Policy will also be responsible for assuring that the policies are complied with by both registrars and registrants. We are committed to providing sufficient resources to ensure full functioning and effective implementation of these policies, as described below.

We will implement all decisions rendered under the URS and UDRP and courts of law in an ongoing and timely manner. We have designated the Vice-President of Policy as the URS Point of Contact (URSPOC) for proceedings brought under the URS against registrations in the Registry. The URSPOC will monitor the receipt of emails from URS providers informing that a URS complaint has passed Administrative Review, and will, on receipt of such an email, immediately arrange to lock the relevant domain name. Resolution services shall not be affected. The USPOC will also monitor emails from URS providers for determinations in URS cases, and will act on them according to their terms. In those cases where the complainant has succeeded in the URS complaint, the domain name status will be moved from “locked” to “suspended”, and will not longer resolve. Where a complainant has been unsuccessful, the domain name will be unlocked, with full control being restored to the registrant. If an appeal is filed, the URSPOC will monitor emails for any change of status resulting from such appeals. The software will designate the status of names during URS proceedings and provide for monitoring to ensure deadlines are met. In order to be able to monitor emails or phone calls and respond quickly, the VPP will be aided by one or more of the Registrar Customer Service representatives.

In the event that the rate of complaints is too high for existing personnel to handle, we will work to automate what can be automated, and hire additional staff as necessary. If a high percentage of complaints are nuisance complaints, or harassing complaints, we may institute a small fee for the Complaint Resolution service in order to prevent capricious use of the service.

Responsibility for maintaining and implementing technical protection mechanisms via the Registry software and hardware rests with the CTO. The CTO will be aided by TANGO engineers.

--RIGHTS PROTECTION MECHANISMS--
The Vice-President of Policy will oversee the management and maintenance of all the policies and coordinate their implementation with TANGO staff and any third-party service provider partners. The VP of Policy, in co-ordination with the Compliance Administrator, will also be responsible for assuring that the policies are complied with by both registrars and registrants. We are committed to providing sufficient resources to ensure full functioning and effective implementation of these policies, as described below.

In the event that the rate of complaints is too high for existing personnel to handle, we will work to automate what can be automated, and hire additional staff as necessary. If a high percentage of complaints are nuisance complaints, or harassing complaints, we may institute a small fee for the Complaint Resolution service in order to prevent capricious use of the service.

Responsibility for maintaining and implementing technical protection mechanisms via the Registry software and hardware rests with Minds + Machines’ CTO, who has worked extensively with enforcing Rights Protections in registries through software applications. The CTO will direct the technical team as necessary. The technical team will implement the trademark clearinghouse and sunrise services at the application level, including connecting to the TMCH, and managing the API for sunrise auction tools.

Our registry functions are outsourced to Knipp Medien und Kommunikation GmbH. All costs associated with the technical functioning of the registry are covered by Knipp Medien und Kommunikation GmbH as per our contract with them. 

--RESOURCING PLANS--

The TANGO Registration System already supports the rights protection features described above at the time of writing. No coding is required for this, which means that no special developing resources will be needed. The staff on duty at Knipp Medien und Kommunikation GmbH will be in charge of performing manual reviews of TM data where required.

Since the TCH API is not fully defined at the time of writing, some software development will have to be done in order to integrate it into the Sunrise workflow and the TCS.

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 5 man days
* System Administrator: configuring system for policies: 1 man day
* First Level Support: training: 4 man hours per person
* Software Developer: integration of TCH API: 10 man days

For the Sunrise phase, the following resources are allotted:

* First Level Support: 30 man days per month
* Second Level Support: 30 man days per month

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 1 man day per month

Employees already working for Knipp Medien und Kommunikation GmbH will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by Knipp Medien und Kommunikation GmbH in the past over the course of 12 months.

This chapter presents an abstract, high-level description of the security principles governing the operation of the .nrw TLD by the Minds + Machines GmbH. Since this part of the response is published, detailed information is not included in this part of the answer, however an exhaustive description of the employed security measures is presented in the answer to Question 30 b).

Knipp Medien und Kommunikation GmbH is currently in the process of being certified according to the ISO 27001 standard. The completion of the certification process is estimated for Q4⁄2012.


1. Security Policy

As Minds + Machines GmbH does not perform the technical operation of the registry itself, but has contracted Knipp Medien und Kommunikation GmbH for that purpose, Minds + Machines GmbH defines a general security policy framework that is imposed on itself, Knipp and all further contractors and subcontractors. All participating entities have to ensure that their security policies meet the requirements of the framework.

The security policy framework has the following key objectives:

* confidentiality
* access
* accountability
* availability

These objectives are further explained in the following.


1.1 Confidentiality

Confidentiality means the protection of private, proprietary and other sensitive information from entities that neither have a right or a need to gain access to it. Information includes, but is not limited to, registration data, registrar data, financial data, contracts, human resources data, and other business and technical data. To achieve this, all managed data are categorised into the classes ʺhighly sensitiveʺ, ʺconfidentialʺ and ʺpublicʺ, which then define the base levels for the respective protective measures. With respect to the determined classification, for each set of data it is defined

* where the data is stored,
* how it is backed up,
* what protective measures are taken both for the data itself and its backups,
* how long the data is retained and how it is safely destroyed once the information is no longer required,
* how it is protected from illicit access,
* how legitimate access and modification is controlled,
* to which extent the data has to be auditable and
* which regular audits are performed.


1.2 Access

Access defines the rights, privileges and the mechanisms by which assets of the Minds + Machines GmbH are being protected. Assets may refer to physical items like desktop computers, notebooks, servers, network devices and other equipment, or to logical items like registration data, e-mails and communication logs, passwords or cryptographic key material. For each entity (i.e., person or machine) that is granted access, it is clearly defined

* for which purpose the access is granted,
* to which level the entity can view or change the data, partially or in whole,
* which obligations are imposed on the holder of the access rights,
* at which frequency the grant is revisited, i.e. checked whether it is still required to uphold the grant.


1.3 Accountability

Accountability defines the responsibilities of staff members and management with respect to security aspects. This includes

* handling of passwords and security tokens,
* reviewing audit logs and identifying potential security violations,
* management of security and access control and
* reporting of potential security breaches.

Staff members are made aware of their responsibilities on the assignment of duties and on a regular basis.


1.4 Availability

For each facet of the registry operation, beyond the requirements of ICANN, it is determined which service level is required, i.e.

* the availability requirements, defining the desired relative availability over a period of time (typically one month), including the allowed maximum planned and unplanned outage times,
* the recovery time objective and
* the recovery point objective, if applicable.


1.5 Security Role Concept

For the Minds + Machines GmbH, the considerations above manifest themselves in an exhaustive security role concept, which defines roles carrying certain access privileges and responsibilities. Employees at the Minds + Machines GmbH are assigned one or multiple roles identified by this concept, which clearly defines their duties and access rights.


2. Security Commitments to Users of the .nrw TLD


2.1 Abuse Prevention and Mitigation

As discussed in detail in the answer to Question 28, the registry has taken various precautions to reduce the probability that the domain names within .nrw are being used in connection with abusive or criminal activities.

As the TLD string ʺnrwʺ represents a geopolitical region, the registration policy ensures that names of governmental or semi-governmental institutions can only be registered by the institutions themselves or their entrusted entities, thus assuring the users of these names that the names are actually under the control of these institutions.


2.2 Reliability and Availability of DNS

Various technical measures ensure a 100% availability of the DNS, as well as reliable, accurate and fast responses. A highly protected DNSSEC infrastructure ensures that the digital signatures contained in the DNS are trustworthy.


2.3 Technical Progress

The Minds + Machines GmbH is committed to employ state-of-the-art security measures on an ongoing basis. This includes, for example, the use of current and secure software, fast patches of security affecting bugs, and the adoption of new security related technologies as they become available.


3. Security Commitments to Registrants


3.1 Protection of Investment

With the commercialisation of the Internet, domain names have become valuable assets. Domain names are no longer simply a more or less convenient handle for cryptic IP addresses, but as brands they have become the base for whole businesses worth millions to billions. Also, with domain names, lifestyles (ʺtwitterʺ, ʺfacebookʺ generations) and communities are associated. Therefore, the loss, abuse or unavailability of a domain name, be it temporary or permanently, may cause significant damage to the domain name registrant.

The Minds + Machines GmbH fully recognises this. With its highly developed technical and administrative security framework, Minds + Machines GmbH has taken the necessary measures to protect the investments of registrants in their names. Due to the domain auto-renew mechanism, a valid domain is never deleted by the registry itself. In addition, the Redemption Grace Period provides extra protection if a request to delete the domain is inadvertently issued by the registrant himself or by the entrusted registrar. Also, if it can be proven that a domain has been illegally moved to a different registrant, this is reverted by the registry to to original state.


3.2 Adherence to Registration Policy

The registration policy clearly defines the conditions by which potential registrants may register domain names. The registrants can rest assured that the registry strictly adheres to these rules. In detail,

* The registry guarantees equal opportunity if multiple registrants meet the registration conditions in the same way.
* The registry applies a clear procedure for handling violations of the registration policy. The registrant has the ability to correct the violations before further actions are taken by the registry; he has also the right to appeal if he believes that the grounds for the registryʹs decisions are invalid.
* The registry maintains its neutrality in conflicts, unless forced by ICANNʹs Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS).


3.3 Privacy of Registrant Data

While the registry is strongly committed to data protection and privacy, only limited commitments can be made with respect to registrant data. This is owed to various requirements imposed by ICANN for the right to operate the registry.

First, the registry is required to provide so-called Registration Data Directory Services (RDDS). On the one hand, this allows the anonymous public to retrieve information on the registrant of a domain name. The registry tries to mitigate the impact by taking measures against data mining and by fully supporting EPPʹs disclosure settings, which allow the registrant (via the registrar) to restrict the exposure of specific data fields (within the limits of ICANN requirements).

On the other hand, as part of the RDDS, the registry is also required to grant access to the data to eligible users and institutions with legitimate interest, not limited to law enforcement agencies. The registry will monitor the activities of these entities and will withdraw the access if there are indications of excessive or abusive use.

Second, the registry has to give access to the registrant data to ICANN as part of the escrow requirement. While the data is encrypted by a public key of ICANN and thus safe from access by third parties, no guarantees can be given about the data handling by ICANN.

The registry adds a declaration about the data handling to the registration agreement in order to make a potential registrant aware of the limited privacy.