Application number: 1-1025-18840 for Taxi Pay GmbH

Taxi Pay GmbH

Persiusstr. 7
Berlin Berlin 10245
DE

+49 30 202021 101

+49 30 202021 719

http:⁄⁄www.taxi.eu

Mr. Hermann Josef Waldner

Managing Director

+49 173 269 02 01

hermann.waldner@taxi.eu

Mr. Benjamin Jonas Waldner

Assistant to the Managing Director

+49 176 100 27 323

ben.waldner@taxi.eu

GmbH

German Limited Liability Companies Act (GmbH-Gesetz)

Not Available

Hermann Josef Waldner
Managing Director

Jens Schmiljun
Director of Marketing
Jörg Schrader
Director of IT
Susanne Kausche
Director of Finance

Hermann Josef Waldner
Managing Director

taxi

Not Available

TaxiPay GmbH has carefully examined the applied-for string (incl. S.W.O.R.D test) and found that deployment of it would not cause adverse operational, rendering, or general user-confusion due to visual similarity with existing TLDs, ISO3166 lists, ICANN list of reserved names, or list of ineligible strings. It is safe to assume similar to existing ASCII-only TLD strings like .com, .net or .de, no operational or rendering problems should be expected. In particular, the string “taxi” consists entirely of ASCII letters 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. It constitutes a valid host name having at least three and less than 63 characters. The ASCII label is therefore in compliance with the string requirements set forth in the Applicant Guidebook (Applicant Guidebook, p. 64, 2.2.1.3.2 “String Requirements”) and with all technical standards such as, but not limited to, RFC 1035, RFC 2181, RFC 952, RFC 1123, and RFC 3696. Since the registry does not support right-to-left scripts on the second level, bi-directional issues (as described at http:⁄⁄stupid.domain.name⁄node⁄683) will not occur. Moreover, the gTLD string exclusively uses characters from a single alphabet, and contains characters that are not subject to homograph issues. This means that there is no potential for confusion with regard to the rendering of other TLD strings. However, TaxiPay GmbH is aware of its responsibility to mitigate and resolve possible issues, as discussed during the TLD Universal Acceptance session at the Costa Rica ICANN Meeting (http:⁄⁄costarica43.icann.org⁄meetings⁄sanjose2012⁄presentation-tld-universal-acceptance-14mar12-en.pdf). Such issues are: 1. Validity checks of TLDs based on either a hard-coded list (which may not be updated with all new gTLDs) or a length check (i.e. maximum of characters). 2. Name conversion in various applications and browsers. Based on wrong definitions or outdated lists of TLDs, some applications may not convert new gTLD to links. 3. User acceptance. Some websites or applications may regard email addresses or URLs entered by users as invalid, if they contain a new gTLD, with the effect of e.g. refusing registration. 4. Email clients validating addresses on the length of TLDs by applying an outdated list of TLDs may also cause problems, as valid email addresses may not be accepted. 5. Websites and search engines such as, but not limited to, Google, Yahoo, and Bing may refuse to offer services such as advertising, if they validate email addresses and valid domain names based on outdated definitions of TLDs, or simply refuse to add new gTLDs to their listsTaxiPay GmbH will work towards enabling general global acceptance of new gTLDs by consulting with registry operators, service providers, and software developers to ensure and encourage a quick adoption of new gTLDs on the internet namespace.

OVERALL MISSION
First and foremost, the gTLD .taxi will be used to assign a dedicated and recognizable namespace to members of the global taxi community, including individual entrepreneurs, offices, corporations, not-for-profit-organizations, relevant industry partners, such as special insurance providers, auto shops, hardware and software suppliers, and the like, as well as related divisions of public authorities, as described in full detail in the answer to question 20(a). The gTLD .taxi serves as a common online platform for all of the just named members, while offering each entity its individual domain space at second level. The overall mission of the gTLD .taxi is to foster the further growth and the long-term sustainability of the taxi community, as well as facilitate the establishment of online presences even for small players of the industry in order to lead the rather traditional industry to an innovative future. Designed and available for registration exclusively for members of the taxi community, the gTLD .taxi will be established as a label for both quality and trustworthiness of information. 

TARGET GROUP AND BENEFICIARIES
As such, the gTLD .taxi most importantly addresses two groups of users: The first one is the target group, representing individuals and organizations of the taxi community being considered as potential registrants. The second one is the group of beneficiaries, constituted by a variety of potential taxi clients, i.e. private individuals, private enterprises, not-for-profit organizations and public institutions without any entrepreneurial affiliation with the taxi community. Both groups are going to be delineated as follows. The target group that we are aiming to engage with consists of several subgroups. Firstly, the core taxi industry with taxi drivers, taxi offices, individual taxi entrepreneurs and other taxi companies, all of which can be clearly identified based on their taxi licenses, as well as a certificate of registration, i.e. a trade register excerpt. Secondly, the taxi community includes the members of the immediate surrounding industry, such as hardware and software suppliers, recruiting and training companies, auto shops, automotive suppliers, insurances and pertinent press all with a very strong if not exclusive focus on the just described core taxi industry. This particular community group is identified through certificates of registration, i.e. trade register excerpts. Thirdly, the community includes superordinate organizations, such as governmental organizations, public authorities and institutions and committees with the purpose of establishing relevant policies for the core taxi industry, as well as non-governmental organizations with the purpose of advocating taxi-related issues towards the public sector, the general public and relevant taxi industry representatives on a municipal, regional, national and international level. This group verifies its affiliation to the taxi community through a written, official and verified statement by its superordinate authority or a certificate of a verified register of associations. Fourthly, the taxi community includes affiliated businesses, such as owners of trademarks with a special interest in the products and services of the core taxi industry, such as major places of public interest (i.e. hospitals) or major events of public interest (i.e. Oscar Academy Awards).

PURPOSE AND BENEFITS
In addition to the just described target group, which is, of course strongly benefiting from the new gTLD .taxi, the group of beneficiaries is mainly defined by private individuals, not-for-profit, private and public entities with a user perspective regarding the taxi community, but no affiliation to the community itself. In order to demonstrate this, potential use cases are outlined in the following. Firstly, target group registrants could for example represent their profession. This could mean that a taxi office registers a domain to promote its services and attract business for all contracted taxi entrepreneurs and companies. The main purpose of such a domain at second level would be to address the public and stimulate consumer decisions. This would represent a mainly business-to-consumer-oriented approach. Secondly, closed discussion forums for members of the taxi community could be established under a .taxi-domain, addressing issues of relevant public policy or fostering an active exchange of interests within a relevant stakeholder group, for instance to stimulate business generation between direct members of the taxi community (drivers, offices, companies) and indirect members (insurances, auto shops, suppliers etc.). This represents an entirely business-to-business level. Thirdly, the whole not-for-profit community can build research networks, publication databases, and representative space all around a verified taxi namespace.

Furthermore, all internet users among the global population itself are considered a relevant audience benefiting from the new gTLD .taxi. As part of a rather traditional industry, taxis are naturally perceived as a means of transport from the point of being to a point of interest for private individuals or business travelers in urban areas, and represent a crucial alternative to public transportation in rural areas, especially. One of the main factors for this is a significantly higher level of comfort than public transportation – not only considering the equipment of the taxi itself (seating, speed of travel etc.), but also in terms of eliminating waiting time for busses, trains, subways and trams or knowing one’s way around a new place. Hence, when people look for information on taxi services, we anticipate them to be interested in a quick, reliable and safe source of information about a service that has become a day-to-day commodity for many of them. In this sense, the gTLD .taxi is facilitating the comparison of available services in terms of price, level of comfort, quality and reliability in a city, a region or a country, thus enabling consumers to choose the taxi service most suitable for them. In addition, the gTLD .taxi would serve as a means to find safe and secure personal transportation in countries, nations or regions with political or economic conflict.

FORECASTED DEMAND
In order to consider the gTLD’s introduction successful, TaxiPay GmbH expects to operate approximately 15,000 “.taxi” domains by the end of year 3 of registry operations. The forecast on registered “.taxi” domains is therefore as follows:

Year 1: 6,750
Year 2: 11,360
Year 3: 15,211

This forecast includes direct sales of domains to accredited registrars only. Moreover, this calculation accounts for an annual growth rate of 30%, and an annual termination rate of 2%.The business case in question 46 “Projections Template” will further illustrate the expected revenues from the registry business.

BEYOND MISSION AND PURPOSE
Yet, our purpose of hosting the respective gTLD goes beyond the mere provision of an additional Top Level Domain. When introducing a TLD for professionals in such a traditional community such as the taxi community, we believe that the respective TLD must be safeguarded against any fraudulent behaviour. Therefore, TaxiPay GmbH intends to make sure that only trusted organizations, communities, and individuals with an eligible purpose can register a domain and provide information under a “.taxi” TLD. In that way we will raise and sustain an always equally-high level of reputation and trustworthiness. As TaxiPay GmbH currently also operates taxi.eu, the largest online platform for the taxi community on a business-to-consumer level throughout Europe, the taxi community surrounding TaxiPay GmbH alone comprises at least 40,000 taxis in more than 50 European cities with more than 150,000 drivers. Thus, TaxiPay GmbH as the sole operator of the gTLD .taxi believes to be the ideal candidate for this purpose. 

GOALS, AREAS OF SPECIALITY, SERVICE LEVELS & REPUTATION
Inherently, the mission statement and the targeted audience as defined and described in question 18(a) strongly indicate the area of specialty the new gTLD .taxi is focusing on. The overall goal in terms of specialization is to establish and maintain a clear-cut focus on issues concerning the taxi community. We are fully aware of the fact that a variety of subtopics can be subsumed under this category. This is due to the varicolored and diverse shades of professions in this field and the formidable size of the topics themselves. Consequently, we expect to have a gray area of topics that might be only partially covered by the mission statement and that it is impossible to find and apply axiomatic rules that can adjudicate on every particular case. However, the goal has to be to diminish such cases to an absolute and inevitable minimum and at the same time maximize quality for the vast majority of topics. Additionally, we as the registry operator do not see our role as content discriminators as long as the overall mission and the registry agreement are maintained. Simultaneously, we completely commit ourselves to the community approach. In terms of service levels that the new gTLD .taxi will add, we expect two effects to occur. At first, we believe that with increasing penetration, the new gTLD will more and more become a label added to the second level domains. In fact, already today only two aspects of a website can indicate any information to the user about that site before even before visiting it: the second level and the top level domain. Whereas the second level domain can be defined at the registrant’s discretion, it will most likely testify something about the content a user will find on the respective website. However, this must not always be the case. A second level domain can also composed of imaginary terms or worse, fake and obscure words. A top level domain such as the proposed string .taxi however, cannot be altered by any registrant and will therefore remain the same for all second level domains in the zone. In coherence with thorough marketing measures promoting the gTLD .taxi as a quality label, the internet user can judge the content quality of a website. With the help of a joint mission statement, registration policies and a code of conduct, we believe that the label .taxi will indicate quality, security and reliability of information. The user will develop a maximum sense of trust towards .taxi websites and therefore be more likely to visit them when finding the need for information on the taxi community. As the element of trust also becomes more and more important for search engine operators such as Google or Bing, this development will also lead to a preferred status of .taxi websites in search results and consequently in a higher ranking, we assume. This has several implications for the reputation of registrants and their respective websites. On the one hand, registrants can now label the first user touch point of their website – the domain – with a gTLD that symbolizes trustworthiness, credibility, and accuracy. On the other hand, internet users are able to identify a valuable website without even visiting it, just by indication of the gTLD itself. The interaction of registrants and internet users enabled by a top level domain .taxi is largely oriented towards the similar effects of brands. Therefore, it is fair to say that the gTLD .taxi will certainly become an established brand or signet that websites have to qualify for. It will then hold true that if a website is assigned with the signet .taxi, it offers trustworthy and reliable information to the internet user.

EXCLUSIVE VALUE ADDED TO THE CURRENT DOMAIN SPACE
The introduction of the new gTLD .taxi does not necessarily create an entirely new competitive environment – it rather enhances and facilitates healthy competition amongst direct members of the taxi community, as defined in question 18(a). As mentioned before, internet users will be able to quickly identify and classify information presented among the namespace of the proposed gTLD .taxi. This may create a new competitive environment on an international level, given that all taxi brands worldwide will be united under one gTLD .taxi. However, the taxi industry is a very traditional industry with not only a strong national and regional focus regarding direct competition, but also a currently low online profile. Whereas many European taxi offices generally dispose of a second level domain, this is only true for the minority of taxi companies or individual entrepreneurs – hindering competition on the level of small businesses and making them largely dependent on larger offices and organizations. The gTLD is intended to serve the community as a whole. It has the ambition to become a label, brand, or signet which needs registry and the entirety of registrants pulling together in the same direction. To ensure this, we believe that the establishment of competition among all registrants applying for a .taxi gTLD will add quality to the namespace itself and the internet as a whole, which will then again benefit all internet users. As the gTLD will be on the one hand a sign of quality and reliability for internet users, it will on the other hand have positive effects for the respective website owners in terms of rising visits, higher publicity, and possibly an increase in revenue. Therefore, every .taxi website operator will strive for a high availability and impeccable quality of content type, information quality, and service availability. By doing so, they can make sure to remain eligible for receiving the signet .taxi.

As mentioned before, by introducing the new gTLD program, registry operators for the first time in internet history are able to offer a top level domain as a quality differentiation criterion. Differentiation by top level domain name adds value for both the target group (described in 18(a)) and internet users. It is commonly known that a product or service offering is in strong need for competitive differentiators and unique selling propositions in order to distinguish itself from competitors and achieve sustainable success. Website providers with content covering taxi-related topics will from then on have the chance to differentiate their offering from others via the unique label .taxi. This becomes especially important on the internet for two reasons. First, the individual internet user independently searches for such information and usually does so when in need of quick and safe transportation has usually already arisen. The user’s time to judge the quality and reliability of the found content then is limited. Second, websites requiring personal data and possibly even confidential credit card information are increasingly in danger of becoming victim to phishing attacks from online criminals at the cost of the potential or actual taxi transportation consumers. Therefore, the quality-controlled environment of a .taxi gTLD will avoid all such problems by highlighting and differentiating between all website operators that commit to the concept.

USER EXPERIENCE
As some aspects that have already been described earlier also enhance user experience, they will at first be briefly repeated before focusing on one or two new aspects. As mentioned before, we expect to help centralizing issues of interest and relevance for the taxi community on the internet and therefore aim to create a label or brand that offers the user a one-stop shop approach towards all facets of such topics. Accompanying effects will be the effect of higher trust for .taxi-labeled websites, the first-time possibility to evaluate website content quality before even visiting the respective site, and the assurance of quality, security and reliability of information. A new aspect of enhanced user experience concerns the group of taxi professionals as beneficiaries of the .taxi gTLD. From experience, we know that organizations and individuals belonging to such professions usually follow a very conservative approach towards information policies. As they operate in a traditional industry with almost no direct connection to the online world, this fact is not astonishing at all. However, especially this field is also heavily driven by persona relations and professional networks, which crucially rely on a continuous exchange of information. We believe that the gTLD .taxi can play a vital role in connecting professionals and encouraging communication. This is due to the fact that professionals will also identify the assured quality, reliability, and security of information provided and therefore more easily publish their information or engage in discussion forums for example. 

REGISTRATION POLICIES & PROTECTION OF PRIVACY
Only TaxiPay GmbH is in charge of defining clear, comprehensible, transparent and justifiable content boundaries. As such, TaxiPay GmbH will establish and maintain a holistic framework of requirements necessary to ensure controlled and well-regulated operations. Additionally, when considering dispute cases, we also think about integrating a third party as dispute resolution provider. Its task would be assessing the alignment of website content with the requirements raised in the mission statement, the registration policies and the code of conduct. At third, the community itself benefits from the establishment of a new gTLD .taxi and can therefore exploit global innovation processes. The former regionally-organized community parts will set out further, using synergies existing through the internet and their connector .taxi to expand and strengthen the common ground between each other. In order to ensure that all goals set in this document will be achieved after go-live, TaxiPay GmbH will establish a registration policy that determines the conditions a registrant can register a domain. Consecutively, the intended registration policies as well as their proposed outcome are described. First, an applicant for a .taxi second level domain has to submit roof of his or her affiliation with the taxi industry to the desired registrar. This process does not involve any formalities on the side of TaxiPay GmbH except an official document, such as a taxi license or a commensurate certificate of registration stating the purpose of the company and aligning it with a strong affiliation to the taxi community. This step is absolutely necessary and favors almost all goals directly or indirectly for the following reason. A validation agent on the side of TaxiPay GmbH will, in the event of disputes over registrations, manually check the required proof of affiliation in order to ensure the quality of this process, during which only relevant information is acquired from the registrant and data security is always in compliance with relevant laws and data security regulations. Therefore, outsourcing this activity to a third party would only harm the goal of assuring quality, security and reliability of information, especially as no costs will ever occur for the registrant. This procedure directly supports the goal of maintaining a target group solely consisting of members from directly and indirectly related taxi professions. Each applicant for a new .taxi second level domain will have to provide proof of being an eligible member of the community (please refer to question 20 for further details on eligible professions and organizations). Consequently, the TaxiPay GmbH has automatic and in some cases manual verification mechanisms in place (as described above). This supports the community approach providing a platform for safe and secure information addressed to both beneficiary groups, professionals and all internet users. Second, applicants will have to obligate themselves to strictly follow a Code of Conduct (CoC). The CoC will consist of a generic and a taxi-specific part. The generic part covers topics as following
- Second level domain name registration must not infringe upon the rights of others
- Second level domain name registration must not violate trademark (or any other) rights of others 
- Second level domain name registration must not, in any case, violate national and international laws
- Neither second level domain name nor content published under it can contain explicit or implicit pornography, violence glorification, political or religious extremism (including but not necessarily limited to fascism, Islamism, etc.)
- The registrant has a legitimate interest in the domain name
- The registrant does not act in bad faith
- The registrant and all respective activities must abide national and international laws
- The registrant agrees that in dispute cases, the verdict of a third party dispute resolution provider (such as a community audit, and according to ICANN’s dispute resolution processes) is binding

The taxi-specific part covers topics as following
- The registrant only publishes content relevant for taxi-related issues or indicating a strong connection towards it
- The registrant provides platforms for user-generated content only relevant taxi-related issues or indicating a strong connection towards it
- The registrant verifies all content that is published in his responsibility and thereby ensures quality fulsomeness and correctness in all conscience
- The registrant agrees that in dispute cases, the verdict of a third party dispute resolution provider (in accordance with ICANN’s dispute resolution processes) is binding

Besides, a particular domain name can only be registered if
- The name has not been registered yet
- The name is not reserved or blocked
- The name fulfills the technical and lexical requirements
- The name demonstrates a clear connection to the name or occupation of the registrant

Third, the applicant has to agree that a violation against any of the policies of the registration agreement may result in the loss of the registered domain. Fourth, TaxiPay GmbH will act upon request or complaint on the basis of the registration policies. Moreover the answers provided to questions 27 “Registration Lifecycle”, 28 “Abuse Prevention and Mitigation” and 29 “Rights Protection Mechanisms” describe more clearly in which cases TaxiPay GmbH will proactively agitate in means of supporting the goals listed above. Regarding measures of privacy and⁄or confidential information protection, we intend to adhere to all standards already set by other registries.

OUTREACH & COMMUNICATION
The TaxiPay GmbH has a great interest in transforming the project into a community success. First and foremost, we hope that our ambitious goals can be reached and the community members accept this revolutionary approach towards topic clustering and trust on the internet. Thus, TaxiPay GmbH feels that it is necessary to carefully lead the constituents of the taxi community onto a new level of communication, starting out by focusing strongly on classic above-the-line measures of direct marketing. We know that a reliable, transparent and consistent communication strategy over a long period of time is necessary in order to activate early-adopters and multipliers. Therefore, we plan to create an explanation of advantages of this project and carry out a steadily-timed communication plan, largely basing our communication on print media. During the start-up phase of the gTLD .taxi, we are planning to send out a print pamphlet to all members of our group of supporters (as described in question 20), large professional associations, i.e. the International Road and Transport Union (IRU), other important national taxi organizations, as well as all of their constituents down to a level of taxi offices. We also plan to send out yearly updates on important changes or announcements regarding the gTLD .taxi and updates on the development of the taxi community. Based on our own experience, we know that personal networking is a crucial factor for success within the taxi community. We therefore plan to supplement our classic marketing campaign with an informative roadshow throughout the most significant organizations and associations of the taxi community, mainly comprised of the group of our supporters (as described in question 20), but also large professional associations, i.e. the International Road and Transport Union (IRU). In the past two years, TaxiPay GmbH has also earned great awareness within the German market by using the means of public relations. We intend to continue following this path by focusing our PR activities on major business publications, both in Germany, the origin of the gTLD .taxi (i.e. “Wirtschaftswoche”, “Handelsblatt”), and internationally (i.e. “The Economist”, “Financial Times”), as well as targeting relevant and taxi-specific publications – also on a national and international level. Furthermore, we take an active part at fairs, conferences and conventions and the like to present the .taxi topic to a broad audience. 

MULTIPLE APPLICATIONS FOR ONE PARTICULAR DOMAIN NAME
One operating rule to eliminate social costs has been to assign domains on a first-come first-serve basis in the case of multiple applications for one particular domain name. The reason is that TaxiPay GmbH introduces the “.taxi” gTLD in order to benefit interested parties especially with taxi-focused background. This way, all relevant parties are granted with a fair and transparent opportunity to register their preferred domain name.
Otherwise by choosing to resolve multiple applications for a domain by conducting an auction, potentially only privileged registrants would be provided with their preferred domain name. As TaxiPay GmbH intends to avoid such a situation, a decision has been made in favour of a first-come first-serve allocation.

COST BENEFITS FOR REGISTRANTS
Moreover, TaxiPay GmbH commits itself to follow a pricing policy that sets reasonable prices, balancing prices on behalf of the registrants as members of the community, but to be able to finance registry services. Albeit the prices will be based on the registry business in which TaxiPay GmbH only has little control of the prices registrars are passing on to the registrants. TaxiPay GmbH has also decided against a landrush phase at the start-up of the gTLD-operation, due to the nature of the taxi community. As already described in question 18(a), the overall objective of the gTLD .taxi is to foster the further growth and the long-term sustainability of the taxi community, as well as facilitate the establishment of online presences even for small players of the industry in order to lead the rather traditional industry to an innovative future. Hence, the focus of the gTLD-operation is not at all on generating notable revenues, but rather to living up to the just described mission statement for the greater success of the community itself – high prices during a landrush phase might endanger smaller taxi businesses and must therefore be strictly averted.

MAGNITUDE OF PRICE ESCALATIONS 
Regarding anticipated increases of prices of domain registrations, TaxiPay GmbH cannot make any binding commitment today that no price increases will occur over the following ten years while running the registry services for the gTLD .taxi. Nevertheless, TaxiPay GmbH will commit itself to stable prices over the first three years of operation of the gTLD .taxi, as well as guarantee that beyond that, prices will only increase prices if necessary to follow economic or currency developments that necessitate price changes. They will not occur in order to maximize profit. However if price increases occur, TaxiPay GmbH will inform all registrars as well as ICANN following the Registry Agreement requiring written notice in advance of price increases. Further details on minimizing possible negative effects on consumers⁄registrants will be described in the answers to question 28 and 29.

Yes

COMMUNITY DELIANATION
The community the applicant is committing to serve is the global taxi community, including its four main community groups: Firstly, the core taxi industry with taxi drivers, taxi offices, and individual taxi entrepreneurs, all of which can be clearly identified based on their taxi licenses, as well as a certificate of registration, i.e. a trade register excerpt. Secondly, the taxi community includes the members of the immediate surrounding industry, such as hardware and software suppliers, recruiting and training companies, auto shops, automotive suppliers, insurances and pertinent press all with a very strong if not exclusive focus on the just described core taxi industry. This particular community group is identified through trade register excerpts. Thirdly, the community includes superordinate organizations, such as governmental organizations, public authorities and institutions and committees with the purpose of establishing relevant policies for the core taxi industry, as well as non-governmental organizations with the purpose of advocating taxi-related issues towards the public sector, the general public and relevant taxi industry representatives on a municipal, regional, national and international level. This group verifies its affiliation to the taxi community through a written, official and verified statement by its superordinate authority or a certificate of a verified register of associations. Fourthly, the taxi community includes affiliated businesses, such as owners of trademarks with a special interest in the products and services of the core taxi industry, such as major places of public interest (i.e. hospitals) or major events of public interest (i.e. Oscar Academy Awards). All just described member groups of the taxi community cater to internet users in general, as the ladder represent a large percentage of potential clients. Hence, there is a clear delineation based on the verification through a certificate of registration or a similar written statement ultimately identifying members of the four groups as members of the taxi community, and excluding the general group of internet users from this very community based on the non-existence of such a certification. Anyone not being able to verify his⁄her affiliation to the community based such a certification cannot register a second level domain under the gTLD .taxi.
STRUCTURE AND ORGANIZATION OF THE TAXI COMMUNITY
Although the global taxi community fulfills all given criteria that define a community, a single and overarching constituent part does not yet exist. Every vaguely qualified community organization faces some restrictions that disqualify said entity to fulfill this role. That is, for example, because only a limited region or number of countries are represented. Another reason lies in the scope of the content of an organization’s coverage. For example, many organizations focus their advocacy endeavors on different means of transportation at once (i.e. public transportation, car hiring companies and taxis), making it increasingly harder to access information exclusively focused on the taxi community. Even worse, most organizations are intentionally limited to regional coverage only – furthering the gap in-between individual members of the community. In almost every country, a multitude of organizations and associations exists, each being divided by different regional interests and greatly varying membership numbers. Additionally, the taxi community is subdivided mostly in small companies in a very traditional environment most importantly based on personal relationships and offline networks characterized by long decision-making cycles and widely ramified hierarchy in its structures as well as operations. Nevertheless, a community like this should eventually establish an adhesive force that guarantees an overall communication and organization network. Hence, TaxiPay GmbH is aiming at representing the interests of all organizations and individuals belonging to direct or indirect taxi professions in order to encourage increasing collaboration within the community itself.
COMMUNITY ESTABLISHMENT
As mentioned before, the community is largely based on values like hierarchy and personal relationships. One reason for this is the traditional nature of the service itself, but also the age of the community itself. The taxi community has its roots in the 17th century, where sedan chairs were first used to publicly transport persons of interest from point A to point B in Paris, France (1617) and Berlin, Germany (1668). Even at the beginning of the personal transport business, the price was dependent on the time it took to transport a person to the desired place of interest, only using an hourglass instead as taximeter. With the progressing industrialization, the taxi industry was increasingly established to the point of the first electric hackney in Berlin in the years of 1900. Only seven years later, in 1907, the first organization to regulate the taxi business and foster the exchange amongst drivers, the “Verein der Kraftdroschkenbesitzer” (Association of Owners of electric Hackneys) was founded in Berlin.
SIZE OF COMMUNITY, MEMBERSHIP & GEOGRAPHIC EXTENT
Today, the taxi industry is one of the most developed industries in terms of availability of its services and its perception as a basic means of transport in the developed world. Though widespread, the taxi industry also proves to be one of the most fragmented industries in the world. Strictly speaking, a taxi is defined as a type of vehicle for hire with a driver, used by a single passenger or small group of passengers, often for a non-shared ride. This vehicle may very well be a middle class car, but can also be a horse carriage, bike, motorbike or even a pedicab, depending on the state of a country’s development. Thus, the actual current size of the taxi community can only be estimated. Due to the absence of a worldwide taxi organization, official numbers on the global size of the community do not exist, and are only partially existent for individual countries or regions. Therefore, TaxiPay GmbH has undertaken a calculative estimate on its own, and has verified the hypotheses and numbers with its immediate supporters (see question 20(f)). The basis for the calculation of the size of the community is the size of the world population, as announced by the United States Census Bureau in 2011, in the amount of approximately 7.005 billion people. Already taking into account differences between developed, emerging and developing countries, as well as urban and rural areas, TaxiPay GmbH believes that there is an average of 0.2 taxis per 1,000 world citizens. Concluding, there are about 1.5 million taxis worldwide. The geographical reach, as TaxiPay GmbH perceives it, spans as far as the word “taxi” can be understood or associated with the taxi industry itself. This includes all languages related to English, Spanish, French, German, Italian, Portuguese and Russian. It also includes all North, Middle and South American countries, all of the Anglo-Saxon and Francophone African continent, Europe including Russia as well as most Asian counties, especially countries with former bonds to the Commonwealth. Recent activities of the taxi community include the discussion on the level of centralized regulation of the various international taxi sectors, the preparation for the upcoming mobile revolution by developing smartphone applications for ordering and sharing taxis in large urban areas, as well as the initiative of increasing the percentage of green taxis operated on biofuel.

RELATIONS TO COMMUNITY ORGANIZATIONS
In accordance with the answer to question 20(a), the taxi community currently lacks a single and overarching international umbrella organization. Even though there are a handful of organizations with a global claim, none of those comes close to even covering the majority of all community organizations. TaxiPay GmbH is on good terms with a multitude of organizations and with representatives of such organizations, as well. It is the strong interest of TaxiPay GmbH to establish long term and sustainable relationships with stakeholders, thus creating a network based on all four major constituent parts of the taxi community (compare answer to question 20(a)): The core taxi industry, members of the immediate surrounding industry, superordinate organizations and affiliated businesses. TaxiPay GmbH is therefore proud to count the following community organizations to its major supporters of the application for the gTLD .taxi:
RELATIONS TO THE COMMUNITY AND ITS CONSTITUENT PARTS & GROUPS
- Taxiverband Deutschland e.V.: In 1999, the organization was founded in Stuttgart as a Federal Association of German taxi and car-hire businesses. The Taxiverband Deutschland e.V.’s constituents are over 8,000 taxi entrepreneurs and companies – over 3,000 more than the once largest German Taxi trade Association BZP. Taxiverband Deutschland e.V. and TaxiPay GmbH have been very closely cooperating since 2005 on advocacy issues regarding the further development and the influence of public policy relevant to the taxi industry.
- Taxi Deutschland e.V.: The organization was founded in 2008 by Stuttgarter Taxiverband (Taxi Association Stuttgart), the Federal Taxi Associations of Schleswig-Holstein, Lower Saxony, Berlin and Brandenburg, as well as two taxi associations of the State of Hamburg. Thus, Taxi Deutschland e.V. represents a major portion of regional German taxi companies, associations and entrepreneurs. Taxi Deutschland e.V. and TaxiPay GmbH have been very closely cooperating since the foundation of Taxi Deutschland e.V. in 2008. The cooperation grew so close that Taxi Deutschland e.V. has even moved its headquarters to the same premises as TaxiPay GmbH so as to demonstrate a clear commitment to the long term nature of the stakeholder relationship.
- fms Datenfunk GmbH and Austrosoft® Weiss Datenverarbeitung Ges.m.b.H.: Both companies are in a close business relationship with TaxiPay GmbH. The fms Datenfunk GmbH was founded in 1999 and works works to form a lobby for the taxi business, and actively participate in improving the economic and legal environment on a federal, provincial and international level. Austrosoft was founded in 1982. The company develops a fleet management system (FMS). Austrosoft and TaxiPay GmbH have been cooperating very closely since 2007. TaxiPay GmbH itself is using Austrosoft’s software for its business operations. Together the two companies constitute Eurocap Group.
- Taxi 40100 Taxifunkzentrale GmbH: Taxi 40100 Taxifunkzentrale GmbH was founded in 1963 in Vienna, Austria, and operates as a switching center for taxi reservations. Taxi 40100 counts over 1,500 taxis in Vienna alone and is therefore one of the largest operators in Austria. Taxi 40100 Taxifunkzentrale GmbH and TaxiPay GmbH have been operating closely together since 2007. Primarily, TaxiPay GmbH and Taxi 40100 Taxifunkzentrale GmbH share information related to upcoming issues in the taxi business, and develop new action plans for the further development of the European taxi community.
- IsarFunk Taxizentrale GmbH & Co. KG: Isarfunk was established in 1999 and is since then operating in the metropolitan area of Munich as an intermediary between passengers and taxi drivers. The company coordinates more than 1,000 contracted taxi drivers. Isarfunk and TaxiPay GmbH have been cooperating very closely since 2007. For instance, the two companies have successfully and jointly developed the smartphone app “Collexio” which offers fully automatic billing on just one platform for taxi sharing.
- Hansa Funktaxi eG: Hansa Funktaxi eG was established in 1973 in Hamburg, Germany. Today, the company is the second largest switching center for taxis in Hamburg. The registered radio taxi cooperative consists of about 700 members. Hansa Funktaxi eG and TaxiPay GmbH have been cooperating very closely since 2006, most notably on the development of taxi.eu – the largest European online platform for taxi reservations.
- WBT Wirtschaftsgenossenschaft Berliner Taxibesitzer eG: Established in 1938, the company developed into the of the most advanced service provider for passenger transport. Today, the company is specialized in the area of operating as a switching center. In addition, WBT offers a special transport service for people with disabilities on behalf of the State of Berlin. WBT and the Managing Director of TaxiPay GmbH, Hermann Waldner, have been working together very closely since 1983. Even though the two companies are competing on the same market, they cooperatively strive to further develop the taxi business.
All of the just described community organizations share two main characteristics: Firstly, all of the named organizations have close ties to the International Road and Transport Union (IRU) – an international organization that works to facilitate road transport worldwide and ensures its sustainable development. The IRU is no taxi-specific organization, which is why TaxiPay GmbH maintains only indirect ties to the organization. Secondly, all of these organizations share a common interest of elevating the taxi community onto a new level of professionalism. As described in the answers to question 18(a) and 20(a), the core taxi industry is operating mostly offline, due to the offline nature of the taxi service itself. Therefore, TaxiPay GmbH has initialized a project to catalyze the achievement of this objective by launching “taxi.eu” – the largest European online platform for taxi reservations. The consumer-centric online platform facilitates the ordering process of taxis based on an iPhone⁄Android application, as well as a mobile device optimized browser option. Based on this app, taxi drivers are able to attract new, tech-savvy and usually financially strong customers. Based on taxi.eu, TaxiPay GmbH establishes a crucial connection between the taxi community’s constituents and potential customers, and currently represents over 40,000 taxis with 150,000 drivers in over 60 major cities throughout Europe.
ACCOUNTYBILITY MECHANISMS TO THE COMMUNITY
Although there are no established and formal accountability mechanisms between TaxiPay GmbH and the taxi community, TaxiPay GmbH is fully aware of its general accountability and responsibility towards the community itself. A large group of passengers and taxi companies already rely on the services provided via taxi.eu. The added value of the information supplied and demanded on a daily basis, the business that is generated, and the inherent business relationships between all organizations connected with taxi.eu constitute a vital part of the professional life of a not negligible part of the community. By applying for .taxi, TaxiPay GmbH is fully dedicating itself to being a transparent, trustworthy and accountable representative of the taxi community and all of its constituent individuals, parts, groups and organizations.

The overall objective of the gTLD .taxi is to foster the further growth and the long-term sustainability of the taxi community, as well as facilitate the establishment of online presences even for small players of the industry in order to lead the rather traditional industry into an innovative future, and support healthy competition amongst all members of the taxi community, as described in question 20(a). The gTLD .taxi will be established as a label for both quality and trustworthiness of information for all members of the taxi community and end users. The community-based purpose of the applied for gTLD .taxi is to provide a namespace as a safe and secure home base for all topics relevant to the entire taxi community. All community members should consider the .taxi as a cooperation of reliable, skilled, trustworthy and most notably verified professionals concerned with similar issues and a professional attitude towards their work life. The gTLD should encourage the community and its members to play an active role in the exchange of information and knowledge and the organization of community issues. Ideally, this strengthens the bonds between the individual member and the higher goals and interests that aid and promote the community. Therefore, the centralization and professionalization of the presentation of taxi-related websites, services, individuals and organizations, creates an identity that community members can identify themselves. Above all, the .taxi gTLD encourages and improves the provision of a solution accessible for every internet user worldwide in terms of providing information and services on taxi-related topics.
INTENDED REGISTRANTS IN THE TLD .TAXI
Consecutively, intended registrants for the gTLD .taxi are all community members. Please find an overview on intended registrants in question 20(a). The .taxi gTLD addresses, but is not limited to, the following use cases: Primarily, .taxi should provide a namespace for all members of the taxi community for representing themselves, their businesses or occupations, and their day-to-day work. Possible webpages could range from, among others, introductions of taxi and taxi-related businesses, overarching taxi services of relevance to community members as well as potential taxi clients (i.e. online reservation platforms), or other information that is worth being published to an open or limited public. Second, community members could for example publish content regarding special events for the taxi industry, for instance relevant international industry conferences or regional meet-ups between individual stakeholders. Third, they should be able to use the .taxi namespace for research and aggregation of useful information they can apply to their daily work or their profession, for instance information on public policies and the status of policy-making (i.e. safety regulations for vehicles, pricing policies etc.).Last, the secured namespace should encourage members of the taxi community to engage in communication and exchange of information. As access to such websites and services with .taxi domain is restricted and therefore a certain level of quality is guaranteed, it is expected that community members will experience as greater tendency to do so than today.
INTENDED END-USERS IN THE TLD .TAXI
Apart from the community members, who are intended registrants as well as beneficiaries, TaxiPay GmbH expects all internet users to be another important group of important beneficiaries. Thus, end users of the gTLD .taxi will be all community members as well as all internet users (please refer to question 18(a) for more details). As end-user use cases have already been described for community members in the intended registrant section, it should now be concentrated on end-user use cases for internet users. First, internet users not directly related to the taxi profession are able to identify and evaluate the great variety of different taxi services and their respective locations. They can plan trips ahead and inform themselves about pricing levels, timing (i.e. trip duration), as well as special features of the respective vehicles (i.e. air conditioning). Second, there is a growing tendency of people demanding information and knowledge about the businesses they commission, especially against the backdrop of a growing awareness for ecological sustainability and a “green” lifestyle. Regarding taxi services, the majority of consumers are increasingly concerned with using taxi vehicles with alternative sources of energy, i.e. hybrid or biofuels. People connected to the internet widely use it as a source for information and research, which is why a designated taxi-specific namespace could function as a first point of contact and signpost for people with an interest in various options of taxi services. Third, webpages and services could complement business-to-consumer-relationships by providing additional information and simplifying communication. Fourth, members of the core taxi industry could benefit from services offered by the immediately surrounding industry, such as hardware and software suppliers, recruiting and training companies, auto shops, automotive suppliers, or even insurances all with a very strong if not exclusive focus on their special needs. Providing simple and quick access to relevant websites of these suppliers combined under a .taxi gTLD will therefore facilitate business-to-business relationships within the taxi community, too.
RELATED ACTIVITIES
Apart from the application for the new gTLD .taxi, TaxiPay GmbH is currently providing an additional service to the community with taxi customers as the main beneficiaries. In January 2012, TaxiPay GmbH has initialized “taxi.eu”, the largest European online platform for taxi reservations. The consumer-centric platform facilitates the ordering process of taxis based on an iPhone⁄Android application, as well as a mobile device optimized browser option. Based on this app, taxi drivers are able to attract new, tech-savvy and usually financially strong customers. Based on taxi.eu, TaxiPay GmbH establishes a crucial connection between the taxi community’s constituents and potential customers, and currently represents over 40,000 taxis with 150,000 drivers in over 60 major cities throughout Europe. Apart from merely connecting members of the core taxi industry with clients, taxi.eu serves to achieve the very same mission as the gTLD .taxi – that is to foster the further growth and the long-term sustainability of the taxi community, as well as facilitate the establishment of online presences even for small players of the industry. The end-user, on the other hand, greatly benefits from the platform as ordering, rating, saving and planning personal transportation is facilitated to written information on the end-users mobile device and at hand anytime when needed.
LASTING NATURE OF COMMUNITY PURPOSE
As described earlier in the answers to these questions and question 18, the .taxi network is a first step towards a cross-professional taxi association providing organizational and communicational services to the global community. This is especially important, as the community will certainly remain intact as long as people will feel the need for means of private, comfortable and fast transportation. As mentioned in question 20(a), the taxi community belongs to the oldest communities in modern history. Furthermore, increasing gas prices have already and will continue to cause private individuals and households to either significantly reduce the usage of their own automobile or even going without any household automobile, at all, due to a growing price consciousness. Of course, an unspecified percentage of these households and companies will refrain to public transportation. However, consumer groups with a larger price elasticity will most certainly maintain their need for safe, comfortable and fast transportation to their point of interest. 

RELATIONSHIP TO THE ESTABLISHED NAME
The relationship between the applied-for gTLD string “.taxi” and the taxi community identified in the answer to the question 20(a) is based on the largest common name denominator between all members of the taxi community, as well as its direct beneficiaries. The word “taxi” describes the center of the taxi community, which is the taxi service and vehicle itself – the very object that all community groups, namely entrepreneurs and companies of the core taxi industry, members of the immediate surrounding industry (i.e. suppliers), superordinate organizations and affiliated businesses, as well as its beneficiaries, namely current and potential taxi customers, have in common. For entrepreneurs and companies of the core taxi industry, the gTLD .taxi reflects the core service they provide, as well as the name of the automobile used to carry out this service. For members of the immediate surrounding industry, the name “taxi” represents the name of the core service of their essential customer base. For superordinate organizations, the string “.taxi” represents an industry and a group of professionals that they are working to represent or to develop policies for. For private and corporate customers, as well as for affiliated business as described in the answer to question 20(a), the string “.taxi” represents the service they are looking to commission or the rough industry description of the businesses they strive to engage in a business relationship.
RELATIONSHIP TO THE IDENTIFICATION OF COMMUNITY MEMBERS
Furthermore, the term “taxi” translates not only in the English language, but also in over 70 other languages worldwide, among others in four of the six United Nations languages, namely Spanish (taxi), French (taxi), Russian (такси, pronounced similar to English), as well as Japanese (タクシー, pronounced similar to English), German (Taxi) or Portuguese (taxi). Similar examples can be found in almost all other Romance and Germanic languages which accumulate to 1.2 billion native speakers and 1.55 billion including non-native speakers. In most countries, especially those with a regular and large income of tourists, the English word “taxi” will be printed on official and registered taxi vehicles. In all these languages, the abbreviation .taxi will, because of its word stem, automatically evoke a connection to the taxi service, but not only to community members but to every speaker of such languages. This is also an explanation for the geographic layout of the community given in the answer to question 20(a). Additionally, English (as one of the Germanic languages) is the most widespread language used in the tourism sector, of which the core taxi industry is a crucial part.
POSSIBLE OTHER CONNOTATIONS BEYOND THE COMMUNITY
In addition, the term “taxi” has long been established, and is very likely not object to any changes in the near future. The word “taxi” is the short form of the taximeter cab (introduced in London in March 1907), from “taximeter” (automatic meter to record distance and fare) from the French “taximeter”, from the German “Taxameter”, which was coined from the Latin taxa (tax, charge) from “taxo” (to evaluate, to put in an order, to fix the value of a thing, to rate, to tax, to touch), and from the Greek verb “tasso” (to put in an order, to fix the value of a thing; τάσσω). Because of the strong lingual connotation of the string with the taxi community itself, we could not find any other realistic cases of connotations differing from this case.

ELIGIBILITY
In order to ensure that all goals set in this document will be achieved after go-live, TaxiPay GmbH will establish a registration policy that determines the conditions a registrant can register a domain. Consecutively, the intended registration policies as well as their proposed outcome are described.
First, an applicant for a .taxi second level domain has to submit proof of his or her affiliation with the taxi industry to the desired registrar. This process does not involve any formalities on the side of TaxiPay GmbH except an official document, such as a taxi license or a commensurate certificate of registration stating the purpose of the company and aligning it with a strong affiliation to the taxi community. This step is absolutely necessary and favors almost all goals directly or indirectly for the following reason. A validation agent on the side of TaxiPay GmbH will, in the event of disputes over registrations, manually check the required proof of affiliation in order to ensure the quality of this process, during which only relevant information is acquired from the registrant and data security is always in compliance with relevant laws and data security regulations. Therefore, outsourcing this activity to a third party would only harm the goal of assuring quality, security and reliability of information, especially as no costs will ever occur for the registrant. This procedure directly supports the goal of maintaining a target group solely consisting of members from directly and indirectly related taxi professions. Each applicant for a new .taxi second level domain will have to provide proof of being an eligible member of the community (please refer to question 18(a) for further details on eligible professions and organizations). Consequently, the TaxiPay GmbH has automatic and in some cases manual verification mechanisms in place (as described above). This supports the community approach providing a platform for safe and secure information addressed to both beneficiary groups, professionals and all internet users. Only the predefined members of the taxi community are eligible to register a domain under the gTLD .taxi at second level. These namely include the core taxi industry with taxi drivers, taxi offices, individual taxi entrepreneurs and other taxi companies, all of which can be clearly identified by their taxi licenses, as well as a certificate of registration, i.e. a trade register excerpt.
Secondly, the taxi community includes the members of the immediate surrounding industry, such as hardware and software suppliers, recruiting and training companies, auto shops, automotive suppliers, insurances and pertinent press all with a very strong if not exclusive focus on the core taxi industry. These can be identified by their certificates of registration, i.e. trade register excerpts.
Thirdly, the community includes superordinate organizations, such as governmental organizations, public authorities and institutions and committees with the purpose of establishing relevant policies for the core taxi industry, as well as non-governmental organizations with the purpose of advocating taxi-related issues towards the public sector, the general public and relevant taxi industry representatives on a municipal, regional, national and international level. This group verifies its affiliation to the taxi community through a written, official and verified statement by its superordinate authority or a certificate of a valid and verified register of associations.
Fourthly, the taxi community also includes affiliated businesses, such as owners of trademarks with a special interest in the products and services of the core taxi industry, such as major places of public interest (i.e. hospitals) or major events of public interest (i.e. Oscar Academy Awards).
SECOND LEVEL STRING SELECTION
The applicants will have to obligate themselves to strictly follow a Code of Conduct (CoC). The CoC will consist of a generic and a taxi-specific part.
The generic part covers topics as following
- Second level domain name registration must not infringe upon the rights of others
- Second level domain name registration must not violate trademark (or any other) rights of others
- Second level domain name registration must not, in any case, violate national and international laws
- Neither second level domain name nor content published under it can contain explicit or implicit pornography, violence glorification, political or religious extremism (including but not necessarily limited to fascism, Islamism, etc.)
- The registrant has a legitimate interest in the domain name
- The registrant does not act in bad faith
- The registrant and all respective activities must abide national and international laws
- The registrant agrees that in dispute cases, the verdict of a third party dispute resolution provider (such as a community audit, and according to ICANN’s dispute resolution processes) is binding
- The registrant agrees that name of the chosen second level domain has to contain major parts, if not the full name of the registrant’s company⁄ organization⁄ affiliate business
In addition, a particular domain name can only be registered if:
- The name has not been registered yet
- The name is not reserved or blocked
- The name fulfills the technical and lexical requirements
- The name demonstrates a clear connection to the name or occupation of the registrant
CONTENT & USE
The taxi-specific part covers topics as following
- The registrant only publishes content relevant for taxi-related issues or indicating a strong connection towards it
- The registrant provides platforms for user-generated content only relevant taxi-related issues or indicating a strong connection towards it
- The registrant verifies all content that is published in his responsibility and thereby ensures quality fulsomeness and correctness in all conscience
- The registrant agrees that in dispute cases, the verdict of a third party dispute resolution provider (in accordance with ICANN’s dispute resolution processes) is binding
The applicant has to agree that a violation against any of the policies of the registration agreement may result in the loss of the registered domain.
ENFORCEMENT
TaxiPay GmbH ensures, based on the Registry Agreement, that its commissioned Registry Service Provider will validate a registrant’s eligibility for a domain at second level under the gTLD .taxi, and will act upon request or complaint on the basis of the above described registration policies. TaxiPay GmbH itself, however, will provide an in-house validation agent in order to be able to react quickly upon possible cases of abuse and⁄or arising disputes. The main responsibility of the just mentioned validation agent is to double-proof a registrant’s eligibility for the respective domain at second level.
TaxiPay GmbH will additionally:
- Develop a trusted method of communication for all correspondence between the TaxiPay GmbH and the TLDʹs registrars, to ensure that all registrant contact information, including WHOIS records, is complete and remains current, and that all requests for registration within the space may be easily verified for authenticity.
- Implement effective mechanisms for addressing abusive practices.
- Establish a point of contact for third-party reporting of abusive practices.
- Ensure accurate WHOIS data by implementing and enforcing a strict registration and validation policy. The Registry-Registrar Agreement will furthermore include the obligation of accredited registrars to validate and verify each registration request.
- Determine and implement a streamlined practice for addressing and removing orphan glue records.
- Publish on its website and include as binding registry policy an Anti-Abuse Policy, described in detail below, which provides applicable definitions of abuse and outlining steps TaxiPay GmbH will take to address any such situations.
Moreover, the answers provided to questions 27 “Registration Lifecycle”, 28 “Abuse Prevention and Mitigation” and 29 “Rights Protection Mechanisms” describe more clearly in which cases TaxiPay GmbH will proactively agitate in means of supporting the goals listed above.

Not Available

No

In accordance with Specification 5, TaxiPay GmbH will not allow reservation of the following country and territory names at the second- and other sub-level:
- The short form in English of all country and territory names contained in the ISO 3166-1list, including all updates made to it
- The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries in the World
- The list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names 
The names of countries and territories specified in the lists above will be reserved at the second and all other levels of the “.taxi” TLD and thus, will not be available for domain name registration. A release of such a domain name will merely take place following an agreement with the respective government as well as after official approval by ICANN. This release process will follow the guidelines that have been set out by the GAC. Thus, the relevant authority wishing to reserve its specific name will need to inform the GAC Secretariat. After authentication, the GAC Secretariat will transfer the request to ICANN and TaxiPay GmbH. TaxiPay GmbH will verify the availability of the name and issue an authorization number which will be transmitted to the beneficiary, i.e. the registrant. This beneficiary then can register the name with a registrar by providing the authorization number. In order to ensure that relevant governments and authorities are aware of the process, information regarding the registration of geographic domains will be displayed on TaxiPay GmbH’s major websites. Moreover, the process will be documented in the registration policies. 
Moreover, TaxiPay GmbH will grant governments, IGOs and public authorities the possibility to report and challenge abuses of geographical names and names with geographical significance. Reporting will be directed either towards the responsible registrar or towards TaxiPay GmbH itself. If TaxiPay GmbH or a registered registrar receives such a complaint by any institution mentioned above, the complaint will be inspected by TaxiPay GmbH’s very own validation agent and a decision will be made (as described in question 18(a)). More information regarding the reporting process as well as the domain status during this process is specified in the answer to question 28 “Abuse Prevention and Mitigation”. 

The technical and operational specifications for the TLDs Registry consist of the following:

Registry.net has been chosen as technical backend for registry operations because of the companyʹs extensive knowledge of the domain industry and technical infrastructure. The parent company of registry.net, the ICANN accredited Registrar InterNetWire Communications GmbH, has extensive knowledge in the area of handling gTLDs as well as more than 20 different ccTLDs. The registry.net Shared Registry System (ÒSRSÓ) is based on a registry platform, which is already in use as a domain management platform. 

The scalability of the system has been proven by the growth of the customers base of InterNetWire. With more than 150 resellers and over 800.000 domain names under management, the systemsʹ scalability is proven with the number of domains under management and the number of simultaneous connections from different resellers. 

The EPP-based platform provides a stable, DNSSEC and IPv6-enabled SRS that is scalable, state-of-the-art, and secure. All registry services will be provided by the registry.net in a responsible manner adhering to all ICANN requirements for TLD operations.

The goal is to operate an ICANN compliant technical registry platform meeting industry best practice standards to allow registrations under the applied for new top level domain.

All registry services described in our responses to questions 23-44 are covered by a contract with the RSP registry.net GmbH.

The responses to question 23-44 have been developed together with registry.net.

All ICANN accredited registrars that meet the registry operators established eligibility criteria must use EPP (see section A below) to interact with the registry and manage their sponsored domain names.

All fundamental registry services will be subject to the SLAs as defined in question 24. All services are continuously monitored for compliance with the SLAs and to discover increased system load and performance issues prior to affecting the experience of the registrars or end-usersʹ of the TLD.

The registry will implement several blacklists to ensure compliance with ICANN guidelines, including but not limited to Specification 5 of the New gTLD agreement specifications.

All domain name availability checks and registrations will be checked against the implemented blacklists and eligible registration guidelines to ensure standard compliance and policy guidelines (such as hyphens in third and fourth place are only allowed for valid IDN registrations ʺxn--ʺ).

Two character labels, country and territory names as stated in ISO 3166-1 and all successors thereto, will be blocked and only released if a written confirmation of such a release is granted by the applicable governments. Detailed descriptions on the handling of reserved domain names can be found in answer to question 22.

None of the registry services are offered in a manner that is unique to this TLD. They are offered as standard registry services as is the case for established gTLDs today, and no new services are defined for this TLD.

Registry.net will support this TLD in accordance with the policies established by ICANN and the applicant leveraging a fully operational registry infrastructure supported by experienced professional staff and fully provisioned to immediately launch this and a number of other gTLDs to meet or exceed the Service Levels required in the ICANN contract.

Standard Policies and Dispute Resolution

Domain name registration in the zone are subject to the Uniform Dispute Resolution Policy (UDRP), PDP, URS and all successors thereto.

Inter-registrar transfers are subject to the ICANN transfer policy as described in

http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm and the transfer dispute policy as described in http:⁄⁄www.icann.org⁄en⁄transfers⁄dispute-policy-12jul04.htm.

The registry operator is committed to using best practice standards as described by industry members and ICANN. 

Data Escrow Service

To ensure compliance with the Data Escrow requirements the registry will be using Group NCC to act as the third party data escrow agent (see answer 38 for details). All data uploaded to the escrow agent will follow the specifications published at http:⁄⁄tools.ietf.org⁄html⁄draft-arias-noguchi-registry-data-escrow-02 or any successor RFC.

The purpose of the third party data escrow service is to allow a registry data transition in the case that the registry provider fails to fulfill its SLA or is incapable of continuing the registry operations in a manner defined by ICANN.

Reports will be generated on a regular basis to be used for reportings to ICANN.


A. Receipt of Data from Registrars

A.1 Extensible Provisioning Protocol (EPP)

For the purpose of data exchange with the registrar, EPP is used in combination with an SSL encryption on a dedicated port. The registry will issue an SSL certificate for usage by the registrars.

Our EPP specifications follow the existing RFCs and will comply with all relevant successor standards. RFCs considered for the EPP protocol are: RFC 3735, 5730 Ð 5734, 5910 and 3915.

The following commands will be available for registry operation:

- CreateDomain, CreateContact, CreateHost
- ModifyDomain, ModifyContact, ModifyHost
- InfoDomain, InfoContact, InfoHost
- DeleteDomain, DeleteContact, DeleteHost
- CheckDomain, CheckContact, CheckHost
- TransferDomain
- RenewDomain

Check commands will be available for accredited registrars to check availability of contact handles, host objects, and domain names.

CreateContact will be used to create contact handles used for subsequent domain registrations and modifications. 

CreateHost will be used to create host objects serving as nameservers.

CreateDomain will enable all ICANN accredited registrars to create a domain name under the respective TLD of this application.

Several ʺInfoʺ commands will be available to provision status information on domains, contacts and host objects to the accredited registrars.

See attached 23_Figure1.pdf.

Detailed EPP descriptions can be found in the answers to the questions 25, which are incorporated here by reference.

A.2 Production and Operational Testing and Evaluation (OT&E) EPP Servers

There will be two EPP servers to interact with the registry. One will be for production purposes and the other for testing and evaluation (referred to as the OT&E server) of new software versions and EPP client implementations. The production server consists of at least two load balanced servers (n+1). Each new stable production release will be released on the OT&E EPP server at least 30 days in advance. To increase security, a registrar IP address limitation is in place for the EPP servers (both production and OT&E).

A limitation on the allowable commands per time interval will prevent the registrar from affecting other clients in the SRS environment in regard to performance issues and increased system load.

Each registrar in the SRS environment will be entitled to up to five sessions from two different IP addresses. The registrar will be forced to update the registry password for the EPP servers and registrar extranet (see below) at least once every six months.

A.3 Registrar Extranet and SFTP Area

In addition to the EPP system the registrar can chose to interact with the registry through the registry specific registrar extranet and SFTP area. Access to the SFTP area will be secured by protocol specific encryption mechanisms. Aside from the EPP registrar-registry interaction, the registry extranet is mainly used to adjust registrar specific settings such as accounting, default values for RDDS (WHOIS), and reporting. Different tiers of access are granted to the registrars for this purpose. Access can be limited on a per user and group basis to either read only or write operations for the following objects: domains, hosts, contacts, user and group rights, accounting lists and current account statement.

The registrar extranet will enable registrars to update their IP address range and passwords for the EPP production, OT&E and SFTP areas. When changes are made to the IP address range a support agent will contact the registrar to verify the changes prior to the implementation. The registry will provide marketing material and⁄or detailed reports to all registrars on a regular basis via the registrar specific SFTP area.

Documents will be generated on a regular basis for all registrars and can be found in the SFTP area. These include transaction reports, monthly billing details, and detailed lists on domain names with a status of PendingDelete, domain names under registrarsʹ management, and contacts used.

Access to the registry extranet and SFTP area is also limited to a set of IP addresses as defined by the registrar during the accreditation process.

A.4 Support Case Handling

Each support case received by the registry.net system either by email (ticket system) or phone will be subject to a passphrase authentication scheme. The passphrases are given during the registrar accreditation process and will be used to identify authorized persons belonging to the registrar. This will thwart any social hacking attempts by unauthorized users.

Regular support will be offered from 9 am Ð 6 pm UTC⁄GMT. Supported languages are German and English. 

Registrar technical support will be available through a dedicated technical support team 24 x 7 x 365. The support team is committed to delivering support by utilizing best practices and industry standards.

A.5 Provisioning of Zone Status Information to Registrars 

Registrars can query the status of a domain name with the ÒInfoDomainÓ command or through RDDS. In order to query status information on an existing host-object the command ÒInfoHostÓ is used.

The registry operator will inform registrars by email in the cases of unplanned (emergency) or scheduled maintenance. 

Information on planned system maintenance will be sent to all accredited registrars at least 30 days prior to the deployment in the OT&E and production system. Registrars will also be informed in the event that system performance drops below normal operational standards and in the event of unforeseen system outages. 


B. Dissemination of TLD Zone Files

Nameserver operations for the Registry TLD will comply with RFCs 1034, 1035, and 2182 and all future successors and updates thereto. Additional details on the dissemination of TLD Zone Files can be found in answers to question 35 of this application, which are incorporated here by reference.
Distribution of zone files among all secondary nodes will be handled by a dedicated hidden master.

Updates to the primary master node will be performed every 15 minutes and distributed to a secondary master node (operated by PCH.NET, an external service provider specialized in providing anycast DNS services). For additional stability, the two hidden primary servers (master nodes) will be used in two different geographic locations. All other anycast and unicast nodes will query the secondary master node for zone file updates and update their records accordingly. Several checks will ensure the integrity of the distributed zone file before it is uploaded to the master node. Zone transfers will use the AXFR⁄IXFR zone file transfer method after successful verification of the newly generated zone. The distribution of new zone files will be continuously checked with each of the client nodes.


C. Dissemination of Contact or Other Information Concerning Domain Name Registration

A port 43 RDDS (WHOIS) server (RFC 3912) will be available for legitimate WHOIS lookups. The service will be load balanced on a cluster system updated in near real time. Query limitations on a per IP and subnet basis will apply to prevent system abuse. IP addresses stated in the ICANN RADAR section will be entitled to an increased query limit to facilitate inter-registrar transfers. A website WHOIS will be available on the registryʹs website to facilitate legitimate WHOIS queries using a normal browser. All services will be provided in full compliance with the ICANN requirements and applicable law. Additional details will be described as part of the answer to question 26 (RDDS) and question 44 (IDN).

In order to prevent system abuse of the website whois, a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) will be used. Each IP address will be entitled up to six lookups per minute and up to 360 lookups per hour. Each subnet will be entitled to 12 lookups per minute and up to 720 lookups per hour.

IP Addresses listed in the ICANN RADAR section will be entitled to 20 lookups per minute and up to 1200 lookups per hour. For clients using Ipv6, appropriate limitations will be in place to prevent data mining and abusive WHOIS queries.

Information used for WHOIS lookups will be distributed to the WHOIS server cluster using default SQL replication mechanisms. A dedicated read-only database (load balanced) will be used to store all relevant data at the location of the WHOIS server. To prevent any unauthorized access to the database all external communications to the database are blocked.
The WHOIS output will contain information such as domain names and contacts associated with the domain name registration, dates such as registration date and expiration date, status of a domain name, and host objects.

Example Request: Query for domain Òexample.stringÓ (please refer to Q26 section 8 for additional information concerning the WHOIS output)
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.example.string
Referral URL: http:⁄⁄www.example.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0


D. Internationalized Domain Names (IDNs)

Actual there are no IDNs provided.


E. DNS Security Extensions (DNSSEC)

DNS Servers will provide DNSSEC capability according to RFCs 5910, 4641, 4034 and all successors and updates thereto. EPP DNSSEC specifications will be implemented according to RFC 4310. Zones will be signed on the signing server and distributed to the hidden master nameservers which will then distribute them to the secondary servers. A full detailed description of DNS and DNSSEC related topics can be found in answers to question 43, which are incorporated here by reference.


F. Additional Proposed Registry Services

F.1 Bulk Zonefile Access

Clients with a legitimate interest in accessing the registry zone file will be entitled to access this file once a day. For this purpose a dedicated SFTP access will be granted and the zone file will be uploaded once a day. This service will be subject to an additional agreement fully executed between the interested party and the registry.

F.2 Tiered Registration

Sunrise details are described in Question #29 Rights Protection.


G. List of Attachments

- 23_Figure1.pdf - List of supported EPP commands ⁄ EPP object relationship

The registry.net system (RegEngine) is a domain registry system capable of registering domain names managed by multiple registrars. In addition to the SRS system, RegEngine provides RFC conforming interfaces for EPP, RDDS (WHOIS), DNS, and DNSSEC. RegEngine is capable of running any IDN string as well as IPv6. RegEngine uses recognized and proven technologies such as MySQL database software and BIND DNS servers, as well as industry standard backup and monitoring solutions.

RegEngine uses a thick registry model wherein all contact details are stored in a central location by the registry. All services are set up as a fully redundant solution (n+1). Additionally, there are two geographically separate data centers (Tier 3, all components are available at least n+1), one active and one which is designed to function as a warm-standby solution to ensure a maximum of data security and business continuity. All SRS and DNS related information is replicated in real-time between the data centers. 

RegEngineʹs modular design allows for quick and easy installation or removal of system components at any time. This ensures RegEngineʹs ability to react to any business needs or system loads in an appropriate manner at all times. 

RegEngine is managed by trained personnel only. Its operations follow well-defined business and security processes which are based on the ITILv3 standard and in accordance with ISO 27001. 

Registry.net has a NOC and support team available at two different locations in Germany (Munich and St. Ingbert) which allows 24 x 7 x 365 monitoring of all systems and provides customers with an easy way to reach personnel regarding any issue they may have. 

The SRS is protected against unauthorized access. Data integrity is ensured by both physical and software security and protection mechanisms.

All these measures together are the basis for running a robust and reliable SRS and are in compliance with Specification 6 and 10.


A. Detailed RegEngine Description

The following section refers to attachment 24_Figure1.pdf.

Figure 1 contains a high level functional overview of all RegEngine components which are described below. All described services and functions are in compliance with Specification 6 and 10 based on their design and setup.

For all of the services listed below the following applies:

The application servers (e.g. EPP, DNS, and RDDS) are set up as a cluster to guarantee a high-availability solution. The sizing of the servers and the databases are calculated to meet the needs of each business case. Additionally, the system is set up to be scalable so that an increase of domains or registrars can be easily handled by installing additional hardware as needed. 


A.1 Services Integrated into RegEngine

Domain Name System (DNS)

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, and any other resource connected to the Internet or a private network. The registry will be set up with a mix of anycast and unicast name servers. This service is provided by an external provider called PCH.NET which has over 10 years of experience in this area. This partnership with PCH.NET ensures a 100% guaranteed uptime of the service and worldwide DNS coverage. DNS and zone file creation is performed periodically (every 15 minutes), uploaded to the primary hidden master name server, and spread to the anycast clouds (PCH.NET) within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by zone transfer {AXFR (Asynchronous Full Transfer Zone)⁄IXFR (Incremental Zone Transfer)} to the worldwide anycast net.

DNS Security Extensions (DNSSEC)

DNSSEC adds security to the Domain Name System. DNSSEC helps in preventing cache poisoning or man in the middle attacks. This helps to protect usersʹ personal and⁄or financial information from being compromised on the Internet. This additional security helps in protecting end users and the reputation of brands.

Extensible Provisioning Protocol (EPP) 

The EPP gives registrars the ability to fully automate the management of their domain names. RegEngine uses EPP as a protocol for registering and managing domain names in a very standardized way. RegEngine is in compliance with RFCs 3735 and 5730-5734 as well as with Specifications 6 and 10 of the registry agreement. EPP compliance is ensured by technical validation (XML validator) and through the change management process which includes a quality assurance program.

Web Interface

The web interface provides the registrars the ability to manage their domain names through a comfortable user interface and grants access to reports and accounting information.

RDDS (WHOIS)

The Whois is a data directory service which grants public free access regarding domain information. The RDDS (WHOIS) service is provided as a web-based directory service via port 43 in accordance with RFC 3912. This service provides different information depending on the request. The data this will offer includes, but is not limited to:

- Domain name
- Address information on the registrant, administration-, technical- and billing contacts.
- IP addresses of the name servers
- The identity of the registrar
- Domain creation and expiration dates

There will be a searchable Whois accessible via the web interface. This service will only be available to registrars in respect to confidential data. In order to prevent any abuse of the provided data, additional limitations on the service include IP-based limitations and masking of critical customer data.

SFTP ⁄ SCP Access to the File Store 

The SFTP area grants access to all reports which are available in the RegEngine. Communication is only possible over an encrypted connection, such as with SFTP or SSH, protecting registrars from unauthorized access to their data. In addition to command line access, RegEngine offers access through the https-based web interface.

Escrow

RegEngine generates two types of deposits: full and differential. The escrow data provides all SRS-related information to an escrow agent as required for running a registry in compliance with the approved registry services.

The escrow file is generated in compliance with the format specification as described in Specification 2. The file will be transferred (SFTP) to the escrow agent as a compressed (ZIP RFC 4880) and encrypted file.

Registry.net is working with the escrow agent NCC Group GmbH, Munich, Germany.

The required data for generating the deposits are always stored in both data centers at all times. This enables the RegEngine to generate these files even in disaster scenarios.

Reports

The registry.net system generates all ICANN reports on a monthly, weekly, or daily basis. In addition to the ICANN related reports, reports for the registrars are created which contain invoicing and domain portfolio information:

- Per-registrar transactions report (Specification 3)
- Registry functions activity report (Specification 3)
- Up-to-date registration data (escrow format as described in Specification 2)
- Thick registration data in case of a registrar failure, de-accreditation, court order, etc. (escrow format as described in Specification 2)
- Technical and operational reports describing performance specifications (Specification 10)
- Registrar based domain and contact reports
- Monthly invoicing reports
- Name server reports
- Data escrow (full and differential as required in Specification 2)


Internationalized Domain Name (IDN)

An IDN is an internet domain name that contains at least one label that is displayed in software applications, in whole or in part, in a language-specific script or alphabet. 

RegEngine has fully integrated IDNs in the SRS and related DNS, DNSSEC, RDDS (WHOIS), and EPP services. The domain registration must be submitted in PUNY code (ascii-encoding) with the appropriate language tag. There is no different handling or billing between the IDN and ASCII domains. 


B. Network Diagram

See attached 32_Figure1.pdf for the detailed network overview.

B.1 Hardware (Number of Servers)

Network Components:

- Two (2) or more firewalls (Vyatta) (load balanced) Vyatta 6.3
- Two (2) or more network switches frontend (Juniper), EX2200, EX4200
- Two (2) or more network switches transfer (Juniper), EX2200, EX4200
- Two (2) or more network switches backnet (Juniper), EX2200, EX4200
- Two (2) or more load balancer (Keepalived) and SUSE Linux Enterprise High Availability Extension

B.2 Server Components

Typical components for all servers:

Server: IBM compatible Linux server
Processor: INTEL 64bit multicore CPU
Memory: Up to 64 GB ECC DDR2 RAM modules
Disk: Internal RAID 5 for operating system and software, additional intern RAID 5 for data, iSCSI support 
Network Adapter: Average 4 100⁄1000 mbit network interface

- Two (2) or more webservers for the web interface (load balanced)
- Two (2) or more EPP server (load balanced)
- Two (2) or more RDDS (WHOIS) servers (load balanced)
- Two (2) or more SFTP servers (load balanced)
- Two (2) or more tools servers (cron, batch) (n+1 redundant with failover)
- Two (2) or more database servers (load balanced)
- Two (2) or more storage servers (load balanced)
- One (1) BIND hidden master
- One (1) Generator
- One (1) Signer ⁄ HSM

Full detailed hardware description can be found in attached 32_Figure3.pdf.

The listed hardware satisfies the SLA requirements as described in Specification 10.


C. Description of Inter-Connectivity with Other Registry Systems

The modular design of the registry.net solution has the advantage of being very flexible and highly scalable. The SRS, EPP, and RDDS (WHOIS) services communicate through an internal API which protects the system from direct database access while providing real-time information to all SRS related services. 

The DNS and DNSSEC information is provided every 15 minutes to the primary hidden master name server and then spread to the anycast⁄unicast cloud within 180 seconds. The communication between the primary hidden master name server and the DNS cloud is facilitated by AXFR⁄IXFR.

The escrow data (full and differential deposit) is generated, zipped, and encrypted once a day and sent to the escrow agent in compliance with Specification 2.

The complete SRS database information is shared between both data centers (primary site, warm-standby). This is achieved by real-time data synchronization. In addition, the SRS program code and binaries are also shared between both data centers at any given time. Only one of the two data centers is actually running in production mode at a time, while the other one is always on standby but not active until needed.

The two data centers are connected through a VPN connection which is used for synchronization of the services described above. In the unlikely event of the complete loss of one data center, RegEngine can be switched from one site to another within minutes and with no data loss. The DNS⁄DNSSEC is secure and highly available due to its worldwide setup.

The systemʹs complete inter-connectivity is integrated into the system monitoring and ensures the readiness of the failover locations at any time. In addition to monitoring, a controlled failover testing from the production data center to the warm-standby data center is performed once a year.

These measures ensure compliance with registry continuity in Specification 6.


D. Frequency of Synchronization between Servers

The frequency of the server synchronization depends on the service being synchronized. Some services are synchronized in real-time while others are synchronized at fixed periods.

The database is set up as a cluster solution (with n+1 redundancy) in each data center. Since only one data center is running in production mode at a time, the other data center is connected to the production database by real-time replication. This guarantees a complete set of SRS⁄DNS information at all sites.

As the DNS⁄DNSSEC is generated from the database information, RegEngine always has the complete zone file information available at both data center sites. The zone file itself is generated every four minutes and uploaded to the primary hidden master name server. From there, the zone file is distributed to 95% of all DNS servers worldwide within 180 seconds.

The RDDS (WHOIS) is retrieved from the database in real-time and is available at both data center locations at all times. 

Like RDDS, the EPP interface retrieves and submits its information in real-time and is also connected to the database.

In addition to storing the complete registry-related data in the database, RegEngine also distributes the complete SRS source and binary codes to both data center locations at all times. This is achieved by a central repository which is synchronized at every location.

The combination of synchronization of source and binaries of each SRS-related service and the centralized database allows registry.net to switch from one data center to the other within 30 minutes. During a failover, the DNS service remains unaffected by the switch.

The data escrow files are generated in accordance with the registry Specification 2.

- Full Deposit: Each Sunday by 23:59 UTC
- Differential Deposit: Monday through Saturday by 23:59 UTC

These measures ensure the compliance with registry continuity in Specification 6.


E. Synchronization Scheme (warm-standby)

The setup of the system includes two geographically separate data centers configured as a warm-standby system (one active, the other in warm-standby, see attachment 24_Figure1.pdf). If the production data center is hit by a disaster which results in the complete loss of the data center, the warm-standby system can be brought online within minutes to completely take over.

The complete SRS data (domains, contacts, DNS, etc.) is always available at both data centers at any given time, safeguarding the SRS data from being lost. This is achieved by the setup of the SRS databases as clusters and distributed over both data centers. The cluster is synchronized in real-time.

Using PCH.NET as a partner for DNS⁄DNSSEC, RegEngine always has ten different locations available worldwide.

These measurements ensure the compliance with Specification 6.


F. Project Resources and Roles

InterNetWire Communications GmbH has gathered experience in various roles in the domain business for more than 16 years and has access to extensive knowledge in the domain industry. This deep industry knowledge and experience has been transferred to registry.net GmbH, the technical provider for shared registry services, and is evident in many trusted persons serving in different roles throughout the company.

All employees, contractors, and consultants that have access to or control of the registry system are trusted persons.

Each role is staffed with multiple human resources for backup and capacity purposes.

Prior to commencement of employment in a trusted role, registry.net GmbH performs the following background checks on a prospective candidate:

- Criminal records bureau check
- Verification of previous employment
- Check of professional references


F.1 Role Descriptions

Security Role

The Chief Security Officer (CSO) is dedicated to the security role. The CSO is the person responsible for the security of a companyʹs communications and other business systems. The CSO is involved in both the business (including people) and technical aspects of security. CSO responsibilities include training of personnel regarding security awareness, developing secure business and communication practices, purchasing security products, and ensuring that security practices are followed. The CSO has a stand-in backup available.

Designated Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces such as EPP, RDDS (WHOIS), escrow, etc. All engineers are also integrated into 3rd level support of the SRS and related interfaces. 

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware and system installations as well as the cluster setup of the databases and all data backups which are made. 

The NOC team is composed of system administrators. This team is responsible for clean, well-documented, and reliable data center operations. All access to the data center is restricted to members of the NOC team and persons accompanied by members of the NOC team only. There is an emergency team of at least two people at all times. This team is reachable 24 hours a day, 365 days a year.

Security Administrator

Members of this role define HSM domains⁄tokens and administer HSM users and the overall HSM policy. Security administrators guarantee a working HSM domain for DNSSEC signing.

Support Role

The support role covers the first and second levels of support (Service Desk). All registrars and SRS customers may contact the support role as the first line of contact. Requests can be submitted via email or phone and can be placed 24 x 7. If problems are traced back to an erroneous system behavior as the cause, all available data are gathered and a problem report is generated and handed over to the change management team. 

DNS⁄DNSSEC Role

The DNSSEC administrator role is staffed with at least two persons. Members of this role are responsible for the overall Open DNSSEC setup and maintenance. This includes the connection to the HSM cluster as well as compliance to the HSM policy for the DNSSEC domain. 

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed entirely on a separate testing system (OT&E) which mirrors the production system. The QM ensures the production readiness of each and every software upgrade, including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM. 

Change Management ⁄ Project Management Role (CM⁄PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented, and reviewed in a controlled manner. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The CM⁄PM reviews and closes requests for change and reports to management. 

F.2 Project Resources

The table in (attachment 24_Figure2.pdf) shows how the roles described above are planned for the SRS system. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, management, and development required. All human resources are only engaged in the domain industry and are experts in their area.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.


G. List of Attachments

- 24_Figure1.pdf
- 24_Figure2.pdf
- 32_Figure1.pdf
- 32_Figure3.pdf

InterNetWire Communications GmbH first gained experience working on the client side of the Extensible Provisioning Protocol(EPP) with the .Info registry (launched in 2001). This deep industry knowledge and experience has been transferred to the subsidiary registry.net GmbH. Launched against early Internet Drafts, a great deal was learned in the first years leading to important protocol revisions. Some of these included changes to prevent the formation of orphaned glue records in an EPP registry and the ability to affect mass internal host updates with a single request. Most importantly, EPP brought the required functionality of populating registration contact data in the registry, allowing the subsequent implementation of a centralized or ÒthickÓ Whois service.

EPP was largely motivated by the growth in the number of accredited registrars that occurred beginning in 1999. Technologists working on EPP believed that the emergence of many new TLD registries was imminent and sought to ease the client-to-server implementation work that would flood the registry⁄registrar community if a standardized protocol was not developed through which to interact with domain registries. The effort was largely successful, although there has been extensive distinct diversion among overlapping EPP extensions between different registries over the years.

RegEngine EPP Server Interface

The EPP server is set up as a cluster to guarantee a high availability solution. The sizing of the servers and databases are calculated to meet the needs of each business case. The system is set up in a scalable way so that an increase of domains or registrars can be handled by adding hardware as needed. The RegEngine EPP API is offered over TCP on port 700 with mandatory SSL session enforcement for registrars for automated interaction with username and password. 

To increase security, a registrar IP address limitation is in place for the EPP servers (both production and OT&E). This API also supports a secure web-based (over https) EPP client for registrarsʹ manual use only. The web-based graphical interface interacts with the EPP server through standard EPP XML queries. The EPP XML responses are in turn displayed in the web interface. This allows the registrars to perform registry transactions through the web-based interface.

The RegEngine EPP Interface is capable of supporting up to 5000 read transactions per minute and 2000 write transactions (concurrently). It is provisioned in a highly redundant, duplicative environment using stateless, multiple application instances. 

Please see aswer 31 for details on expected transaction volumes for this TLD registry.


A. RFC Relevance to registry.net (RegEngine)

A.1 RFC 5730

This RFC is a base protocol document for EPP. EPP is an XML-text object based client-server protocol, atomic in its transactions, and developed to support multiple transports and lower level security protocols. There are no partial failures; all commands either succeed or fail definitively. Object-to-object associations are standard with limited application of parent-child relationships where delegate relationships are necessary for affected functionality, such as internal host data and its relationship to domain objects. The RegEngine registry fully implements the service discovery, commands, responses and the extension framework described. 

A.2 RFC 5731

This RFC explains the mapping of the primary EPP registry object, the domain object. It reviews associated attributes and states of the domain object as well as child object relationships (hosts). It also details associations with other contact objects. RegEngine complies with the full XML examples and descriptions and applies flexibility where permitted. For example, 5731 allows operators to implement the info command with different responses for a Òsponsoring registrarÓ and a Ònon-sponsoring registrarÓ in regards to most domain object attributes. RegEngine implements this as a base protocol document for EPP.

A.3 RFC 5732

RegEngine implements this as a base protocol document for EPP. RegEngine notes this RFC describes the mapping of relationships to host objects, which are by definition subordinate to the superordinate domain name object. Host objects that are defined as internal or in the namespace of the registry must be related to a superordinate domain object to be created. Internal hosts, as full child objects, face restrictions associated with the management of their superordinate domain object. External hosts are hosts belonging to another domain namespace and as such are not subordinate in the present namespace. Internal hosts can have a glue or an A record associated with them, external hosts refer to another namespace or zone for the associated A record. 

A.4 RFC 5733

Another base RFC implemented in the RegEngine server, this RFC describes the contact object mappings in EPP. Contact objects are used to contain related data surrounding the standardized contacts types in TLD registries including attributes such as contact type, country, telephone numbers, email addresses, etc. As a standalone object, a contact object can be created and associated with no domain objects or with any number of domain objects available in the registry. This is used commonly by registrars to update common contact information associated across large numbers of domains in a single transaction. Like the domain object, it can be secured with a passphrase or ÒauthinfoÓ code. Contact object data represents the definitive data source for authoritative RDDS (WHOIS) in new TLDs. 

A.5 RFC 5734

RegEngine will implement this RFC as the preferred industry transport and in compliance with ICANNʹs requirements. Early implementations of EPP were considered over BEEP. This RFC describes a standard implementation of TCP incorporating TLS. As mentioned earlier, EPP can be implemented over multiple transports. The transport of choice for the EPP registry community has been TCP. Implementers are encouraged to take precautions against denial of service attacks through the use of standard technologies such as firewall and border router filters. IANA awarded port 700 as the dedicated port for the server side. There is no dedicated port assignment for the client side. 

A.6 RFC 5735

RegEngine will implement this RFC as applicable to any extensions it utilizes as this RFC provides specific and detailed guidance on EPP extensions. An important principle in creating extensions to, as opposed to modifying, the EPP protocol was to fully preserve the integrity of the existing protocol schema. Additionally, a valid extension itself should be extensible. Another important requirement in the RFC is to include announcements of all available extensions in the EPP server greeting element before establishing an interactive client session. 

A.7 RFC 3915

RegEngine will support this extension since this TLD implements the grace period implementation known as the Redemption Grace Period or ÒRGPÓ. When RGP is in use, domains are deleted into the RGP where Registrars may request a restoration of the domain. This is a billable event and requires a three-step process: placement of the domain into a pending restore state, submission of a restore report explaining why the domain is being restored, and finally the restoration of the domain. The RFC extends the domain update command, adds related domain statuses, such as ʺredemptionPeriodʺ and ʺpendingRestore,ʺ and extends the responses of domain info and other details. The RFC provides a lifecycle description of the RGP and defines the format and content for client to server submission of the associated restore reports. 

A.8 RFC 5910

RegEngine will support DNSSEC from the initiation of this TLD and therefore will also support this extension from initiation of the registration process. DNSSEC is a mechanism for cryptographically verifying that each delegate zone in the DNS hierarchy has been referred to or is referring to its genuine parent or child zone respectively. Since TLD zone files are generated from authoritative registry data, this extension specifically provides the ability to add elements to the domain-create and domain-update functions and to the domain-info responses, allowing registrars to submit associated delegated signer information of the child zone indicating it is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.

 
B. Extensions used by RegEngine and Related Internet Drafts

B.1 Draft-tan-epp-launchphase-01 (Launch Phase Mapping for the EPP)

RegEngine intends to use this EPP internet draft to facilitate Sunrise phases during the initiation of this TLD registry. This internet draft proposes an extension mechanism that supports the organization of Sunrise related domain applications. The extension considers the following elements:

〈lp:phase〉
This element allows a Sunrise application submission to be marked by the EPP client as a particular Sunrise application type, in respect to running different types of Sunrise applications during a concurrent submission period. RegEngine will use this to identify Sunrise A and Sunrise B application types. 

〈lp:status〉
This element allows the EPP server to assign one of a number of statuses indicating what stage the Sunrise application is in. These statuses can be expressed through the domaininfo command response and, optionally, through the RDDS service if applicable. The statuses listed below can be assigned uniquely or in combinations where appropriate:

〈pvrc〉
The Pre-Validation Result Code, an opaque string issued by a third-party validation agent

〈claimIssuer〉
contains the ID of a contact object (as described in RFC 5733 [RFC5733]) identifying the contact information of the authority which issued the right (for example, a trade mark office or company registration bureau)

〈claimName〉
identifying the text string in which the applicant is claiming a prior right

〈claimNumber〉
the registration number of the right (ie trademark number or company registration number)

〈claimType〉
indicates the type of claim being made (eg trademark, symbol, combined mark, company name)

〈claimEntitlement〉
indicates the applicantʹs entitlement to the claim (ie, owner or licensee)

〈claimRegDate〉
the date of registration of the claim 

〈claimExDate〉
the date of expiration of the claim

〈claimCountry〉
indicates the country in which the claim is valid

〈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 [WIPO.ST3] 

The complete draft is described in attachment 25_Figure3.pdf.


C. RegEngine EPP Server 

C.1 RegEngine EPP Command and Elements and Overview

Attachment 25_Figure1.pdf contains the table with the supported EPP commands and the EPP object relationship.
Note: There are at least 2 name servers required for an active domain. Otherwise, the domain will be in the inactive status.

C.2 EPP Compliance Assurance:

RegEngine is committed to ensuring and maintaining compliance with the aforementioned EPP RFCs and, to this end, employs numerous mechanisms as listed below:

Quality Assurance Program

RegEngine runs a robust Quality Assurance (QA) program with multiple dedicated QA engineers. Complete unit, regression and stress based automated test suites for positive and negative use case testing are applied. The test suites are optimized for the relevant use cases. RegEngine reviews its use cases regularly with the entire development and registry operations teams for consideration as additional test cases. Additionally, RegEngine hosts periodic events where we bring together registrar engineers to discuss these use cases and seek new cornerstone cases that registrars may be able to offer from their experiences and points of view. 
RegEngine provides its QA team with a robust production grade testing environment with client load emulation capabilities that far exceed the load (through rate limiting) permitted on the RegEngine production environment. 

OT&E

All new candidate EPP application versions will be released to a pre-candidate Registrar Operational and Testing Environment (OT&E) before promotion. Minor revisions, defined as new optional functionality, will have a minimum 30 day period in OT&E. Major changes, defined as requiring changes on the registrar client side, will have a minimum 90 day period in OT&E.

Inline XML Validator

The RegEngine EPP application uses the following XML validator in its server implementation. (Perl library XML::LibXML) XML errors or malformed XML will fail EPP transactions with the client atomically and the server will detail the failure state in the returned error message as well as the incorrect XML.

Third Party Validation

RegEngine is partnered with another Registry Service Provider (RSP), KSregistry GmbH as a subsidiary of Key Systems GmbH and has a bilateral agreement for each party to independently test and verify each otherʹs EPP RFC compliance. Registry.net GmbH may also opt to engage other third parties for compliance testing.


D. Resources and Roles

D.1 Resources

InterNetWire Communications GmbH has gathered experience in various roles in the domain business for more than 16 years and has access to extensive knowledge in the domain industry. This deep industry knowledge and experience has been transferred to registry.net GmbH, the technical provider of the registry.net system (RegEngine), and is evident in many trusted persons serving in different roles throughout the company.

All employees, contractors, and consultants that have access to or control of the registry.net system are trusted persons.

Each role is staffed with multiple human resources for backup and capacity purposes.

Prior to commencement of employment in a trusted role, registry.net GmbH performs the following background checks on a prospective candidate:

- Criminal records bureau check
- Verification of previous employment
- Check of professional references

D.2 Roles

Designated Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces (EPP, RDDS (Whois), escrow, etc.). All engineers are also integrated into 3rd level support of the SRS and related interfaces. The members of the engineering role are located in two geographically separate locations in Germany (Munich and St. Ingbert).

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware, and system installations, as well as the cluster setup of the databases and all data backups which are made. Further, the installation of the hardware security module is performed by this role. This includes network setup, operating system installation, and HSM activation.

Support Role

The support role covers the first and second levels of support (service desk). All registrars and SRS customers may contact the support role as the first line of contact. Requests can be submitted via email or phone and can be placed 24 x 7. 

The first level of support receives all incoming requests from registrars and SRS customers and establishes the first contact. All problems that arise due to improper usage of the system or a misunderstanding of procedures will be resolved by the first level support. In addition, the first level points the customers to the online wiki and knowledge bases to prevent such requests in the future.

The second level support takes care of all problems which could not be solved by the first level. If problems are traced back to an erroneous system behavior as the cause, all available data are gathered and a problem report is generated and handed over to the change management team.

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed on a separate testing system (OT&E) which mirrors the production system. The QM ensures production readiness of each and every software upgrade, including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management (CM) ⁄ Project Management (PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented and reviewed in a controlled manner. This role filters requests so that only useful, valid and approved changes are implemented. They are also responsible for managing development efforts and changes to ensure that the changes are applied in accordance with predefined processes. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The project and change management role reviews and closes requests for change and reports to management. 


The table in attachment 25_Figure2.pdf shows how the roles described above are planned for the SRS system. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, management, and development required. All human resources are only engaged in the domain industry and are experts in their area.

However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.


E. List of Attachments

- 25_Figure1.pdf
- 25_Figure2.pdf
- 25_Figure3.pdf
- 25_Figure4.pdf

RegEngine provides both web and command line (port 43) publicly accessible RDDS (WHOIS) which offers a central location for all authoritative TLD related information when registering or modifying a domain name. The Registry Data Directory Services RDDS (WHOIS) information is reflected in real-time to the public. 
The RDDS (WHOIS) service is a public service for interested stakeholders such as registries, registrars, individuals, law enforcement, and trademark owners that require detailed information on one of the following categories of information:
- Domain name including status, creation, and expiration date
- Information on domain registrant, administration, technical and billing contact
- Name server and IP address
- Registrar information
This information will provide the public with the ability to get in touch with the domain holder for any reason that requires action to be taken (e.g. trademark issues, violations with registry policies, offensive content, etc.). In addition to the search capabilities, the service has methods of limiting abuse.
The RDDS (WHOIS) service is in compliance with RFC 3912 and Specifications 4 and 6 of the registry agreement and global best practices.
Registry.net as subsidiary of InterNetWire Communications GmbH is already running a RDDS (WHOIS) server in full compliance with RFC 3912. The service has been in place for over 16 years without any major incidents. Experienced personnel are on board for operating and maintaining the RDDS (WHOIS) service.


A. Searchable RDDS (WHOIS)

The RegEngine RDDS (WHOIS) includes a web-based searchable service for registrars only which reveals more detailed information, satisfying the requirements for a score of 2.
Attachment 26_Figure2.pdf shows the complete list of all possible queries which can be made.
For security reasons and legal restrictions some search capabilities are only available in the registrar web-based RDDS (WHOIS). This includes partial match capabilities regarding the registrantʹs postal address.


B. Abuse Protections

There are technical restrictions in place for all RDDS (WHOIS) types to prevent the abuse of the data from such methods as data mining or DDOS (Distributed Denial of Service). Following best practices, RegEngine protects the web-based whois service with CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) and port 43 whois service with IP limitations. 
In addition to these technical restrictions, the registry policy disallows data mining or comparable approaches of collecting data.


C. Technical Overview

The RDDS (WHOIS) service is set up as a two server cluster with a redundant loadbalancer in front of it to ensure a highly available solution (n+1 redundancy). 
The server software is running on a SuSE Linux Enterprise Server and is configured to be scalable, allowing RegEngine to be extended by simply adding additional servers to the setup during regular operations.
The sizing of the servers and the databases are calculated to meet the needs of the individual business case and are able to handle a sustained and significant load. The available RDDS (WHOIS) servers are always active at one regional site and may be switched to another regional site within minutes as necessary. There are two different sites available for running the RDDS (WHOIS) service.
- Primary Site: Munich, Germany
- Secondary Site: St. Ingbert, Germany 
All sites have a permanent highly secure VPN connection to the (current) primary site in order to synchronize the complete SRS, EPP, DNS⁄DNSSEC, escrow and RDDS (WHOIS) related database information. All network traffic between the VPN gateways will be encrypted using 1024 bit RSA keys. The complete availability of RegEngine information at all times allows a safe failover from the primary site to the secondary or disaster site within minutes.
The RDDS (WHOIS) information data is stored in a MySQL database which is setup as an active⁄active database cluster. This cluster is permanently replicated to all other sites. The RDDS (WHOIS) data is also stored daily by the RegEngine backup system. The backups are also sent to the secondary site.
In addition to the performance aspect of the RDDS (WHOIS) service, the RegEngine detects abusive usage levels such as those that occur from excessive numbers of queries from one source. This is accomplished by checking the source IP of the request on the port 43 RDDS (WHOIS). The web-based RDDS (WHOIS) comes with an additional CAPTCHA mechanism in order to prevent abuse.
Further protections to the WHOIS service from incidents like DDOS (Distributed Denial Of Service) attacks are assured by an IDS (Intrusion Detection System) which provides RegEngine overall protection.
Daily generated escrow data files containing all RDDS (WHOIS) related data are stored at the NCC Group as the RegEngine escrow provider. 
The full RDDS (WHOIS) architecture is described in attachment Figure 26_Figure1.


D. Quality Measurements and Validation of Compliance with Specifications 4 and 10

RegEngine takes several measurements in order to ensure ongoing Service Level Agreement (SLA) checking, RFC compliance, and compliance with Specifications 4 and 10 of the registry agreement. For the following, RegEngine refers to the RDDS (WHOIS) as RDDS (Registration Data Directory Services) in order to describe the collective of RDDS (WHOIS) and web-based RDDS (WHOIS) services. 
In order to facilitate the registry performance specification (Specification 10), the following checks are performed on the RDDS (WHOIS) periodically.
- RDDS availability
- RDDS query RTT 
- Web-based RDDS query RTT (Round Trip Time)
- RDDS update time
- RDDS test 
All available RDDS (WHOIS) search patterns are randomly checked with a data parser compliant with RFC 3912 and Specification 4 in order to check if the data output satisfies the given requirements.
A non-registry partner also validates RFC 3912 compliance. Backwards RFC compliance checks are made by a non-registry partner and KSregistry GmbH, arranged by a registry partnership.
All software enhancements or corrections go through the change management process. This includes full regression testing with the complete SRS system. Provided that all quality tests and the change is approved by the Change Management Board (CMB), a change will be made in the OT&E system. Once the testing phase in the OT&E is done and no problems are found while testing with the registrars, the software change of the new version will be made in production.


E. System Capacity

RegEngine sizing calculations have been performed to assess the hardware resources necessary to support the expected volume of transactions from the business case for this TLD and are based on available statistics from the monthly ICANN registry reports of existing gTLDs like .com, .org, .info and the ccTLD .be. 

Taking into account that the RegEngine is setup and designed to host multiple strings, the maximum number of this specific string does not fully load the maximum capacity of the system.

RegEngine is capable of handling the following volumes as a maximum with the current capability of the hardware which allows a max. RDDS (WHOIS) capacity of: 200,000,000 queries⁄month.

For the TLD .TAXI the calculation is the following:

First Year:
- RDDS per domain and month: Up to 78 queries
- Number of domain names registered in the first year: 6,750
- RDDS queries per month: Up to 526,500 

Note: Benchmark calculations from values from public registry data are raised by 50% for RDDS in the first year in respect to related registry launch activities.

Second Year:
- RDDS per domain and month: Up to 52 queries
- Number of domain names registered in the second year: 8,640
- RDDS queries per month: Up to 449,280 

If the system reporting and alerts indicate that the current volumes of data or transactions is reaching 75% of the maximum capacity of the system, the system will be upgraded by adding additional servers to the setup. This can be done during regular operations without requiring any downtime. RegEngine used the gathered statistics to derive blended base and peak transaction volume expectations per domain. Calculations of traffic presented below are derived strictly from peak transaction volumes in support of conservative estimates and the intent that a margin of error should result in over-provisioning registry services, versus under-provisioning. 


F. Hardware Specifications

The hardware specifications are based on the analysis from the system capacity numbers.
RegEngineʹs primary and secondary data center were chosen to fit a common architecture, providing the following benefits:
- at least TIER III compliance
- n+1 redundancy on power supply, cooling network 
- at least one 1 Gbit uplink provider
- latest fire prevention system
- 1 Gbit internal network transfer for RegEngine systems 
The detailed hardware list is described in attachment 32_Figure3.pdf.
RDDS plans are consistent with the technical, operational, and financial approach as described in the application.


G. Roles and Resources

G.1 Resources

InterNetWire Communications GmbH has gathered experience in various roles in the domain business for more than 16 years and has access to extensive knowledge in the domain business. This deep industry knowledge and experience has also been transferred to registry.net GmbH, the technical provider of the RegEngine system and is evident in many trusted persons serving in different roles throughout the company.
The table in (in attachment 26_Figure4.pdf) shows how the roles described above are planned for the SRS system. All resources at registry.net are dedicated to the registry business. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, managing and development required. All resources are engaged in the domain industry only and are experts in their field.
However, as the resources are shared and are not dedicated exclusively to one SRS project, the columns contain the number of resources available for this role and the percentage of all people working for this specific TLD. This percentage is the guaranteed time the resources for this SRS project assure.

G.2 Roles

Engineering Role

The designated engineering role includes the software developers of the entire SRS and all related interfaces (EPP, RDDS (WHOIS), escrow, etc.). All engineers are also integrated into 3rd level support of the SRS and related interfaces. The members of the engineering role are located in two geographically separate locations in Germany (Munich and St. Ingbert).

System Administration Role

The system administrators take care of the infrastructure of the SRS system. This includes the entire network, hardware and system installations, as well as the cluster setup of the databases and all data backups which are made. Further, the installation of the hardware security module is performed by this role. This includes network setup, operating system installation and HSM activation.
The members of the administration role are located in two geographically separate locations in Germany (Munich and St. Ingbert).

Quality Management Role

The Quality Management (QM) role takes care of each software component which is integrated into the SRS system and related interfaces. After a development cycle is finished, the QM performs full integration testing of the entire system. The testing is performed on a separate testing system (OT&E) which mirrors the production system. The QM ensures production readiness of each and every software upgrade including emergency software patches. No software or system change will be promoted to production without the explicit approval of the QM.

Change Management (CM) ⁄ Project Management (PM)

The CM and PM role ensures that all steps in the development and system change processes are assessed, approved, implemented and reviewed in a controlled manner. This role filters requests so that only useful, valid and approved changes are implemented. They are also responsible for managing development efforts and changes to ensure that the changes are applied in accordance with predefined processes. They also chair the Change Advisory Board (CAB) and the Emergency Change Advisory Board (ECAB). These boards are comprised of selected people from other functions within the company. The project and change management role reviews and closes requests for change and reports to management. 


H. Whois Output Fields

Query on domain name data displays the following information:
Domain Name
Domain ID
WHOIS Server 
Referral URL
Domain Last Updated Date 
Domain Registration Date
Domain Expiration Date
Sponsoring registrar
Sponsoring registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact
Information including
Contact ID
Contact Name
Contact Organization
Contact Address, City, State⁄Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail
Name Servers associated with this domain
DNSSEC information

Example Request: Query for domain Òexample.stringÓ
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.nic.string
Referral URL: http:⁄⁄www.nic.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0

Query on name server name data displays the following information:
Name Server Host Name
Name Server IP Addresses if applicable 
Sponsoring registrar
Name Server Creation Date
Name Server Last Updated Date 

Example Request: Query for name server ns1.example.string
Example Response:
Server Name: NS1.EXAMPLE.STRING
IP Address: 192.0.3.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Creation Date: 2011-06-01T23:45:33Z
Updated Date: 2011-07-22T01:44:02Z

Query on registrar displays the following information:
Registrar ID
Registrar Name
Registrar Status
Registrar Address, City, State⁄Province, Country
Registrar Postal Code
Registrar Phone, Fax, E-mail
Registrar Creation Date
Registrar Last Updated Date
Administrative, Technical Contact
Information including
Contact Phone, Fax, E-mail

Example request: Query for registrar Example Registrar, Inc.
Example response:
Registrar Name: Example Registrar, Inc.
Street: 4231 King Street
City: London
State⁄Province: XY
Postal Code: 123445
Country: XR
Phone Number: +1.3105559999
Fax Number: +1.3105559911
Email: registrar@example.string
Admin Contact: Pete Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: pete@example-registrar.string
Technical Contact: Karlo Schlapp
Phone Number: +1.5610555222
Fax Number: +1.33105551111
Email: karlo@example-registrar.string


I. List of Attachments
- 26_Figure1.pdf
- 26_Figure2.pdf
- 32_Figure3.pdf
- 26_Figure4.pdf

A. Registration Life Cycle Periods
The registration life cycle of a domain name includes the following periods: available, add-grace period, registered, expired, auto-renew grace period, redemption grace period, pending delete, and released. This life cycle offers the possibility for different business cases, such as domain auctioning, drop catching, and domain tasting. As this TLD operates with a single registrant policy, neither auctioning, drop catching, nor domain tasting is expected to take place. It also includes the domain deletion excess fee in order to avoid massive abuse of the add-grace period. 
The complete registration life cycle is shown in attachment 27_Figure1.1.pdf.

A.1 Available
The domain name is available for registration. Each registrar can register the domain name using a create domain command. The first registrar which submits the domain registration order and has sufficient funding will receive the domain name. After the successful registration of the domain name, the add-grace period will begin. An available domain name cannot be transferred, deleted, updated, or restored and will not be included in the zone file.

A.2 Add-Grace Period (AGP)
The AGP starts after the successful registration of the domain name and lasts for fifteen (15) working days. During this period the registrar can submit a delete domain command to delete the domain name and will receive a complete refund of the registration fee. This refund does not include non-refundable fees of the registration process. However, the AGP follows the Internet Corporation for Assigned Names and Numbers (ICANN) AGP consensus policy to charge the registrar for excessive deletion activity during this period. During the AGP, the domain name is considered registered and therefore offers the same possibilities available during the registered period described below. A domain name in the AGP is included in the zone file and may not be transferred. The registrar license and agreement prohibits a domain name holder from changing registrars within the first 60 days of the initial registration, enforced by the SRS. If a domain name is renewed during this period and then subsequently deleted, the owning registrar will only receive a refund for the initial registration fee.

A.3 Registered
A domain name can be registered for a period of one to ten years. During this period the domain name can be transferred to another registrar using the transfer domain command if the requesting registrar has sufficient funding to pay the transfer domain fee. The transfer of a domain name will extend the registration period for one year, but cannot exceed ten years total registration period. The domain name can be renewed any time by the owning registrar using the renew domain command if the owning registrar has enough funding for the domain renewal fee. However, the maximum registration period of ten years can never be exceeded. A registered domain name is included in the zone file if associated with any host objects.

A.4 Expired
If the domain name passes its expiration date without being renewed by the owning registrar, the domain name will enter the auto-renew grace period. An expired domain name is included in the zone file if associated with any host objects.

A.5 Auto-Renew Grace Period (ARGP)
During this period the owning registrar has the possibility to delete the domain name using the delete domain command and receive a refund of the domain renewal fee. The ARGP lasts for 10 working days. A transfer to another registrar is possible if the requesting registrar has enough funding for the domain transfer fee. A transfer process will extend the domain registration period for one year, but cannot exceed ten years total registration period. If the registration period is already ten years, the transfer will not extend the registration period. After 45 days without a renewal, the domain name will enter the redemption-grace period. During the ARGP the domain name will still be in the zone file if associated with any host objects.

A.6 Redemption Grace Period (RGP)
If a domain name enters the RGP it will be excluded from the zone file and the domain name will no longer resolve. During this period no renewal, transfer, or new registration of the domain name is possible. The RGP lasts for 30 working days. During this time the owning registrar can restore the domain name. The registrar can submit an extended update domain command (restore) to reactivate the domain name if the registrar has enough funding for the restore domain fee. If a domain is restored it will enter the registered status with a registration period of one year. It will be included into the zone file with the associated host objects that were used before entering the redemption grace period. If a domain name passes the 30 days of redemption grace period (75 days total after expiration) the domain name will enter the pending delete period and can no longer be restored.

A.7 Pending Delete
In the pending delete period the domain name is set for deletion. The period lasts for five working days and prohibits any process from occurring regarding the domain name. It will not be included in the zone file. After five days, the domain name will be released and available for new registration through a valid domain registration order.

A.8 Released
The domain name is deleted from the SRS and enters the available period. The domain name will be immediately available for registration to all registrars.


B. Domain Name Operations

B.1 Create Domain
A registrar uses the create command to register a domain name. Before a domain name can be created the registrar should use the check command to determine if the domain name is available. The domain name will be registered for the period specified by the registrar. This period may be from one to ten years (the default is one year). Upon registration of a domain name the registrarʹs credit is immediately debited by the registration fee multiplied by the number of years requested. The registry operator may also add an initial setup fee for a new registration. To be included into the zone file, the domain name must have at least two but no more than thirteen name servers. The registrant may add an authentication code for the domain during the creation or a randomly generated authentication code will be set for the domain name.

B.2 Delete Domain
The delete domain command allows the owning registrar of the domain name to delete it. A request to delete a domain name will cause all child name servers of the domain name to also be deleted. A domain must not be deleted if it has child name servers hosting other domains. When a domain name is deleted outside of the AGP it goes into the redemption-grace period status for 30 days. When a domain name is deleted within the AGP it is deleted immediately from the SRS and the zone file and will be available for a new registration.

B.3 Transfer Domain
The transfer process begins when a registrar initiates a transfer with a transfer domain command, the correct authentication code, and sufficient funding in his account for the transfer domain fee. The domain will be flagged in the SRS as being requested for transfer („pendingTransfer“ status). The current registrar has five calendar days to approve or reject the transfer request. If the losing registrar explicitly approves the request the domain is transferred and one year is added to the expiration date. However, the registration period cannot exceed ten years total and will be capped at a maximum of ten years. If the losing registrar explicitly denies the request, then the transfer is immediately canceled and the requesting registrar will receive a refund of the transfer fee. If the gaining registrar mistakenly sends a transfer request, they may cancel the request as long as the transfer is pending. In this case the requesting registrar receives a refund of the transfer fee. Once one of these three actions is complete the SRS creates a poll message to all participating registrars for the domain name. If no action is taken within five days, the request is automatically approved by the SRS batch system. Once a transfer is requested the losing registrar has the response options to reject, approve, or do nothing (auto approve). After the successful transfer of a domain name the old authentication code will be replaced with a new randomly generated authentication code.

B.4 Update Domain
The update command enables the owning registrar of the domain name to perform four different update operations on the domain name: Update the name servers, the authentication code, the associated contacts, and the statuses of a domain name. Possible statuses that can be updated include „clientHold“, „clientDeleteProhibited“, „clientUpdateProhibited“, „clientTransferProhibited“, and „clientRenewProhibited“. If an update command removes all name servers of a domain name, it will no longer be included in the zone file and will receive the status „inactive“.

B.5 Renew Domain
The renew domain command allows the registrar of the domain name to extend the registration period if they have enough funds for the renew domain fee multiplied by the number of years the registration period will be extended. For this TLD only one year renewals will be offered. The request for a renewal should contain the period to identify the number of years to be added to the registration period. If not provided, the SRS uses a default value of one year. The renewal request should contain the current expiration date to ensure that the domain name will not be renewed multiple times if the request was submitted multiple times due to connection problems between the SRS and the registrar. If no expiration date is given, the SRS will automatically use the current expiration date as the default value. The SRS will renew the domain name for the period specified by the registrar and returns the new registration expiration date.

B.5 Restore Domain
The restore domain command enables a registrar to restore a deleted domain name after the AGP. In order to successfully restore a domain, the registrar must submit a restore domain command and have sufficient funding for the restore domain fee. The restore operation adds the „pendingRestore“ status to the domain name until completion of the request. A successful restore will extend the registration period of the domain name by one year but is capped at a total registration period of ten years. After the restore operation, the domain name will be added back into the zone file as long as there is at least one name server and no „clientHold“ or „serverHold“ status associated. If the restore operation fails, the domain will stay in the RGP until it enters the pending delete period and the registrar will receive a refund of the restore domain fee.

C. Domain Name Statuses

To ensure the registration domain life cycle there are several domain statuses that can be seen by everyone using the RDDP (WHOIS) or by any registrar using the extensible provisioning protocol (EPP). These statuses are very important in identifying the current period a domain name is in, or identifying the problems a registrar can encounter while managing a domain name (e.g. a failing transfer request caused by a „serverTransferProhibited“ status). A foreign registrar may also be interested in the statuses of a domain name to identify when a specific domain name will be available for registration again (drop catching). Domain name statuses include EPP and RGP domain name statuses as referenced in RFC 3915. Depending on the life cycle period of a domain name, it can have an EPP and a RGP status at the same time. In some cases these two statuses can be different.

These domain statuses are compliant with the RFCs 3915, 5730-5734, and 5910. The domain statues are:

- addPeriod
- autoRenewPeriod
- inactive
- ok
- pendingRestore
- pendingDelete
- pendingTransfer
- redemptionPeriod
- serverDeleteProhibited
- serverHold
- serverRenewProhibited
- serverTransferProhibited
- serverUpdateProhibited

All server statuses are always set by the SRS. However, the owning registrar also has the ability to assign statuses to a domain name, offering the same functionality as the server statuses. These statuses are:

- clientDeleteProhibited
- clientHold
- clientRenewProhibited
- clientTransferProhibited

A domain name may have more than one status at a time, but must have at least one status. Some statuses prohibit other statuses on the same domain name.

C.1 ok
This is the default status of a domain name that has no operations or prohibitions. This value is set and removed by the SRS system as other status values are added or removed and cannot be combined with any other status. The SRS sets this status upon initial creation. A domain name with this status may be updated with any „client“ statuses and will be included in the zone file if there is at least one name server associated with it.

C.2 inactive
If the delegation information has not been associated with the domain name, this status is applied. This is the default status when a domain name has no associated host objects for the DNS delegation. This status will be set by the SRS when all host-object associations are removed.

C.3 clientHold
The owning registrar may set the domain name to this status to prevent the domain name from being included in the zone file. 

C.4 clientUpdateProhibited
If a domain name status is „clientUpdateProhibited“ it cannot be updated using an update domain command. The name servers, authentication code, contacts, and other statuses of the domain name cannot be updated until this status is removed. 

C.5 clientTransferProhibited
The owning registrar can set this status to a domain name to prevent any other registrar from successfully requesting a transfer for this domain name.

C.6 clientDeleteProhibited
If a domain name status is „clientDeleteProhibited“, it cannot be deleted from the SRS using the delete domain command. The domain can still expire after the registration period has passed. 

C.7 clientRenewProhibited
If a domain name status is „clientRenewProhibited“, it cannot be renewed explicitly by the registrar using the renew domain command. It can still be automatically renewed by the SRS batch system if the owning registrar has set the renewal mode of the domain name to auto renew.

C.8 serverHold
The SRS administrator may set the domain name to this status to exclude it from the zone file. 

C.9 serverUpdateProhibited
The SRS may set the domain name to this status to prevent any updates using the update domain command. The name servers, authentication code, contacts, and the domain name statuses cannot be updated until this status is removed. 

C.10 serverTransferProhibited
The SRS may set the domain name to this status to prevent any registrar from successfully requesting a transfer for this domain name.

C.11 serverDeleteProhibited
The SRS may set the domain name to this status. If a domain name status is „serverDeleteProhibited“ it cannot be deleted from the SRS using the delete domain command. This status is slightly different from the „clientDeleteProhibited“ as the domain will not even be deleted after the redemption-grace period.

C.12 serverRenewProhibited
The SRS may set the domain name to this status. If a domain name status is „serverRenewProhibited“, it cannot be explicitly renewed by the owning registrar using the renew domain command. It can still be automatically renewed by the SRS batch system. 

In addition, the SRS batch system may set the RGP pending period statuses as listed below. In EPP, the RGP pending period statuses are represented as substatuses of the EPP statuses.

C.13 redemptionPeriod
The SRS sets the domain name to this status when a domain is deleted after the AGP. Only the restore domain operation is allowed on a domain with the „redemptionPeriod“ status.

C.14 pendingRestore
The SRS sets the domain name to this status when a restore is requested. If a domain name status is „pendingRestore“, then no additional restore request can be successfully submitted.

C.15 pendingDelete
The SRS sets the domain name to this status once it has been in „redemptionPeriod“ for 30 days. A domain name remains on „pendingDelete“ status for five days before it is finally deleted from the SRS.

C.16 pendingTransfer
The „pendingTransfer“ status is automatically set when a domain transfer is requested by a registrar. A domain name remains in „pendingTransfer“ status until the transfer is approved, automatically approved through the SRS batch system, rejected, or canceled by the requesting registrar.

C.17 addPeriod
This period is entered after the initial registration of a domain name. If the domain name is deleted by the owning registrar during this period he will receive a refund of the domain registration fee in compliance with ICANNʹs AGP consensus policy.

C.18 autoRenewPeriod
This period is set after a domain name registration period expires and is renewed automatically by the SRS. If the domain name is deleted by the owning registrar during this period he will receive a refund of the domain renewal fee.


D. Reserved Premium Domain Names
The registry operator reserves the option to define specific domain names as reserved or premium domain names. These domain names will be in compliance with the described registration life cycle with the addition of a manual registration process through the registry operator support and legal team. Special fees may be accounted for those domain names to reflect manual processing.


E. Roles

As the resources are shared among the TLDs operated through registry.net, they are not dedicated exclusively only to one SRS project. The columns contain the number of human resources available for this role and the percentage of all people who are working for this specific gTLD. The entire registration life cycle process is fully automated by the SRS batch system. This process monitors all actions and problems regarding the registration life cycle and creates automated reports for the registrars and the registry operator.
The table in attachment 27_Figure5.1.pdf shows how the roles described below are planned for the SRS system.

Support Role
The support role of the registry operator will review these reports. If there is a logical problem, an engineer will be assigned to solve the problem. The support may manually correct or influence the life cycle of a domain name if necessary. The registry operatorʹs support role will also take care of any submitted registrar problems regarding the registration life cycle, either through the telephonic support or the ticket system.

Legal Role
All legal issues and dispute cases will be manually reviewed and processed by the legal role of the registry operator in compliance with the registry operatorʹs policy. The legal role may manually correct or influence the life cycle of a domain name if necessary.

Administration Role
The ticket system and the telephone system where the registrars submit their problem requests will be set up and maintained by the administrators. 

Designated Engineering Role
Each technical issue that is assigned by a supporter will be reviewed and solved by an engineer. Another task of the engineering role is the development of the tools that enable the support and legal roles to influence and maintain the domain life cycle.


F. List of Attachments
- 27_Figure1.1.pdf
- 27_Figure5.1.pdf

The gTLD .taxi is, as described in question 20(a), a community gTLD. Hence, TaxiPay GmbH ensures, based on the Registry Agreement, that its commissioned Registry Service Provider will validate a registrant’s eligibility for a domain at second level under the gTLD .taxi. TaxiPay GmbH itself, however, will provide an in-house validation agent in order to be able to react quickly upon possible cases of abuse and⁄or arising disputes. The main responsibility of the just mentioned validation agent is to double-proof a registrant’s eligibility for the respective domain at second level.

TaxiPay GmbH will additionally:

- Develop a trusted method of communication for all correspondence between TaxiPay GmbH and the TLDʹs registrars, to ensure that all registrant contact information, including WHOIS records, is complete and remains current, and that all requests for registration within the space may be easily verified for authenticity.
- Implement effective mechanisms for addressing abusive practices.
- Establish a point of contact for third-party reporting of abusive practices.
- Ensure accurate WHOIS data by implementing and enforcing a strict registration and validation policy. The Registry-Registrar Agreement will furthermore include the obligation of accredited registrars to validate and verify each registration request.
- Determine and implement a streamlined practice for addressing and removing orphan glue records.
- Publish on its website and include as binding registry policy an Anti-Abuse Policy, described in detail below, which provides applicable definitions of abuse and outlining steps TaxiPay GmbH will take to address any such situations.


A. Point of Contact for Abuse Complaints

The abuse email inbox will be routinely and continuously monitored several times per day. Complainants will be provided with a responsive communication containing an auditable tracking or case number.

The abuse point of contact will be responsive and effective, tasked with answering email quickly, empowered to take effective action, and guided by well-defined written criteria. This role-based function will be performed by a team of trained and qualified staff assigned to TaxiPay GmbH from the legal team of the parent entity of TaxiPay GmbH, which will ensure that the abuse point of contact has a broad familiarity with current industry knowledge and a high-level awareness of evolving online security risks. TaxiPay GmbHTaxiPay GmbHOne or more additional employees will be trained in the role overseeing the TLD as part of his⁄her duties, in order to provide “back up” assistance as needed. The abuse point of contact will be supported by one or more attorneys from a trusted law firm in Germany, with whom the abuse point of contact will consult and coordinate the correct management of disputes and reported abuse. 
With regard to the estimated number of registrations and the Registration Restrictions, these allocated resources will be sufficient to handle the expected initial volume of abuse complaints. Abuse complaint metrics will be tracked and reviewed carefully each year, and adequate resources will be expended to ensure appropriate trending of those metrics, thus providing the abuse point of contact with sufficient resources.

Given TaxiPay GmbH’s belief that infrastructure protection, rights protection, and user security are of paramount importance for a TLD owner, TaxiPay GmbH expects to ensure sufficient resources for this critical role, and to do whatever is reasonably necessary to ensure a secure and trusted zone.


B. Anti-Abuse Policy

TaxiPay GmbH will develop and implement upon launch of the TLD an Anti-Abuse Policy (AAP). The AAP will be made binding for all registrants by contractually obligating registrars through the Registry-Registrar Agreement to pass on the AAP as part of their registration agreements. The AAP will also be published prominently on the Registry website alongside the abuse point of contact and with instructions on how to best report any suspected violations of the AAP to the registry.

The AAP will be based on and expand upon existing registry policies to ensure best industry practice is followed. The goal of the AAP is to limit significant harm to internet users, to enable TaxiPay GmbH or accredited registrars to investigate and to take action in case of malicious use of domain names and to deter registrants from engaging in illegal or fraudulent use of domain names.

TaxiPay GmbH defines abuse as an action that causes actual and substantial harm, or is a material predicate of such harm, and is illegal, illegitimate, or otherwise contrary to Company policy.
“Abuse” includes, but is not limited to, the following:

- Use of a domain to defraud or attempt to defraud members of the public in any way
- Use of a domain to distribute or publish hateful, defamatory, or derogatory content based on racial, ethnic, or political grounds, intended or generally able to cause or incite injury, damage or harm of any kind to any person or entity
- Use of a domain name to publish content threatening or invading the privacy or property rights of a third party
- Use of a domain name to publish content that infringes the trademarks, copyrights, patent rights, trade secrets or other intellectual property rights, or any other legal rights of TaxiPay GmbH or any third party, or any action infringing on the named rights
- Violation of any applicable local, state, national or international law or regulation
- Use of a domain name for the promotion, involvement in or assisting in, illegal activity of any kind, as well as the promotion of business opportunities or investments that are not permitted under applicable law
- Advertisement or offer for sale any unlawful goods or services in breach of any national or international law or regulation
- Use of domain names to contribute to the sale or distribution of prescription medication without a valid prescription as well as the sale and distribution of unlicensed or unapproved medication
- Distribution of Child Pornography or other content depicting minors engaged in any activity of a sexual nature or which may otherwise harm minors
- Use of domain names to cause minors to view sexually explicit material
- Any use of domain names with regard to spam in any form, including through e-mail, instant messaging, mobile messaging, or the spamming of Web sites or Internet forums, as well as advertising for a domain name through spam
- Initiation or intentional participation in denial-of-service attacks (“DDoS attacks”)
- The use of domain names in phishing activities, tricking Internet users into divulging personal data such as usernames, passwords, or financial data
- The use of domain names in pharming , such as DNS hijacking and poisoning
- The use of domain names for the intentional distribution of spyware, botware, keylogger bots, viruses, worms, trojans or other forms of malware
- The use of a domain name in unauthorized fast flux hosting, disguising the location of internet addresses or Internet services. Fast flux hosting may be used only with prior permission of TaxiPay GmbH
- The use of domain names to command and control botnets, i.e. a network of compromised computers or “zombies”
- The use of domain names in activities intended to gain illegal access to other computers or networks (“hacking”), as well as any activity to prepare for such system penetration

In accordance with best practices in current generic Top Level Domains, TaxiPay GmbH reserves the right to either directly or through the issuing of a request to an accredited registrar deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion:

- to protect the integrity and stability of the .taxi TLD and⁄or prevent the abuse of any .taxi domain name
- to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process
- to avoid any liability, civil or criminal, on the part of TaxiPay GmbH, as well as its affiliates, subsidiaries, officers, directors, and employees
- per the terms of the Registry Agreement or
- to correct mistakes made by TaxiPay GmbH, Registry Service Provider or any Registrar(s) in connection with a domain name registration

TaxiPay GmbH also reserves the right to place a domain upon registry lock, hold or similar status name during resolution of an investigation or dispute.


C. Handling of Abuse Reports

All abuse reports received by the abuse point of contact will be tracked internally in a ticketing system to ensure accountability and ease of reference, and a tracking number will be provided to the reporter. Each report will be carefully reviewed and evaluated regarding its credibility, to determine whether the reported issue is an abuse concern and to assess the required action(s), if any. TaxiPay GmbH will work in tandem with the sponsoring registrar as well as the Registry Service Provider to rapidly address potential threats or abuse complaints, investigate all reasonable complaints, and take any appropriate action(s) thereto.

As standard practice, TaxiPay GmbH will forward all credible and actionable reports, including the accompanying evidence, if any, to the sponsoring registrar, with a request to investigate the issue further and to take appropriate action. The sponsoring registrar has a direct relationship with the registrant and therefore possesses further information not available to TaxiPay GmbH, such as payment details, sales history, and IP addresses of the customer, reseller data (if applicable) and other specific data unique to the customer. In case the registrar determines in the course of the investigation that the use of the domain name violates the applicable terms of use, ICANN policies or the AAP, the registrar is expected to take action within reasonable time. TaxiPay GmbH further reserves the right to act directly and immediately in cases of obvious and significant malicious conduct.

TaxiPay GmbH will implement valid court orders or seizure warrants from courts, arbitration tribunals, or law enforcement agencies of applicable jurisdiction as a top priority. TaxiPay GmbH will further work closely with law enforcement agencies if necessary.

Based upon the applicable registration policies and restrictions, TaxiPay GmbH does not expect further measures to be required to effectively prevent or stop malicious use. In case of an unexpected volume of credible abuse complaints, TaxiPay GmbH will take advantage of additional resources such as spam databases and blocklists, anti-phishing feeds, analysis of registration data, and DNS queries.


D. Orphan Glue Records

According to the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf orphan glue records are defined as follows:

“By definition, orphan records used to be glue records. A glue record becomes an ‘orphan’ when the delegation point NS record referencing it is removed without also removing the corresponding glue record. The delegation point NS record is sometimes referred to as the parent NS record.”

An orphan glue record can occur whenever a domain is placed in ServerHold or ClientHold status. In these cases, the domain is removed from the zone file but existing name servers of this domain will be kept in the zone file so that other sites which are still using these name servers are still kept functional.

Example:
“example.string” is deleted from the zone file by setting to ServerHold status, but “ns1.example.string” will be kept in the zone file.

D.1 Prevention of Orphan Glue Records During Domain Deletion

Deleting a domain name is only possible if there are no glue records used by other domains associated with the domain being deleted.

If there are glue records available but not used by other domains in the registry, the glue records will be deleted prior to the domain deletion. Whenever there are glue records available which are still in use, this has to be resolved first. If there are no glue records at all the domain can be deleted instantly.

Solving the problem of glue records for domains which are supposed to be deleted can be done by checking the zone file. The zone file reveals the domains which are using the name servers. Once the required information is available, the named registrars must be contacted and new name servers should be set for the remaining domains in order to release the glue records.

In cases where glue records are being used in a malicious way, the abuse point of contact has to be contacted. The abuse point of contact will check this issue and take any appropriate actions, which may result in removing relevant records from the zone file in case the abuse complaint is valid.


E. Preventive Countermeasures

Pharming is an abusive practice used to gain illegal access to personal and confidential internet user information by diverting internet traffic through the manipulation of the information between the recursive resolver name server and the client software (e.g. web browser) (DNS-cache poisoning). Since pharming is commonly accomplished by redirecting traffic at the recursive DNS level, mitigation is most effective at the ISP level.

However, as an added countermeasure, the Registry Service Provider registry.net will sign the domain zone using DNSSEC, as detailed in the answer to question 35, allowing the relying party to establish a chain of trust from the DNS root down to the domain name, thus validating DNS queries in the zone.

Registrars will be encouraged to use a DNSSEC enabled DNS hoster and to provision the related delegation signers (originating from the DNS hoster) to registry.net’s SRS via EPP. This way it will be possible for the relying party to validate DNS queries and to protect from DNS tampering to a certain degree.

DNSSEC is a set of records and protocol modifications that provide authentication of the signer of the DNS data, verification of integrity of the DNS data against modification, non-repudiation of DNS data that have been signed, and authenticated denial of existence of DNS records. DNS data secured with DNSSEC are cryptographically signed and incorporate asymmetric cryptography in the DNS hierarchy, whereby trust follows the same chain as the DNS tree, meaning that trust originates from the root and is delegated in the same way as the control of a domain. When a domain name in the TLD is requested by a browser, the signature is validated with the public key stored in the parent zone.


F. Promoting Accurate WHOIS Data

TaxiPay GmbH is committed to maintaining the zone as a safe, secure online environment. A key component of such a plan is the creation and upkeep of accurate WHOIS records for the registry. 

As indicated in detail in the above answer to Question 26, TaxiPay GmbH will develop strong safeguards to verify the accuracy and privacy of the data stored in the WHOIS database, and will ensure that such records will be publicly-available to the extent required by ICANN regulations. The WHOIS records for this TLD will constitute a “thick” WHOIS, combining all applicable data and information for domain name registrants in a central location.


TaxiPay GmbH shall expressly reserve the right to cancel or suspend any domain name registrations within the space should a registrant fail to provide accurate or complete whois information. Details will be executed in the Registration Guidelines.

In order to ensure Whois Accuracy, registrars will be obligated by the Registry-Registrar Agreement to commit registrants to provide only current, accurate and complete whois data according to the Registration Guidelines. 

The Registry Service Provider will ensure that registrars comply with the contractual agreements to provide accurate data, including the use of field-valid telephone and fax numbers and the use of country names as defined under ISO 3166. 

Complaints about Inaccurate Whois Information can be filed by everyone via InterNICs website (http:⁄⁄www.internic.org). The well developed process for the Whois Data Problem Reports (WDPR) will assure a prompt investigation by the responsible registrar and - in case - correction of whois data.

Registrars will be obligated by the RRA to fulfill ICANNs Whois Data Reminder Policy (WDRP). This means, a registrar must present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.

TaxiPay GmbH will take adequate measures to ensure whois accuracy by random examinations of whois data against public registers like telephone directories or other suitable measures.



G. Registrant Authentication

TaxiPay GmbHPossible registrars will be responsible for making sure that only authenticated registration requests will be submitted to the registry, ensuring the accuracy of the WHOIS. This means in detail that registrars are in full responsibility of verifying a registrant’s affiliation to the taxi community (as described in question 20(a)), as well as the completeness and accuracy of the examined data, thus ensuring that only eligible registrants will be part of the newly-formed online community under the gTLD .taxi. Effectively, this will ensure that all WHOIS data is 100% accurate and pre-validated.

TaxiPay GmbH will accordingly maintain strict control over the registration and use of this TLDʹs domain names. Only authorized personnel will be able to release a name from reservation and register it for use through an ICANN-accredited registrar. Likewise, only authorized company personnel will be able to make DNS changes or alterations to the WHOIS data for the domain names. TaxiPay GmbH will require multiple unique points of contact to request and⁄or approve update, transfer, and deletion requests, and will require notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted.

These checks will include a clear, written policy detailing the steps by which such corporate authority may initiate the request for a domain name registration in the TLD. The concerned registrar(s) will have the ability to register domain names in this TLD only upon receipt of the proper corporate approval. Furthermore, there will be strict policies in place to prevent unauthorized changes to name servers, WHOIS or other DNS information, including registration of third- and higher-level subdomains.

In the event that TaxiPay GmbH decides to license the use of this TLD domain names or subdomains to affiliates, additional levels of corporate approval may be required in order to ensure the proper use of such domain names.


H. Licensed Domain Names

TaxiPay GmbH may, from time to time and in its sole discretion, elect to license the use of its TLD domain names to its affiliates. TaxiPay GmbH will ensure that any such licensed affiliates will have only a limited license to use the allocated domain name, subject to continuing compliance with all policies in place during that time. Should TaxiPay GmbH elect to offer such license arrangements, additional corporate approval may be required to ensure internal responsibility for overseeing and enforcing the terms of the license. 
Any licensee(s) must warrant they will not assign the license or sublicense any subdomain without

- securing the sublicenseeʹs agreement to any and all terms required by TaxiPay GmbH, including the Acceptable Use Policy and all other applicable policies
- obtaining TaxiPay GmbH’s prior consent in writing
 

I. Ensuring Proper Access to Domain Functions

The Registry will be operated using a comprehensive and detailed authentication system designed to implement a wide range of registry functions for both internal operations and as external registrar access. Registrar access will be limited by IP address control lists and TLS⁄SSL certificates, as well as verification processes for proper authentication and appropriate limitations to restrict access to the sponsored objects.

Each domain name will be assigned a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time a domain is created and which can be modified by the registrar at any time. Its purpose is to aid in the identification of the domain owner so that proper authority can be established. For example, a registrar-to-registrar transfer can be initiated only by using the correct AUTH-INFO code, to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the authorized registrant. Access to the domain’s AUTH-INFO code, stored in the registry, is limited to the sponsoring registrar and is accessible only via encrypted, password-protected channels.

Registrars will be obligated by the RRA to provide best practice processes like Form-Of-Authorization (FOA) emails to confirm a domain name transfer and will be encouraged to take advantage of the domain status clientTransferProhibited to mitigate abuse.

Further security measures are anticipated and will be implemented in the new space, but are currently treated as confidential for security reasons. Accordingly, a full explanation of these mechanisms may be found in the response to Question 30(b).


J. References and Attachments

http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf

Rights holder protection is a core element of TaxiPay GmbH’s approach to the management of new TLD spaces. We have built our comprehensive rights-protection plan by carefully reviewing the many mechanisms developed during the launch of other recently introduced and already established TLDs in order to learn from previous experience and find innovative solutions to certain common issues. Our outsourced registry service provider, registry.net GmbH, will comply with all required management and gateway mechanisms needed for the TLD. Thus, the outsourced registry service provider and TaxiPay GmbH will jointly undertake the following actions:

- Implement appropriate registration enforcement mechanisms during the various critical phases of the registry launch
- Execute a well-defined Sunrise period in compliance with ICANN requirements, which will include implementation of the Trademark Clearinghouse notification system
- Implement a professional Trademark Claims program, utilizing the Trademark Clearinghouse and drawing upon models of similar programs used successfully in previous TLD launches
- Enlist a third party Trademark validation service, as necessary, during the Sunrise period in conjunction with using the Trademark Clearinghouse
- Commit to operating the URS (Universal Rapid Suspension) Policy as described in the draft Registry Agreement
- Commit to operating and implementing the UDRP (Uniform Domain Name Dispute Resolution Policy) when and as needed in our capacity as the Registry Service Provider for the space
- Comply with the new Trademark Post-Delegation Dispute Resolution Procedure (PDDRP)
- Comply, as a named party, with findings issued in any Trademark Post-Delegation Dispute Resolution Procedures (PDDRP)
- Embed all rights protection elements that require compliance support or involvement with Registrars and⁄or their resellers into the Registry-Registrar Accreditation Agreement for all domains of this TLD
- Ensure the inclusion of all ICANN-mandated and TLD-specific rights-protection mechanisms in the Registry-Registrar Agreement entered into by ICANN-accredited registrars authorized to register names in the TLD, including oversight of all provisions to be included in the end-user Registration Agreements in effect as between the registrar and registrants of this TLD.

The following provides a brief outline of the steps the Registry Service Provider intends to implement in conjunction with the Registry Operator for the proper function of this new TLD space.


A. Trademark Clearinghouse

The Trademark Clearinghouse is a new service offering provided for under the ICANN New gTLD program. It will provide a mechanism to notify trademark holders of qualified Sunrise applications for textual strings that present an identical match to their trademarks. The Clearinghouse system will be comprised of the following elements:

- Registration of marks in the Clearinghouse by trademark holders will be validated by the Clearinghouse operator, utilizing trademark filings and other rights as applicable under the established policies for the Trademark Clearinghouse
- An asynchronous comparison of marks submitted during Sunrise with the Trademark Clearinghouse
- Should an exact match be identified between an applied-for textual string and a mark registered in the Clearinghouse database, notification will be provided to the relevant mark holder and the Sunrise applicant in the manner and means specified in TaxiPay GmbH Guidebook

TaxiPay GmbH will comply with all required elements of the Trademark Clearinghouse system, and will utilize a trademark validation agent as necessary to assist with the Sunrise procedure.


B. Sunrise Procedure

B.1 Sunrise Mechanism

The TLD Sunrise period will be conducted in compliance with ICANN specifications. 

TaxiPay GmbH will develop a fully compliant Sunrise policy, which will define what domains may be applied for during Sunrise applications and detail all dispute policies, including its SDRP (Sunrise Dispute Resolution Policy), for challenging the validity of Sunrise registration. This very sunrise policy will include different phases for major non-governmental representatives of the taxi community, relevant (i.e. taxi-affiliated) owners of trademarks and rights holders, as well as extraordinate members of the taxi community. The elected SDRP dispute provider will be a member of ICANN’s list of approved UDRP providers. TaxiPay GmbH will consult with both the dispute provider and expert legal counsel in drafting and finalizing the Sunrise Policy.

The Sunrise period will run for a minimum of 30 days prior to the general availability of domain names and will include a minimum two week quiet period. The registration functions will not be available during the quiet period while we work to complete related Trademark Clearinghouse matches and related notifications.


C. Eligible Rights

The proposed Sunrise Eligibility Requirements (SERs) will conform to the following qualifications derived from numerous past TLD Sunrise programs:

C.1 Ownership of a qualifying mark

In accordance with Section 7.2 of the ICANN Applicant Guidebook, number (i): The registry will recognize and honor all

- Word marks that are nationally or regionally registered and for which proof of use (which can be a declaration and a single specimen of current use) was submitted to, and validated by, the Trademark Clearinghouse
- Trademarks not in the Clearinghouse but that are verified by a third party Trademark validation contractor and conform to the following standards:
 * the Domain Name is identical to the textual or word elements of the trademark or service mark registration on which the registration of the Domain Name is based; AND
 * the trademark or service mark registration on which the registration of the Domain Name is based is of national effect; AND
 * the trademark or service mark registration on which the registration of the Domain Name was based was issued (registered) prior to [a cutoff date to be determined]
- Representation that all provided information is true and correct
- Provision of data sufficient to document rights in the trademark


D. Application Process

All submissions during Sunrise will be accepted as applications only and not a full registration until the Trademark has been validated to conform per the SERs listed above, and the Sunrise applicant has been determined to meet the eligibility requirements for registration in this TLD. Multiple applications for the same string, were they to occur, would be allowed from multiple Trademark holders. Contention would be resolved on a first come first served basis were there to be more than one qualifying applicant. Following winning an auction, or if there is a single qualifying applicant, the application would be promoted to a full domain registration.

D.1 Field Submission and Validation Safeguards

To support the Sunrise process the registry system will apply requirements to data submissions, in the registry application. registry.net will use the data fields⁄extensions from the DotAsia and DotXXX launches. The field types listed below are mandatory during Sunrise submissions and are not able to be updated once an application has been submitted in order to avoid manipulation of the validation process. Please see the related EPP extension 〈insert name〉 attached to the Question 25 response.

IPR Name 〈ipr:name〉

The word mark of the trademark, as noted in the trademark or service mark registration record.

IPR Number 〈ipr:number〉

The registration number (not the application number) of the trademark.

IPR Applied Date 〈ipr:appDate〉

The date the trademark was applied for.

IPR Registration Date 〈ipr:regDate〉

The date the trademark was registered. This is the date that the trademark was granted.

IPR Registration Locality 〈ipr:ccLocality〉

The two-letter code for the nation or national jurisdiction the trademark was registered in. Allowable values will be limited to identify national trademark registries and regional trademark registries (such as the Benelux and EU trademark registry registrations).

IPR Registered Class 〈ipr:class〉

Number of the Class of the Registered Mark according to the Nice Classification System (http:⁄⁄www.wipo.int⁄classifications⁄nivilo⁄nice⁄index.htm#).

IPR Entitlement: 〈ipr:entitlement〉

Whether TaxiPay GmbH (corresponding to the Registrant Contact) holds the trademark as the original “owner,” “co-owner,” or “assignee”.

D.2 Trademark Validation and Safeguards

As mentioned previously we will employ a Trademark validator to examine Sunrise applications (please see question 28). The Trademark Validator will have the ability to request additional data or clarifying materials about any Sunrise Application, including additional direct verification of the Sunrise applicant’s identity in respect to the cited trademark.

The contracted party will be globally experienced in intellectual property law and will employ the following stepped process and functions:

Examination of Trademark

Trademarks will be validated against either the Trademark Clearinghouse, or against a National Trademark Database from a qualifying country. This is required for a Sunrise application to be considered “qualified or validated”.

Deterrents

In policy documents, training materials, and FAQs, we will communicate clear language indicating that administration fees associated with filing Sunrise applications are NOT refundable. The administration fee will be designed to recover validation costs and should financially dissuade frivolous applications.

D.3 Contending Applications, Sunrise Auctions

The Registry will complete all Sunrise application validations following the close of the Sunrise period. There are only three possibilities for outcome and subsequent actions:

- One valid application for a given string:
 * The domain will be awarded to that applicant
- Two or more valid applications for the same string:
 * The domain will be offered to the applicants on a first come first serve basis. The earliest applicant will be awarded the domain.
- No valid applicants for a given string:
 * The domain will be offered in subsequent phases of the Registry but without Trademark requirements.

D.4 Additional Considerations


Domains awarded under Sunrise will be locked (Sunrise lock status) for at least 60 days following the procedure to support parties wishing to file a Sunrise Challenge.

Once a Sunrise domain is awarded, it will be promoted to a full registration and the relevant RDDS (WHOIS) data will be published as per standard Registry RDDS (WHOIS) policy.

Conflict of Interest restrictions will be applied to employees, contractors, consultants and significant investors of the Registry disallowing participation in Sunrise auctions. See also the answer to Question 28.


E. Sunrise Challenges

The Sunrise Dispute Resolution Process (SDRP) will allow challenges based on the following four grounds:

1. at the time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect
2. the domain name is not identical to the mark on which the registrant based its Sunrise registration
3. the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect)
4. the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received

We see that ICANN’s Module 4, “Trademark Clearinghouse” document, paragraph 6.2.5 says “The Clearinghouse will maintain the SERs, validate and authenticate marks, as applicable, and hear challenges.” We are not sure exactly what “hearing challenges” means. If it means that the Clearinghouse Provider is the only party that can adjudicate Sunrise Challenges, then of course the TLDʹs Sunrise Challenges will go there to be heard. Otherwise, we will retain the services of a well-known dispute resolution provider such as WIPO to receive and adjudicate the Sunrise Challenges. All applicants and registrars will be contractually obligated to follow the decisions handed down by the dispute resolution provider.

After any Sunrise name is awarded to an applicant, it will remain under a “Sunrise Lock” status for at least 60 days so that parties will have an opportunity to file Sunrise Challenges. During this Sunrise Lock period the domain name will not resolve and cannot be modified, transferred, or deleted by the sponsoring registrar. The domain name will be unlocked at the end of that lock period only if it is not the subject of a Sunrise Challenge. Challenged domains will remain locked until the dispute resolution provider has issued a decision, which the registry operator will promptly execute.


F. Continuing Rights Protection Mechanisms in the Specific TLD Space

Following the conclusion of the Sunrise period for this TLD space, certain rights protection mechanisms will continue to be active. These mechanisms are the dispute resolution policies, which shall include the URS, UDRP, Trademark PDDRP, a Trademark Claim Service and any other policies ICANN may enact from time to time via the adoption of Consensus Policies.

F.1 Uniform Rapid Suspension (URS)

The registry operator will implement decisions rendered under the URS on an ongoing basis.

As per the URS policy, the .taxi registry operator will receive notice of URS actions from ICANN-approved URS providers. These e-mails will be directed immediately to our support staff, which is on duty 24 x 7 x 365. The support staff will be responsible for executing the directives from the URS Provider, and all support staff will receive training in the proper procedures.

As per ICANN’s URS guidelines, within 24 hours of receipt of the Notice of Complaint from the URS Provider, our staff will lock the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The support staff will accomplish this by associating the following EPP statuses with the domains and relevant contact objects:

- ServerDeleteProhibited, with an EPP reason code of “URS”
- ServerTransferProhibited, with an EPP reason code of “URS”
- ServerUpdateProhibited, with an EPP reason code of “URS”

Our support staff will then notify the URS Provider via e-mail immediately upon locking the domain name.

Our support staff will retain all copies of the e-mails from the URS providers. We will assign each case or order a tracking or ticket number. We will use this to track the status of each opened URS case through to resolution via a database.

Our support staff will then execute further operations upon notice from the URS providers. Each URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the Complainant, and the Registrar. We will set up the necessary DNS re-pointing required by the URS guidelines.

The guidelines state that if the Complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS Provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”

F.2 Uniform Dispute Resolution Policy (UDRP)

Although UDRP actions are typically implemented at the Registrar level, it’s conceivable that a court order may be directed to the Registry through the APOC. Such an order would be escalated to the support and⁄or legal department contacts as required. Support staff would quickly affect a mandated transfer, if so ordered, or an order requiring the lock-down of a domain name. The Registry’s legal counsel would also typically verify the court order. Registry functionality outlined in the answer to Question 27 describes the necessary functionality required by Registrars to support their UDRP commitments, and TaxiPay GmbH is committed to meeting these standards.

F.3 Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP)

TaxiPay GmbH would be the defending party in a Trademark PDDRP. TaxiPay GmbH commits to abiding by the directives of the Trademark PDDRP Provider assigned by ICANN, up to and including the cessation of all registration activities and cancellation of the Registry Agreement with ICANN.

F.4 Trademark Claims Service:

For at least the first 60 days of general registration, the Applicant will enable a Trademark Claims service for trademarks recorded in the Trademark Clearinghouse, which will provide a real-time notice to a party attempting to register a domain name if it matches a trademark in the Clearinghouse and notify trademark holders when domain names are registered that match marks in the Clearinghouse.


G. Contractual Operation of Provision via the Registry-Registrar Agreement

The Registry-Registrar Agreement will be signed by all registrars interested in offering registrations under the TLD .taxi. This agreement will contractually bind such registrars to follow certain registry-mandated procedures, and will include inter alia the following provisions:

- The registrar will ensure that the relevant Registrar-Registration Agreements between itself and any prospective registrant in the TLD space will incorporate all registry-mandated policies, restrictions, and guidelines
- The registrar will comply with all eligibility and registration restriction criteria established by the registry in issuing registrations within the .taxi space. The registrar shall not register a domain name to an individual or entity who does not meet the eligibility criteria for registration within the TLD
- The registry shall have the authority to refuse or reject any registration request received for a domain name within the TLDʹs space, or to cancel, transfer, delete, suspend, revoke, or otherwise modify a registration within the space, for the following reasons:
 * The domain name was registered through a registrar error or oversight, the provision of inaccurate data, fraud, or mistake, and the registrant is determined to be ineligible to register domain names within the TLD
 * The request for registration was not made in the proper format, did not contain sufficient information under ICANN and⁄or registry requirements, or such information was not properly updated as required by ICANN and⁄or registry requirements
 * In order to rectify or correct any mistake or error made by the registry or registrar in the registration of the domain name
 * In order to comply with any request received from law enforcement, a court order, arbitral panel decision, appropriate dispute resolution provider, or to comply with any applicable laws or regulations
 * For the purpose of protecting the stability, safety and integrity of the registry, the TLD infrastructure, or the stability of the DNS
 * In order to avoid any civil or criminal liability on the party of the registry, its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders
 * In order to establish, assert or defend the rights of the registry or any third party
 * For any other reason provided for in either the Registry-Registrar Agreement or the Registrar-Registrant Agreement.


H. Preventative Safeguards

TaxiPay GmbH will implement several additional mechanisms to prevent misuse of the .taxi space, including the introduction of best practices, standards and a comprehensive monitoring system.

H.1 Best Practices - Reducing Opportunities for Behaviors such as Phishing or Pharming

The extensive mark requirements and trademark validation procedures during the Sunrise phase will prevent the registration of effective phishing domains during the start-up period.

In our answer to Question 28 (“Abuse Prevention and Mitigation”), we described our strong anti-abuse program, which is proven to shut down phishing and pharming and has provisions for rapid takedown of domain name abuses. The system prompts notification of relevant registrars for rapid take-down action should phishing activity be identified. Please see the full explanation of this system above under Question #28.

This program will deter bad actors from operating within the space by reducing the effectiveness of their attempts to initiate phishing domains, without infringing upon the rights of legitimate registrants. Since pharming is commonly accomplished by redirecting traffic at the recursive DNS level, mitigation is effective at the ISP level.

H.2 Monitoring of the Success of Abuse Prevention Programs

Every six months, the Anti-Phishing Working Group (APWG) publishes its latest Global Phishing Survey, which is made publicly available on the Group’s website. This study contains an analysis of phishing per TLD. TaxiPay GmbH will review the performance of our anti-abuse program by using the APWG reports and other metrics developed within the security community. TaxiPay GmbH notes that, according the APWG’s available data for 2011, only around 12% of malicious phishing sites contained a brand name (or misspelled variant) in the relevant domain name, and that in the 2010-2011 data only 5,700 brand-targeted phishing sites were known worldwide. Accordingly, phishing represents a very small percentage of brand-targeted domain name registrations, and TaxiPay GmbH believes its adopted best practices and restrictive registration policies will mitigate the risk of bad actors entering the TLD space.

registry.net GmbH, as the registry backend provider of the registry.net system (RegEngine), attaches great importance to the security of the entire registry infrastructure as well as business and customer data. Having more than 16 years of experience in the domain business, InterNetWire Communications has imparted extensive expertise about threats, possible vulnerabilities, and suitable countermeasures to its new subsidiary registry.net GmbH. In case of an attack, the entire staff working on the RegEngine is trained to react quickly to any security issue that may arise. Distinct escalation plans with clear roles for each employee at registry.net GmbH are defined for any possible incident. All team members have access to these plans at any time, according to their security clearance and role.

These plans and security rules are subject to a regular audit schedule and are documented in registry.net GmbHʹs security policy, which includes the Registry Information Security Policy that covers the basic registry services. These services include, but are not limited to, the safety of the technical backend (covering items such as EPP and RDDS, DNS and DNSSEC policies, an ESCROW policy, SFTP, etc.).


A. Security Policy

registry.net GmbH has established a security policy that contains the complete Registry Service Policy, covering the basic registry services. The Registry Service Policy is complimented by policies regarding technical, organizational, and personnel issues for:

- Network structure
- Network and system access
- Wireless networks
- Malware
- Setup of servers and client systems
- System and software updates
- Firewall and IDS
- Removable media
- DNSSEC
- Backups and ESCROW
- Physical Security
- Emergencies and Monitoring
- Continuity

Additional policies cover the behavior of employees concerning passwords, remote access, general communication and allowed tools and describe the handling of general procedures, audits, maintenance and monitoring. These policies are described in detail and attached to AGB question 30b. 

The security policy drafted by registry.net GmbH is based on an extensive threat analysis and is thus tailored closely to the registry services. The introductory investigation of both common and rare security issues to the registry service and to the business in general is accompanied by examples with representative solutions and references to the corresponding policies. 

Based on the analysis, certain notable aspects of the policy, as determined by the threat analysis, are (a more complete description of the policy is detailed in answer 30b):

- To prevent unauthorized access to internal and external services as well as data of all possible security levels, all employees are only provided with the access rights needed for their assigned role and obliged to follow a strict policy regarding the strength, the periodical change and the storage of their password. Updates or new software installations cannot be deployed by engineers themselves but must be managed by the change manager, who reviews the quality management reports and determines deployment procedures
- The administration is also split into different roles to prevent too much access being given to one single point. Access to servers is only possible with individual user rights, there are no superuser logins. All actions on the servers are logged and monitored. All servers are secured against external manipulation by physical separation and limitation to internal IP addresses as far as possible. The network is also separated into different layers depending on each layerʹs function and security level with each layer having its own security measures installed, including firewalls that check every request traveling from one layer to another
- The object data stored by registry.net GmbH is secured in several, geographically distributed data centers with high security standards and which are constantly being backed up to prevent the danger of data loss and to guarantee continuity
- Denial of Service attacks are countered by measures appropriate to the target within the infrastructure. The DNS infrastructure of registry.net GmbH is widespread and reliable to withstand attacks and is additionally secured against manipulation by DNSSEC. Attacks against other services are immediately identified by the Intrusion Detection System and repelled by the firewall and its corresponding rules
- Authorized registrars connect to services offered by registry.net GmbH via encrypted communication. The EPP gateway can be only used with SSL or TSL and an additional check is made for correct authorization credentials for each connection. Each writing operation is logged which allows the reconstruction of every past transaction
- The registrarsʹ frequency of usage of the non-public services is generally monitored to prevent flooding and to guarantee reliable and stable services for all other registrars
- All software used by registry.net GmbH, both developed in-house and acquired from third-party providers, is not deployed until it has been intensely tested by the quality management team. All registry systems, both hardware and software, are under constant monitoring from at least two different locations, and quick reaction times from the Administration Team, the ERT and the engineers are guaranteed 24 X 7 with defined emergency plans and procedures for all kinds of security issues or misbehavior of any component of the infrastructure. The monitoring is fully redundant on system and network level with different software solutions being used to additionally eliminate possible malfunction. Two leading enterprise monitoring solutions are used with the services running on separate hardware. All checks within the monitoring are continuously optimized by engineers and administrators, especially after software updates which are followed by determined check reviews

Regular audits of policies and procedures ensure a steady state of preparation for the entire team and allow for fast and appropriate escalation procedures. In case of an emergency incident, the administration will be very quickly mobilized by the monitoring and then follow the defined emergency procedures by either solving the problem immediately or activating the responsible roles within the company. Procedures and guidelines for any possible incident have been defined from the preceding threat analysis and describe:

- all required steps such as data restoration from backups or fail over to a secondary data center;
- the affected, involved and responsible roles; and
- the necessary details for the concluding report

After the incident, the involved team members file an accurate report which they forward to the role responsible for the corresponding policies, who then checks the policies for complete coverage. The policies then undergo a review by the responsible team members and the Chief Security Officer (CSO) of registry.net GmbH to determine necessary changes based on the report. In case of changes, the CSO is responsible for a final review and the supervision of the policy revisions. Policy reviews are also triggered prior to software updates, the introduction or change of processes, or changes to the infrastructure in general. This procedure guarantees that the policies are continuously up to date and that their coverage is complete. 

The beginning and end of employment of a team member also follow defined routines especially the assignation and termination of access rights, respectively. Each policy contains strict rules for enforcement and the measures taken in case of policy violation. The CSO of registry.net GmbH holds the general responsibility for policy compliance. The security policy describes additional responsibilities of certain roles and the corresponding policies and lists all affected roles within the company. 

These policies are developed alongside the ISO⁄IEC 27001 requirements, accompanied by the code of practice given in the ISO⁄IEC 27002 (source: http:⁄⁄www.iso.org⁄iso⁄catalogue_detail?csnumber=42103). More details can be found in section B. The backup strategy is a TIER 4 strategy following the best practice guide by IBM redBooks (source: http:⁄⁄www.redbooks.ibm.com⁄abstracts⁄tips0340.html?Open).


B. Commitments

registry.net GmbH, the registry backend technology provider for the domain registrar InterNetWire Communications GmbH, benefits from InterNetWires more than 16 years of experience in the domain business and its associated processes (with some team members working even longer in this field). As an ICANN accredited registrar and member in several work groups and technical boards representing a range of registries, InterNetWire is developing all systems in keeping with the requirements of registrars, registrants and brandowners worldwide. 

These requirements are covered by our security policy in general and are implemented in certain policies as our registry service policy or other specifically mentioned policies. The customers of registry.net GmbH can rely on:

- Secure storage and handling of confidential customer data, with clearly defined access rules for virtual access in our ÒNetwork and System Access PolicyÓ and physical access in our ÒPhysical Security PolicyÓ
- All objects are stored in one secured, central registry database as registry.net GmbH supports a thick registry system
- A reliable and widespread DNS system, additionally secured by DNSSEC with its rules being defined in our ÒDNSSEC PolicyÓ
- Secure communication from the registrants, over the registrars to the registry
- A guarantee that no changes to the registry technology will be made if these changes bear a risk of malfunction, as described in our specific ÒSystem and Software Update PolicyÓ

registry.net GmbH will also enforce the policies distributed on all levels of usage of the registry system. The complete staff is trained and audited in every policy the team member is affected by and constantly aware of the great importance of a secure system.

The registry operator is obligated to inform the registrars about all important agreements, general terms and conditions, events and notifications, and must also include these in its own registration agreement that is passed to the registrants. registry.net GmbHʹs extensive documentation of the registry system interfaces such as EPP is provided as white-label and can be forwarded from the registry to registrars or even registrants if desired.

Accredited registrars should nominate persons who are authorized to contact the registry.net GmbH 24⁄7 support in urgent emergency cases. These individuals have to prove their identity with a previously agreed passphrase. It is the registrars responsibility to provide support for their registrants and to decide if support requests have to be escalated to the registry at any time benefiting from registry.net GmbH Support described above.


C. gTLD Specific

registry.net GmbH guarantees a high level of security that is also reviewed and refined on a regular basis. The security policies and procedures comply with the general requirements of a technical registry operator with no need for deviation for this TLD. If any changes to the description of this TLD should occur in the future, registry.net GmbH is able to rapidly adapt new policies and procedures as required.


D. Resources and Roles

D.1 Trusted Roles

InterNetWire Communications GmbH has gathered experience in various roles in the domain business for more than 16 years and has access to extensive knowledge in the domain business. This deep industry knowledge and experience has also been transferred to registry.net GmbH, the technical provider of the registry.net system (RegEngine) and is evident in many trusted persons serving in different roles throughout the company.

All employees, contractors, and consultants that have access to or control of the registry.net system are regarded as trusted persons.

The following Trusted Roles are used for managing the RegEngine solution:

- Security Role: Chief Security Officer (CSO)
- Designated Engineering Role
- System Administration Role
- Security Administrator Role 
- DNS⁄DNSSEC Role
- Operational Role
- Support Role
- Quality Management Role
- Change Management ⁄ Project Management Role 
- Financial ⁄ Controlling Role
- Legal Role

Each role is staffed with multiple human resources for backup and capacity purposes.

Prior to employment in a Trusted Role, registry.net GmbH performs the following background checks on a prospective candidate:

- Criminal Records Bureau check
- Verification of previous employment
- Check of professional references

Complete role descriptions are given in the security policy in answer 30b.

D.2 Project Resources

The table in attachment 30a_Figure1.pdf shows how the roles described above are planned for the SRS system. All resources at registry.net GmbH are dedicated to the registry business. The calculations differ between the project phase and the years after the operational start. The project phase requires more resources as there is much planning, managing, and development required. All resources are engaged in the domain industry only and are experts in their field.

However, as the resources are shared among the TLDs operated through registry.net and are not dedicated exclusively to one SRS project, the columns in the attached figure contain the number of human resources available for this role and the percentage of time those people are working for this specific string. This percentage is the guaranteed time the resources are allocated to each SRS project.


E. List of attachments

- 30a_Figure1.pdf