Application number: 1-1012-71460 for SportAccord

SportAccord

Avenue de Rhodanie 54
Maison du Sport International
Lausanne 1007
CH

+4121 612 3070

+4121 612 3071

http:⁄⁄www.sportaccord.com

Mr. Pierre Germeau

Digital Media Manager

+33450991629

pierre.germeau@sportaccord.com

Mr. Werner Staub

Coordinator of the Permanent Secretariat

+41 22 7006503

werner@axone.ch

Not-for-profit Association

Articles 60-79 of the Swiss Civil Code

Not Available

Pierre Germeau
Digital Media Manager
Vincent Gaillard
Director General

Antonio ESPINOS ORTUETA
Council Member
Denis OSWALD
Council Member
Espen LUND
Council Member
Gian Franco KASPER
Council Member
Hein VERBRUGGEN
President
Jan FRANSOO
Council Member
Pat MCQUAID
Council Member
Ron FROEHLICH
Vice President

sport

Not Available

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

Q18a Description
18.a.1 Mission and Purpose of .SPORT
SportAccord is submitting this application on behalf of a global Sports community to ensure that the .SPORT gTLD shall serve as a trusted and intuitive name space for the global Sports community. The Sport Community is organized primarily through International, Regional and National Sports Federations and their members. All domain names registered within the .SPORT gTLD will be required to comply with the following three policies: Registrant Eligibility (who can register within the .SPORT gTLD); Name Selection Criteria (what domain names can be registered); and Authorized Usage Policy (how the domain names can be used). The umbrella of policies will provide the Sports Federations the confidence that the .SPORT gTLD can be operated on behalf of the global Sports community. The registry will incorporate both active and passive safeguards into its operation to ensure that these registrants continue to abide by the terms and conditions set forth in the registration agreement.
 
SportAccord is fully committed to operating the .SPORT gTLD in a commercially viable manner, as evidenced by the formal Request for Proposal (RFP) process that it undertook as part of this application process. However, SportAccord is also filing this application for defensive purposes to ensure that a .SPORT gTLD is kept out of the hands of a third party that for commercial reasons may turn a blind eye toward illegal and or inappropriate activity within the gTLD. While SportAccord closely analyzed the objection mechanisms currently incorporated into the Guidebook, it was decided that filing this application was the most prudent course of action in the collective interests of the global Sport community.

18.a.2 SportAccord’s Role and Legacy as a Trustee to the Global Sport Community

SportAccord was originally founded in 1967 when delegates from 26 international sports federations met in Lausanne. The purpose of this meeting was to address the need for permanent liaisons between the IFs, for the defense of their objectives and common goals, the preservation of their autonomy and constant exchange of information. The name “General Assembly of International Sports Federations” was adopted.

In 1976, this name was replaced by “General Association of International Sports Federations” (GAISF). GAISF represented the logical continuation of the past IFs’ meetings, dealing not only with Olympic matters but also with all questions of common interest for the IFs. In 2003, in collaboration with ASOIF (Association of Summer Olympic International Federations) and AIOWF (Association of International Olympic Winter Sports Federations), GAISF launched the first SportAccord Convention. The objective was to answer a growing need of the IFs for a “one-stop-shop” where they could all hold their annual meetings, network and share knowledge. In March 2009, GAISF was rebranded SportAccord at the meeting of the 7th SportAccord International Convention in Denver.

Today SportAccord serves as the umbrella organization for all (Olympic and non-Olympic) international sports federations as well as organizers of multi-sports games and sport-related international associations. Currently, SportAccord comprises 90 international sports federations governing specific sports and 15 organizations which conduct activities closely related to the international sports federations. SportAccord has defined conditions for membership which focus on three principles: good governance, universality, and ethics⁄social responsibility.

18.a.3 POTENTIAL BUSINESS MODELS

SportAccord is still analyzing potential use case options on the type of domain names to be permitted to be registered and by whom. This analysis is currently being undertaken by an independent Policy Advisory Board (PAB) supported by SportAccord for the purpose of recommending policy and best practice advice for the .SPORT gTLD and any other sport themed gTLD that may wish to voluntarily adopt its best practices. To date, over fifty International Sport Federations and sport event organizers have formally supported SportAccord’s .SPORT gTLD initiative. Out of these supporters, over twenty have actively engaged in participating in the PAB to help make this initiative beneficial to the global Sport community.
 
The emerging consensus on potential business models includes the following elements. 

First, SportAccord is keenly aware that any new gTLD must have relevant content to achieve recognition and trust. SportAccord has evaluated recent TLD launches and their experience with new paradigms, such as the dotAsia Pioneer program. Recent experience shows that it is critical for relevant content to be available as soon as possible and ideally before any general registration phases. SportAccord would ideally like to launch a series of information portals shortly after delegation. In addition to building awareness and recognition within the community, these portals will also provide appropriate IT staff to test the seamless and secure access of .SPORT domain names.
 
Second, as noted above, the .SPORT gTLD will incorporate the following minimal safeguards into any business model at the time of launch: Registrant Eligibility; Name Selection Criteria; and Authorized Usage. The current consensus involves the initial reservation of all sport disciplines (basketball, football, ski, cricket, rugby, etc.) and their corresponding acronyms (e.g. FIFA, FIG, FIBA, FIM, etc.) The exact composition of this reserve list will be compiled with the assistance and guidance of the PAB and based on new research to be conducted throughout 2012. There will also be a corresponding policy defining how reserved domain names can be assigned to the appropriate body.
 
Domain name registration of the .SPORT registry will normally be confined to the second level, though in special cases the .SPORT registry may also handle third-level registrations. Domains at the third level within individual sport specific domain names may be created by the appropriate International Federation who will set their own policies. Registrant Eligibility criteria at the second level within the .SPORT gTLD will be based on recommendations of the PAB acting in consultation with all International Sport Federations. Eligible registrants may include, but are not limited to: clubs, universities, athletes, sponsors, educational bodies, service providers, media, organizers, and fans.
 
All domain names within the .SPORT name space would be subject to suspension, cancellation or forcible change of administration in case of violation of the terms and conditions set forth in the domain name registration agreement. In addition, the registry will incorporate both active and passive safeguards into its operation to ensure that registrants abide by the terms and conditions and applicable policies. 

SportAccord believes that the approach described above can achieve the following goals:
 
- Provide a trusted and intuitive namespace for the Sport community;
- Facilitate digital communication, from, to and within the Sport community;
- Provide a platform for the development in the digital space of the Sport community;
- Promote the values of sport; and
- Provide a namespace free from illegal gambling, and doping, violence, incitement to hatred and other content incompatible with the values of Sport.

Q18b Benefit

18b HOW DO YOU EXPECT THAT YOUR PROPOSED GTLD WILL BENEFIT REGISTRANTS, INTERNET USERS, AND OTHERS?

SportAccord designs the .SPORT gTLD to offer the following benefits to community members as well as Internet users and consumers: 

* A trusted online space for members of the Sport community 
 seeking to access information, goods and services about 
 sports online;
* Provide short, predictable and memorable domain names (in 
 particular for sport governing bodies); 
* Facilitate navigation to information, services, public 
 interest content, products, etc; 
* A protected, curated name space for the benefit of 
 institutions, consumers and the overall community - 
 all registrations will be subject to the following 
 policies identified above as Registrant Eligibility, 
 Name Selection Criteria and Acceptable Use Policy;
* Post registration safeguards, both active and passive, to 
 ensure that registrants continue to act in compliance with 
 the terms and conditions of registration;
* An intrinsic link between the string and the Sport community;
* The proactive design and development of the name space from 
 its inception to ensure that the operation of the TLD is 
 accountable to the Sport community;
* Reduced contention among registrants - because the TLD is a 
 curated name space reserved for the sport community, a 
 sport community member is more likely to be able to register 
 a name that matches her⁄his⁄its needs;
* Predictability relating to the choice of the name and the 
 content the user may expect from a name corresponding to a 
 certain pattern;
* Facilitates clear and easy communications from, to and within 
 the Sport community;
* Strong intellectual property support, including strong 
 protections against ambush marketing (the illegitimate use 
 of advertising opportunities related to a sport event without 
 paying sponsorship). 


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

The primary mission and purpose of the .SPORT gTLD is to provide a trusted, hierarchical, and intuitive online marketplace to aggregate information, services, public interest content, and products for the Sport community. As technologies for delivering content and services evolve, SportAccord will continue to pursue and explore opportunities to distribute the above identified information and services to the community. SportAccord believes that a .Sport gTLD has the potential to provide a virtual platform to offer interactive features to deepen and broaden its relationship with existing and new members of the Sport community.


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

The sport TLD will create a name space specific to the Sport. Sport has considerable economic and cultural significance in all parts of the world. The .SPORT TLD will therefore fill a large gap in terms of consumer choice. From a competition standpoint, it creates a level playing field with respect to the market power of large unspecific TLDs. It is naturally differentiated both by its scope, by its governance model and by its intrinsic meaning from other TLDs. Innovation is greatly enhanced by the proactive structured development of the name space. The development process involves an open process with calls for proposals for purpose-built community-specific services based on designated portions of the .sport name space. This approach helps use innovative potential worldwide for the benefit of the Sport community and for the advancement of the global Internet.

The primary goal pursued by SportAccord is to provide a safe and secure online space for the Sport community. The success of the TLD will not be measured by the number of domain names registered. Instead it will be measured by the level of consumer recognition and trust that is placed place in .SPORT gTLD. Using this benchmark, SportAccord strives to achieve a level of recognition and trust comparable to that of the .EDU and .INT TLDs.

SportAccord is committed to serving the Sport community as it increasingly relies upon emerging technologies to deliver information and other products and services to its members. A .SPORT gTLD has the potential to serve as a cornerstone of this online strategy. Many members of the Sport community face a barrage of spam and phishing activities. The .SPORT TLD will be reserved from day one for trusted sources of information, goods and services relating to the Sport community.

SportAccord plans a comprehensive approach toward mitigating abusive and⁄or non-compliant registrations within the .SPORT name space. The .SPORT governance model reflects, among other things, the tapestry approach first proposed by ICANN’s Implementation Recommendation Team (IRT). This tapestry approach includes, but is not limited to, the following requirements: registrant eligibility; name selection criteria; content and use restrictions; escalated compliance, response and takedown procedures. (See response to Question 30.)


18.b.3 What goals does your proposed gTLD have in terms of user experience

Compared to most existing TLDs, the .SPORT user experience will greatly enhance predictability and memorability of domain names. The community-based focus, the orderly development process and strong intellectual property support ensure that users will generally find the services they are looking for under the names they intuitively tend to use for them. The user will also be ensured that the .SPORT namespace is free from resources that enable illegal gambling or advocate⁄promote doping and⁄or prohibited substances, or other content incompatible with the values of Sport.

In particular, the names and acronyms of international and national sport federations, the names of sport disciplines, key terms related to various sport disciplines, the names of sport clubs, as well as important slogans or keywords for sport will be assigned in an organized and controlled framework. This affords users a high degree of certainty that they will find, or have found, the intended sport-related resource if the domains end in .SPORT. 

Users will have greater comfort on the context of naming variants: in key portions of the .SPORT name space, alternative names and variants (redirected to the canonical forms) will systematically be activated. Wherever spelling variants exist, all variants belonging together will be reserved and delegated to the same registrant. The registry will not charge for variants based on spelling differences, such as the use or absence of hyphens or diacritical marks in IDN strings. Thanks to these policies and a general focus on building user confidence, users in the Sport community will be able to get accustomed to the predictability of .SPORT domain names. As a result, they also avoid stumbling upon common nuisances like typo-squatting, robotized traps or domain-for-sale pages in the .SPORT TLD. 


18.b.4 Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

As noted above, SportAccord has proposed a range of registrations that will be interwoven into the operation of the .SPORT gTLD. These proposed registration policies include, but are not limited to, the following requirements: Registrant Eligibility (who can register within the .SPORT gTLD); Name Selection Criteria (what domain names can be registered); Acceptable Use Policy (how the domain names can be used, e.g. no illegal gambling or doping); escalated compliance; response and takedown procedures. Each of these individual elements are elaborated in greater detail in SportAccord’s response to Questions 28, 29 and 30.

In addition, SportAccord will implement registration policies that are differentiated between the following phases: pre-launch phase, launch phase and general availability. 

During pre-launch, projects and content provision commitments are actively sought and negotiated, especially for key public-interest portions of the name space. All potential registrants and mandate holders are subject to screening and thorough pre-validation. 

During the launch phase, all registrations are thoroughly pre-validated; launch phase pre-validation depends on priority status, and eligibility requirements for each of the the fundamental categories of .sport:
 
1. Federations and Other Governing Bodies
 1.1 International, Continental, Regional, National, Local Federations
 1.2 Other International Sports-related Governing Bodies
 1.3 Public Authorities for their geographic names in relation to sports 
 events.
2. Sport Clubs affiliated to Sports Federations
 2.1 Sport Clubs taking part in international-level championships
 2.2 Other Sports Clubs
3. Corporate Partners
 3.1 Recognised Sport Events Organizers
 3.2 Sponsors
 3.3 Rights-holders, sports-related media, and other sports-related 
 Corporate Partners.
4. Athletes
 4.1 Athletes with participation in World Championships or Olympic Games
 4.2 Other eligible athletes.
5. Defensive Trademark Registrations (when not sports-related, as then they 
 would fit in 3. above)
6. Same Categories as 1-3 above, but with extended Name Selection criteria.

At general availability, community nexus is subject to post-validation by way of an extensive compliance program, though pre-validation may be applied when and where necessary. The ongoing compliance program will regularly be adapted to current needs based on experience and audit findings. Community nexus validation combined with strong protection of trademarks helps stamp out cybersquatting and abusive registrations.


18.b.5 Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures

SportAccord recognizes first hand that this is an evolving area of law in which there is no international standard. The protection of privacy and confidential information of registrants and users will comply with applicable Law, in particular the European Data Protection framework. Within the bounds of applicable regulations, the registry will implement anti-data mining measures by way of rate limitation, authenticated access or white-listing⁄black-listing, as well as tools to prevent unauthorized recourse to repetitive automated access.

SportAccord also intends to incorporate contractual language in its Registry Registrar Agreement (RRA) modeled after language which has been included in the template Registry Agreement and which has been successfully utilized by existing ICANN gTLD registry operators. 

Specifically, the following language in the RRA is will be one of the foundations of the .SPORT privacy protection measures: “Registry Operator shall notify Registrar of the purposes for which Personal Data submitted to Registry Operation by Registrar is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. Registry Operator may from time to time use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is compatible with the notice provided to registrars regarding the purpose and procedures for such use.”

 
18.b.6 Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

SportAccord will implement outreach and communication programs uniquely tailored to each phase of the launch of .SPORT. 

The pre-launch negotiations involving calls for projects by innovators and pioneer users. They foster the intuitive usability of the .SPORT TLD with a focus on the needs of the Sport community. Once these domain names are active, they become an outreach mechanism in their own right because they establish the touch-and-feel of the .SPORT TLD in the minds of the users. 

The launch phase will involve outreach mechanisms that specifically leverage participation by the local public services, locally relevant trademarks and local actors. 

Through these phases and continuing through to general availability, SportAccord will be leveraging the use of its Policy Advisory Board (PAB) engaged in outreach and communication with key leadership within the Sport community. SportAccord plays a leading role in organizing the annual SportAccord Convention and IP Forum. Both are major Sport community gatherings. SportAccord will use these events to actively promote the adoption and use of the .SPORT gTLD. These events are also the natural venues for the proposed bi-annual face-to-face meetings of the .SPORT Policy Advisory Body (PAB).

Q18c Social-Costs 
18.c.1 What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences⁄costs imposed upon consumers?

The pre-launch, launch and ongoing registration phases of the .SPORT TLD are designed to minimize social costs and negative externalities. They protect potential registrants and potentially affected parties while maximizing the value of the name space to its registrants and users. This approach is based on the premise that extensive screening efforts by the registry in the early stages will create a fair and orderly name space with lower compliance costs in the long term. In phases and areas where the first-come-first-served principle tends to yield perverse results, alternative modes are used. The introduction involves the following phases:

0) Lexical Research. 
1) A pioneer name program and name space mandate program. 
2) A long launch phase based on domain applications and contention resolution.
3) Ongoing registration.


0) Lexical Research:
This is necessary for reserved names and key name assignments. Research will analyze the usage of key strings in a sport context. This initiative will be conducted by SportAccord and overseen by the PAB.


1) Pioneer name program and name space mandate program:

These programs adjudicate domain names based on an open and transparent project selection process. This process is highly economical in terms of social costs and yields substantial external benefits. 

The pioneer name and name space mandate programs are part of the .sport outreach program. It begins before delegation of the TLD. In terms of workload, it mainly affects proposers who themselves are required to demonstrate support for their projects. Support will be required to come from the segment of the community concerned with the respective portion of the name space. Given the high value of the resulting on-line resources for the community and the public interest, and given the economic benefits that can be derived from their operation, the administrative effort is largely justified. To further protect affected parties, all adjudications in name space mandates have a safety-valve clause, allowing for later adjustments based on community input. The principle of the safety-valve is that affected parties can obtain adjustments to a component of a mandate if they propose (and commit to) an improved use of the underlying domain names from a public interest perspective. 

2) Launch phase:

The launch combines the so-called “sunrise” and “landrush” processes simultaneously in one phase. The EPP protocol with standardized extensions for TLD launch phases will be used. The use of domain registration requests instead of synchronous domain registrations means that the registry accepts multiple EPP registration requests for the same domain name. (By contrast, only a single active registration can exist for a given domain.) In this way, contention resolution can take place without time pressure in a transparent, fair and orderly manner.

During the launch phase, the time stamp of domain registration request is not relevant for priority. Adjudication is based on priority differentiation and, in case of equal priority, through a largely automated, multi-step contention resolution process. This mechanism has the lowest aggregate social costs and the aggregate highest public benefits while individually protecting each stakeholder from the risk of an excessive burden.

All applications are published on the Whois service. Requesters mark their prior rights by specifying the class they claim to qualify for in the registration request. There are five fundamental classes: sports governing bodies, sports clubs, corporate partners, athletes and defensive registrations.

Pre-defined presumptive priority rules are based on the lexical research conducted prior to launch and principles of priority. During the launch phase, the registration requests along with the presumptive priority are published on the Whois. Affected parties can submit comments regarding the presumptive priority.

For a given domain, the highest priority applications will be validated with respect to the claimed priority right. If there is more than one application for the same domain in that priority class, a contention resolution process begins. The contention resolutions process allows agreement between contenders (withdrawal and refund of application), an RFP, and, as a tie-breaker of last resort, auction. 

The options available to a contender are thus designed to promote quiet resolution by way of withdrawal, RFP or auction. Thanks to automation this minimize efforts for all parties. 

3) Ongoing registration phase: 

Registrations are checked in a post-validation process and subject to an enforcement program based on statistically targeted random investigation and complaint follow-up. This program minimizes both costs to registrants and third parties. In particular, it strongly diminishes the attractiveness of rights violations, abuse or malicious behavior. Having been preceded by a controlled launch phase, the validation and enforcement workload faces no resource bottleneck and thus achieves a high degree of credibility, further dissuading abuse from the start. This mode of operation has a strong positive side effect in the interest of trademark holders. 


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

As described above, during pre-launch and launch phase, the first-come-first-served principle is NOT applied. However, due to the limited and restrictive nature of the .SPORT namespace, SportAccord does envisage the case of multiple Sport community members vying for the same domain name. However, in the event there are multiple registrations a domain name either during Sunrise or Landrush, a two-step process will determine which registrant receives the domain. Contending registrants may be asked to submit a propose use plan as well as an evaluation fee to demonstrate to SportAccord how the TLD will be used. Emphasis will be placed on developing and deploying the domain in the general interest of the Sport community. In the event that there is no clear winner, or if the contending parties prefer skipping comparative evaluation, adjudication by auction is the tie-breaker of last resort. 


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

The focus of the .SPORT TLD is the bottom-line cost to registrants and stakeholders. This takes into account all burdens, including the effort needed to register or the potential alternative cost to obtain a name on the secondary market. The direct per-unit cost is merely a component of the bottom-line cost. 

The bottom-line cost is greatly reduced thanks to avoiding contention between legitimate community-based applicants on one side and speculators on the other. This is a way to avoid potential perverse effects of low prices, such as speculation with ultimately high costs to registrants, large-scale confusion and waste of the name space, or cybersquatting. Certain names such as initial reserved registry names will have special contractual terms in order ensure that key portions of name space are used in the public interest.


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

SportAccord is committed to providing domain name registration services in accordance with the periods set forth in the registry agreement and providing domain name registrants with pricing predictability. SportAccord further acknowledges that the current template Registry Agreement requires that the Registry Operator “shall offer registrars the option to obtain registration periods for one to ten years at the discretion of the registrar.” 

In connection with premium domain names, SportAccord will set pricing for premium⁄pioneering domain names, as well as renewal terms, in advance of these domain names being offered for registration. However, in connection with this class of domain names, there may be additional requirements that would legally bind these registrants in connection with the registration and use of these domain names. These terms will be known by this class of domain name registrants prior to the creation of any legal obligation between the parties.

Overall, the design of the .SPORT introduction is to ensure that prices will tend to fall over time rather than ever having to be increased. This means that initially, prices will be relatively high. Gradual adjustment follows depending on experience. This sliding price paradigm achieves the best resource allocation. Price increases for financial reasons would only have to be contemplated in case of inflation. However, it cannot be excluded that, by consensus within the Sport community, the price of certain categories of registrations must be adjusted for policy reasons in the general interest.

Yes

Q20a Community Served
20.a.0 Name and Description
The .sport TLD serves the Sport community, which is defined at the highest level for the purposes of this application as being primarily represented through International, Regional and National Sports Federations. The potential community of individuals and organizations that associate themselves with sports is much broader, therefore SportAccord has engaged the International Sports Federations and the International Olympic Committee to comprise a Policy Advisory Board (PAB) to assist in deciding how best to responsible expand the universe of potential registrants in the .SPORT gTLD.
Sport is defined as activity by individuals or teams of individuals, aiming at healthy exertion, improvement in performance, perfection of skill, fair competition and desirable shared experience between practitioners as well as organizers, supporters and audience.
Under the policy principles of the .sport TLD, membership in the Sport community is a necessary but not a sufficient condition for the right to hold a given domain name ending in .sport. The .sport TLD and any domain under it must be used in the interest of the entire Sport community.
Registrations under .sport are restricted to bona-fide members of the Sport community and subject to the further requirement that the registrant’s role in the Sport community, as well as the registrant’s use of the registered domain name, must be:
(i) generally accepted as legitimate; and
(ii) beneficial to the cause and the values of Sport; and
(iii) commensurate with the role and importance of the
registered domain name; and
(iv) in good faith at the time of registration and thereafter.
Furthermore, registrants in .sport must be recognized performers, organizers, promoters or supporters of federated Sport, or belong to categories of registrants recognized by the .sport Policy Advisory Board (PAB).
The Sport community’s organizational efforts for the present .sport TLD application and the subsequent operation of the TLD are built upon the community’s existing organizational structures, capabilities and principles.
As a global association of International Sports Federations, SportAccord will take the operational responsibility for .sport in line with SportAccord’s existing coordinating or facilitating functions in many sport-related areas.
In order to achieve as broad and inclusive representation of all Sport community stakeholders as possible, policy development for the .sport Internet TLD will be based upon advice provided by a Policy Advisory Board (PA B) specifically established for this purpose. The PAB will provide policy advice for .sport regarding eligibility, name selection, acceptable use, compliance enforcement on the basis of the .sport Policy Principles described under (A) above.
The key point is participation in, or organization of, sports activities. This means that membership in the Sport community is based on the respective person or entity’s will and actions. The .sport TLD is restricted to bona fide members of the Sport community. However, as described in the Policy Principles, being a member of the Sport community does not in itself convey a right to register a .sport domain name. Furthermore, beyond the question of eligibility, there are community-based conditions of content and use.
The PAB includes representatives from International Sports Federations and other sport stakeholders. It is also open to the participation of interested parties not represented by SportAccord.
20.a.1 Delineation
The Sport community relates to organizers, performers, sponsors and viewers of sport.
The wish to hold a .sport domain name is not in itself a sufficient indication of a bona fide membership of the sport community.
Furthermore, if a person has been able to register a domain name in .sport, this does not in itself entitle that person to register any other imaginable .sport domain name.
20.a.2 Organization
The Sport community is finely structured and strongly organized. It stands as a key example of the bottom-up organizational paradigm, achieving local and worldwide organizational structures in most sports disciplines. The sport community organizes itself naturally and spontaneously by discipline, between disciplines and between different forms of community participation. The organization of the Sport community is not driven by central command, but rather based on voluntary integration.
Within sport disciplines, the Sport community mostly has voluntary hierarchical structures with amateurs and professional individuals organized in clubs; clubs being grouped into leagues and national federations, national federations being grouped in regional and International Sports Federations.
Sports governing bodies are essential components of the organization of the Sports community. They include International Federations (IFs), Regional and National federations or leagues for most sports disciplines. Many clubs and schools also play a governing body role, often involving more than one sport discipline. Shared organizational resources across sports disciplines exist on the national, regional and global levels, addressing common goals and concerns. (Examples are shared sport infrastructure and events, shared communications infrastructure, shared terminology and shared values.)
On an international level, Sports governing bodies collaborate through global associations of International Sport Federations (such as SportAccord), the organizations of the Olympic Movement and well as special-purpose bodies for specific shared concerns.
Institutions such as IOC (International Olympic Committee), ASOIF (Association of Summer Olympic International Federations), AIWOF (Association of International Winter Olympic Federations) and ARISF (Association of IOC Recognised International Sports Federations) unite and support some or all of the International Federations.
SportAccord is the widest representative body, with 90 International Federations (both Olympic and non Olympic) and 15 associated members (such as International Federation of University Sports, Commonwealth Games).
20.a.3 Community Establishment
The sport has existed as a cause and as an organized community as long has humanity. The strength of the sport global community is exemplified by the fact that even though sport often related to military disciplines, it was possible for enemies to compete in sport events.
The Sport community has always been a link between cultures. Its activities and organizational structures have naturally evolved over time and continue to evolve. The constant evolution of the values of Sport towards an ever greater respect for life, human dignity and diversity demonstrates the timeless nature of the Sport community.
Overall, the quest for improvement (illustrated but not constrained by the motto “citius, altius, fortius” – “faster, higher, stronger”) has always been common to all members of the sport community.
As the organization of Sport is voluntary and natural, there are many community organizations. SportAccord is one of the key a global community institution of the Sport community.
20.a.4. Size of Community
The Sport community is present in all countries and cultures of the world. Its formal organizational structures involve:
- over 100 International Federations
- 15,000 National Federations
- 5 million sport clubs
- Tens or hundreds of million athletes, depending on the definitions.

Q20b Applicant Relationship to Community
20.b.a. Relationships to community organizations
SportAccord acts as the coordinating body of the representative organizations for the Sport community regarding the .sport Internet TLD in consultation with the stakeholders of the Sport community and their representative organizations.
SportAccord is the umbrella organization for both Olympic and non-Olympic sports as well as organizers of sporting events. One of the main objectives is to unite and support international sports federations (IFs) by encouraging and facilitating knowledge sharing and by providing expertise in relevant areas. SportAccord aims to promote its Members and to increase their visibility by establishing various multi-sports games that group together similar sports and put them on a worldwide stage.
As defined in Article 2 of its Statutes, the Objectives of SportAccord are:
1. to promote sport at all levels, as a means to contribute to the positive development of society;
2. to assist its Members in strengthening their position as world leaders in their respective sports;
3. to develop specific services for its Members, and provide them with assistance, training and support;
4. to increase the level of recognition of SportAccord and its Members by the Olympic Movement stakeholders as well as by other entities involved in sport;
5. to actively support the organisation of multi-disciplinary games by its Members;
6. to be a modern, flexible, transparent and accountable organisation;
7. to organise, at least once a year, a gathering of all of its Members, and of other stakeholders of the sport movement, preferably on the occasion of its General Assembly;
8. to recognise unconditionally the autonomy of its Members and their authority within their respective sports;
9. to promote closer links among its Members, and between its Members and any other sport organisation;
10. to coordinate and protect the common interests of its Members;
11. to collaborate with organisations having as their objective the promotion of sport on a world-wide basis;
12. to collect, collate and circulate information to and among its Members.
20.b.3 Relations to the community and its constituents parts⁄groups
The list of the Members of SportAccord is provided in response to Question 11.
The list of Sports International Sport Federations and other international Sport organizations have formally expressed their official support for to date for SportAccord’s Application for the .sport TLD is shown under Question 20d.
20.b.3. Accountability Mechanisms
As an association under Swiss Law, SportAccord is entirely accountable to its members, the International Sport Federations – each of which has accountability mechanism of its own to national federations, which in turn are accountable to their constituents.
Each member of SportAccord has one vote, as required for Associations under Swiss Law. (SportAccord is an Association under Articles 60-79 of the Swiss Civil Code.) The legal framework ensures furthermore that membership cannot be sold and that the Association cannot be acquired or controlled by anyone, member or otherwise. All key decisions are reserved to the General Assembly, defined as the meeting attended by all the Members of SportAccord. The General Assembly is the supreme and legislative organ of SportAccord. The Statutes of SportAccord stipulate the as follows the Powers of the General Assembly:
The General Assembly adopts or amends the Statutes, regulations and directives of SportAccord.
The General Assembly admits, suspends or expels a Member.
The General Assembly elects the President.
The General Assembly approves the budgets, financial statements and the activity report.
The General Assembly sets the amount of the subscription for Members;
The General Assembly exercises any other competence specifically attributed to it by the
Statutes, regulations and directives of SportAccord.
Additional accountability and consultation mechanism are organized horizontally between International Federations, related associations of international federations, associate members of SportAccord and others Sport Stakeholders. Permanent coordination processes exist through the Yearly SportAccord Convention, IF Forum, working group involving IOC, the Association of Summer Olympic International Federations (ASOIF), the Association of International Olympic Winter Sports Federations (AIOWF), the Association of the IOC Recognised International Sports Federations (ARISF) as well as specialized sport-related organizations.

20c Community-based purpose
20.c.1 Relationship between registrant categories and community members
The .sport TLD is to serve the collective interest of the all the members of the Sport Community. For the largest portion of members of the Sport community in numeric terms – sports practitioners, spectators and fans worldwide – the greatest value of .sport lies in the reliability and trustworthiness of the .sport name space. They want to see .sport domain names in the right hands rather than to own .sport domain names themselves.
The inverse analysis comes to the same conclusion: given the intrinsic scarcity of domain names (each name can only exist once), the objective of the .sport TLD cannot be to provide a domain name each to billions of Sport community members. An approach where all Sport community members could register any .sport name would destroy the value of all .sport names. Fair allocation of names would be impossible, community members would be pushed into sterile contention. In such an environment, all stakeholders would experience .sport as a nuisance rather than a useful resource.
For this reason, the .sport TLD is designed as an orderly, curated name space. Registrant categories are differentiated and confined to the two groups playing a primary role in the creation of Sport-related content of interest to the members of the Sport community:
- Sports Performers and Organizers, who produce the sport
content as publicly visible performers or organize and
structure it. (This group includes Athletes, Clubs,
Events, Governing Bodies.)
- Corporate Partners, who support the production of sport
content by providing resources in exchange for sport-
related visibility. (This group includes sponsors and media.)
These two groups of the Sport community create or help create content for the sport community and have a need for .sport domain names for that activity. They share an interest in making sure that the .sport name space is curated and controlled. The difference between the two groups lies in the relationship of their respective names, brands and slogans to Sport.
- Sports Performers and Organizers use names belonging to a
Sport context, by virtue of rights specific to Sport,
- Corporate Partners use names in a general trademark context
and relate their names to sport in exchange of sponsorship
or other contributions to performers and organizers.
Both the registration policies and the financial model of the .sport TLD takes this reality into account. It provides a basis for priority and contention resolution as well as for funding the effort of providing a curated name space. For instance, names in .sport need to take into account sport-specific naming rights which will take precedence over generic trademark rights in many cases. On the other hand, the Corporate Partners expect the sport organizers (which includes the organization of the .sport TLD itself) to reflect their role as Sport sponsors in the treatment the non-sport trademarks within the .sport TLD. As they derive value from the visibility created by Sport, they are ready to fund the bulk of the effort to curate the name space.
The Corporate Partners thus pay higher registration fees per domain in exchange for two value propositions: (1) the legitimate sport-related visibility and (2) the curated name space free from the need for defensive registrations. The substantially higher registration fee for corporate partners in itself further enhances their protection against trademark infringement. From a moral standpoint, it is also a form of contribution to sport in the sense of sponsorship, for the benefit of the entire Sport community. The Corporate Partners thus pay for the bulk of the effort to curate the name space and in doing so create value for themselves and the rest of the Sport community.
20.c.2. Description of Registrant Categories
Note: the Sport community is extremely diverse. This also applies to registrant categories, even though potential registrants are only a fraction of the Sport community. The following is a simplified description of the primary registrant categories. For the purpose of analysis in other parts of the present gTLD application, further simplifications are made. The future .sport registration policy will have detailed category descriptions. It will be adapted regularly to take into account experience and the evolution of the Sport community, under the guidance of the .sport Policy Advisory Board (PAB).
Athletes – Comprised primarily of elite and other top-level athletes competing at the highest levels of national and international sport.
Sports Clubs – Comprised of the sports clubs affiliated with officially-recognized Federations (lists of names, terms and acronyms specific to the .sport TLD needs will be compiled in the lexical research phase prior to launch).
Governing Bodies – includes governing bodies, international, continental, national, regional federations, associations, event organizing committees, major leagues, major (national) teams. By a simplifying extension, this category includes cities and venues for sports events.
Corporate Partners (Media and Brands) – includes media partners (including rights holders), corporate sponsors, sporting goods manufacturers etc.
20.c.3. Evolution over time of registrant access to .sport
Both the principle of prudence and the objective of optimal name allocation dictate that the policy should gradually evolve from strongest validation to gradually easier access, and from high prices to gradually lower prices. (The price differentiation between categories facilitates access where necessary.)
Registrants in the .sport TLD will include athletes, event organizers, sponsors, clubs and other organizations and individuals that share the values of Sport and actively and constructively participate in, organize or support sport activities.
Any person or organization can be a member of the Sport community by faithfully adhering to its values, be it as a practitioner, organizer, supporter or as a member of the audience.
The values of Sport include respect for life, health and human dignity, organization in the common interest, adherence to rules, honesty, courage, loyalty, equal opportunity, objective metrics and not counting luck as proof of achievement.

Q20d String Relationship to Community
20.d.1. Relationship to the established name of the community
The TLD string “.sport” matches the name of the community, Sport, in the generally accepted sense of the word, in French, English and many other internationally used languages.
As stated above, Sport is usually defined as a physical or athletic activity, with often an element of competition. Sport can be primarily physical, primarily mind, primarily motorized, primarily coordination, primarily animal-supported The sport proposed should in no way be harmful to any living creatures. The sport should not rely on any “luck” element specifically designed into the sport. The activities of the Sport community related to Learning⁄teaching,
Performing, Organizing, Viewing, Developing, Improving (fortius, altius, citius). All these aspects are part of the generally accepted connotations of the word “sport” and also match the spirit and the letter of the community definition.
20.d.2. Relationship to the identification of community members
The identification of community members is based on the Community delineation described in the response to Question 20(a)
Note: Community membership is a necessary condition for the right to hold a .sport domain name, but is not in itself a sufficient qualification, as is also described in the response to Question 20(a).
The activities inside the Sport the sport community demonstrate the same constancy throughout millennia, relating to
- learning, practice and teaching of sport,
- organizing sport activities and events,
- viewing or otherwise witnessing sport,
- developing equipment, tools, criteria and procedures in support of sport.
20.d.3. Other connotations of the word sport
The word sport has no frequently-used connotations that are unrelated of the Sport community.
20.d.4. Express support from Sport community organizations
The following Organizations have formally expressed their official support for to date for SportAccord’s Application for the .sport TLD:
IOC INTERNATIONAL OLYMPIC COMMITTEE
ASOIF ASSOCIATION OF SUMMER OLYMPIC INTERNATIONAL FEDERATIONS
AIOWF ASSOCIATION OF WINTER OLYMPIC INTERNATIONAL FEDERATIONS
ARISF ASSOCIATION OF IOC RECOGNISED INTERNATIONAL FEDERATIONS
BWF BADMINTON WORLD FEDERATION
CGF COMMONWEALTH GAMES FEDERATION
CIPS CONFEDERATION INTERNATIONALE DE LA PECHE SPORTIVE
CMAS CONFEDERATION MONDIALE DES ACTIVITES SUBAQUATIQUES
CSIT CONFEDERATION SPORTIVE INTERNATIONALE DU TRAVAIL
FAI FEDERATION AERONAUTIQUE INTERNATIONALE
FEI FEDERATION EQUESTRE INTERNATIONALE
FIAS FEDERATION INTERNATIONALE AMATEUR DE SAMBO
FIBA FEDERATION INTERNATIONALE DE BASKETBALL
FIDE FEDERATION INTERNATIONALE DES ECHECS
FIE FEDERATION INTERNATIONALE D’ESCRIME
FIFA FEDERATION INTERNATIONALE DE FOOTBALL ASSOCIATION
FIG FEDERATION INTERNATIONALE DE GYMNASTIQUE
FIH FEDERATION INTERNATIONALE DE HOCKEY
FIM FEDERATION INTERNATIONALE DE MOTOCYCLISME
FIQ FEDERATION INTERNATIONALE DES QUILLEURS
FIS FEDERATION INTERNATIONALE DE SKI
FISA FEDERATION INTERNATIONALE DES SOCIETES DʹAVIRON
FISU FEDERATION INTERNATIONALE DU SPORT UNIVERSITAIRE
FIVB FEDERATION INTERNATIONALE DE VOLLEYBALL
FMJD FEDERATION MONDIALE DU JEU DE DAMES
IAAF INTERNATIONAL ASSOCIATION OF ATHLETICS FEDERATIONS
IAF INTERNATIONAL AIKIDO FEDERATION
IAKS INTERNATIONAL ASSOCIATION FOR SPORTS AND LEISURE FACILITIES
ICF INTERNATIONAL CANOE FEDERATION
IDBF INTERNATIONAL DRAGON BOAT FEDERATION
IFA INTERNATIONAL FISTBALL ASSOCIATION
IFBB INTERNATIONAL FEDERATION OF BODYBUILDING & FITNESS
IFF INTERNATIONAL FLOORBALL FEDERATION
IFMA INTERNATIONAL FEDERATION OF MUAYTHAI AMATEUR
IFSS INTERNATIONAL FEDERATION OF SLEDDOG SPORTS
IGF INTERNATIONAL GOLF FEDERATION
IJF INTERNATIONAL JUDO FEDERATION
IKF INTERNATIONAL KORFBALL FEDERATION
ILS INTERNATIONAL LIFE SAVING FEDERATION
IOF INTERNATIONAL ORIENTEERING FEDERATION
IPC INTERNATIONAL PARALYMPIC COMMITTEE
IPF INTERNATIONAL POWERLIFTING FEDERATION
IRB INTERNATIONAL RUGBY LEAGUE
IRF INTERNATIONAL RACQUETBALL FEDERATION
ISA INTERNATIONAL SURFING ASSOCIATION
ISAF INTERNATIONAL SAILING FEDERATION
ISSF INTERNATIONAL SHOOTING SPORT FEDERATION
ITTF THE INTERNATIONAL TABLE TENNIS FEDERATION
IWGA INTERNATIONAL WORLD GAMES ASSOCIATION
IWUF INTERNATIONAL WUSHU FEDERATION
JJIF JU-JITSU INTERNATIONAL FEDERATION
TWIF TUG OF WAR INTERNATIONAL FEDERATION
UCI UNION CYCLISTE INTERNATIONALE
WA WORLD ARCHERY FEDERATION
WAKO WORLD ASSOCIATION OF KICKBOXING ORGANIZATIONS
WDF WORLD DART FEDERATION
WKF WORLD KARATE FEDERATION
WMF WORLD MINIGOLFSPORT FEDERATION
WSF WORLD SQUASH FEDERATION
WTF WORLD TAEKWONDO FEDERATION

Q20e Intended Policies and Enforcement
20.e.0. General registration policy principles
As described in the response to Questions 20(a), two types of conditions must be fulfilled for the right to register a .SPORT name. These are:
(A) community membership and
(B) the additional requirements that the registrant’s role in the Sport community, as well as the registrant’s use of the registered domain name, must be:
(i) generally accepted as legitimate; and
(ii) beneficial to the cause and the values of Sport; and
(iii) commensurate with the role and importance of the
registered domain name; and
(iv) in good faith at the time of registration and thereafter.
Furthermore, registrants in .sport must be recognized performers, organizers, promoters or supporters of federated Sport, or belong to categories of registrants recognized by the .sport Policy Advisory Board (PAB).
These conditions must always be fulfilled. The strength of the validation is kept in line with the importance of the underlying domain name based on the assumption that a typical user would reasonably make.
20.e.1. Eligibility, Valididation
To facilitate validation, registrants are required to state their intended use of the registered domain name. A false statement of intended use is an indication of bad faith and can be the basis for the suspension of the domain name.
Registrants are further required to have an administrative contact in the Performers or organizers of sport. This is verified in part automatically (through the postal code in the administrative contact record and by a human eyes review pre-validation or post-validation).
The administrative contact may be any person or entity having received and accepted the mandate to act as such for the respective domain. (The registrar may act as administrative contact.) Any communications addressed to the administrative contact are deemed to have been brought to the attention of the domain holder. Validation checks include machine and human verification of address accuracy.
The validation may be assisted through pre-identification of potential registrants using existing community channels, in particular through promotion codes.
After the launch phase, the validation mode goes from pre-validation to post-validation and later to statistically targeted random validation, backed up by a ongoing enforcement program.
The validation and enforcement program are supported by an integrated issue tracking system. This system allows validating agents and personnel to cooperate and interact with the registrant. The system keeps track of decisions made by the agents and stores supplemental documentary evidence that may be supplied by the registrants.
20.c.2. Name Selection
The fundamental rule on which name selection is based is part of the policy principles: the registrant’s presence in Performers or organizers of sport and use of domain must be commensurate to role and importance of the domain registered.
20.c.3. Content and use
The role and importance of the domain name is based on the meaning an average user would reasonably make in the context of that domain name.
This criterion also applies to the strength of the documentation or proof required of the registrant.
Pre-defined uses of the name space, especially names with significance for Performers or organizers of sport from a public service or public interest standpoint, is developed through special programs with strong selection processes, based on proposals made by parties interested in providing content on such domain names. This process not only covers the identity and legitimacy of the party entrusted with the operation of the domain(s), but also a defined obligations with respect to the content to provide for the benefit of the public.
20.c.4. Enforcement
The purpose of the enforcement program is to protect the credibility of the .SPORT TLD for use by the international public. In particular, it upholds the community-based purpose of the .SPORT TLD and helps prevent misuse or malicious behavior.
The enforcement program is based on statistically targeted random investigations and on a complaint follow-up process. The statistical targeting is strongly automated and involves the use of search engines and the analysis of registry data related to behavior of registrants.
Depending on the type of misuse to be investigated, web site content or content sent to victims of abuse will reviewed and analyzed by investigators.
Enhanced investigation takes place if the registrant has a bad track record in terms of compliance with the rules of the .SPORT TLD. Other violations of public record (such as UDRP or URS cases) will also be taken into account.
If the intended use cannot be deemed legitimate or has a negative impact on the sport community, the registration is rejected. If content or use of an existing .sport domain demonstrates that the registrant has shown bad faith by stating a false intended use, the domain name is suspended.
If a registrar is complicit with systematic violations of the .sport policies or causes an unacceptable burden for the validation and enforcement program by negligence, the registry can restrict that registrar’s access to the new registrations, subject its inventory of .sport domains to enhanced investigation and require it conduct its own post-validation program.
An appeals process is available for all administrative measures taken in the framework of the enforcement program. The first instance of the appeals process is managed by the registry service provider.
The Policy Advisory Board (PAB) set up by SportAccord provides the second and last instance of an appeals process by itself or entrusts it to an alternative dispute resolution provider. The charter of the appeals process is promulgated by the PAB.

Not Available

No

Reserved List of Geographic Names

In accordance with Specification 5 of the proposed TLD Registry Agreement published as Attachment to Module 5 of the Applicant Guidebook by ICANN, and with Governmental Advisory Committee (GAC) advice on geographic names at the second level, the .sport Registry will put the following names on the reserved list, therefore making them unavailable for registration or any other use:


• the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union;
• the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

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

Technically, this is achieved by utilising the advanced domain name rule engine that is part of the CORE Registration System and described in detail in the answer to Question 28. As laid out there, the underlying set of checks can be tuned to block registrations of .sport names based on various syntactic rules, multiple reserved names lists, and patterns. Prior to the launch of the .sport TLD, the rule engine will be configured in accordance with the reserved list mandated by Specification 5, which means that the listed names are not available for registration by registrars.

2. Exceptions

However, the .sport Registry recognizes that there may be cases where a request to register and use a geographic name at the second level should be considered legitimate, valid and useful.

For registration requests from the relevant public authority, the .sport Registry will put in place the procedure agreed between the GAC and Afilias for the .info gTLD, as referenced in the letter written by Mohamed Sharil Tarmizi, GAC Chair, on Sept 9, 2003; see

https:⁄⁄gacweb.icann.org⁄download⁄attachments⁄1540128⁄dotinfocircular1.pdf.

Technically, the registrar needs to use the authorisation code supplied by the registrant as the domain authinfo in the EPP ʹʹdomain:createʹʹ request, which will let the request bypass the rule engineʹs blocking mechanism and permit the registration.

3. Additional monitoring

The .sport Registry does not plan to monitor use of geographic names below the second level (i.e. subdomains used by a .sport TLD domain name registrant), as those procedures are both difficult and ineffective. Available dispute resolution mechanisms are a more adequate resolution procedure in cases where third or higher level domains unduly use country or other territory names.

Q23 - Registry Services


1. Overview

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

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

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

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

CORE Internet Council of Registrars has been entrusted with the technical operation of the .cat and .museum TLDs on behalf of the puntCAT and MuseDoma registries. Therefore, CORE has the knowledge and experience that are necessary to provide the mentioned registry services. Since the software development is handled exclusively in-house, the .sport Registry Services do not depend on any external companies or developers. Software development at CORE is always based on principles like efficiency, scalability and security by design.


2. Infrastructure Design


2.1 Goals

The design of the .sport Registry infrastructure achieves three goals:


2.1.1 High Availability

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

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


2.1.2 Scalability

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


2.1.3 Security

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


2.2 Design Principles

The design principles that follow these goals are as follows:

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


3. Features


3.1 Receipt of Data from Registrars

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

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

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


3.2 Internationalised Domain Names

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

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

Internationalised domain names are not only supported as first-class objects, but also as so-called variants of a base domain. In this case, a domain has more than one representation. The alternatives are organised as attributes of the base domain, meaning they cannot exist by themselves. This has the advantage that they are much less subject to domain squatting, since the variants always belong to the same registrant as the base domain. In the DNS the variants are represented by DNAME records (as it is done in the .cat and .gr TLDs) or published with the same name servers as the base domain. A precondition for the use of variants is that the specified language(s) allow the derivation of a canonical name from any valid domain name. This is, for example, achieved by the principles defined in RFC 3743 for the Chinese⁄Japanese⁄Korean languages.

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


3.3 DNSSEC

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


3.4 IPv6 Support

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


4. Zone Management

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

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

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

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


5. Whois service

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


6. Escrow and Reports

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

In its role as the registry backend operator for .museum and .cat, CORE Internet Council of Registrars has continuously provided reliable registry data escrow services for these registries, in full compliance with the escrow specifications of the respective ICANN registry agreements.

In the same fashion, CORE also produces registrar escrow files for its registrar activities, in full compliance with ICANNʹs Registrar Data Escrow (RDE) requirements.

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

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

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


7. Support for Sunrise and Landrush Phases

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

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

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

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

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

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

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

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

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

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

The CORE Registration System offers built-in support for Sunrise and Landrush phases. In the case of the .sport Registry, both a Sunrise phase and a Landrush phase will be supported.


8. Domain Expiration and (Auto-)Renewal Policies

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

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

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


9. Billing

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

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

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

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

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

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

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

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


10. OT+E and Staging Environment

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

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

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

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

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

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

Q24 - Shared Registration System (SRS) Performance

CORE Internet Council of Registrars provides a unified registration system for its members since 1997. This system grants access to a multitude of top-level domain registries, currently including .com, .net, .org, .info, .biz, .name, .us, .asia, .eu, .coop and .tel domains, via a single entry point. The activities concerning the CORE Registration System provide CORE with a great deal of expertise and know-how regarding the implementation, operation, maintenance and support of a shared registration system, facing a very heterogeneous user group regarding location, language, enterprise size and structure.

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


1. High-Level System Description

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

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


1.1 Multiple sites

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

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

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

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

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

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

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

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

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


1.2 Software Development

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


1.2.1 Change Control

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

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


1.2.2 Quality Assurance

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

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

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


1.3 Synchronisation Scheme

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

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


2. System Reliability, Stability and Performance


2.1 Outage Prevention


2.1.1 Data Centre Precautions

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


2.1.2 Availability by Design

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

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

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

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

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

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

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

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


2.1.3 Hardware supplies and Software Availability

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


2.2 Performance Specifications

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


2.2.1 SRS Performance

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


2.2.2 Registration Data Directory Services (RDDS) Performance

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


2.2.3 DNS Performance

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


2.3 Operational Scalability

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

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

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

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

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

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

Thanks to these measures, the .sport Registry avoids disproportionate demand for registry resources.


3. Employed Hardware

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

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


4. Resourcing Plans


4.1 Implementation

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

System Administrator: 25 man hours;

Network Operation Centre Officer: 25 man hours;

DNSSEC Signing Operator: 5 man hours.


4.2 Ongoing Maintenance

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

System Administrator: 5 man hours per month;

Network Operation Centre Officer: 5 man hours per month;

Software Developer: 2 man hours per month;

Quality Assurance Agent: 1 man hour per month;

DNSSEC Signing Operator: 1 man hour per month.

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

Q25 - Extensible Provisioning Protocol (EPP)


1. Experience

The EPP interface for registrars of the .sport Registry is based on COREʹs EPP implementation, which has been used for several registries.

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

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

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

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

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

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


2. Standards Compliance

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

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

The proposed standard for an EPP extension for ʺgrace periodʺ policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN) is fully supported also (RFC 3915). Such grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed.

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

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

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


3. Stability

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

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


4. Equal opportunity

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

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


5. Proprietary Extensions

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


5.1 Extension for Trademark Information during Launch Phases

The CORE Registration System used to operate the .sport Registry provides a proprietary EPP extension for submitting special data needed during launch phases.


5.1.1 Introduction

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

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

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

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

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


5.1.2 Object Attributes

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

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


5.1.2.1 Phase

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


5.1.2.2 Application Status

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

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


5.1.2.3 Claim Data

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

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

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


5.1.2.4 Additional Application Information

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


5.1.3 EPP Command Mapping

This section deals with the specific command mappings for the .sport Registry EPP extension for launch phases.


5.1.3.1 EPP Query Commands

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


5.1.3.1.1 EPP ʺcheckʺ Command

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


5.1.3.1.2 EPP ʺinfoʺ Command

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

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

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

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

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

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


5.1.3.1.3 EPP ʺpollʺ Command

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


5.1.3.1.4 EPP ʺtransferʺ Command

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


5.1.3.2 EPP Transform Commands

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


5.1.3.2.1 EPP ʺcreateʺ Command

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

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

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

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


5.1.3.2.2 EPP ʺdeleteʺ Command

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

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

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

The CORE Registration System supports the withdrawal of an application using this extension to the ʺdeleteʺ command. Note, however, that support for the withdrawal of an application depends on the .sport Registry Sunrise policy, which is described elsewhere.


5.1.3.2.3 EPP ʺrenewʺ Command

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


5.1.3.2.4 EPP ʺtransferʺ Command

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


5.1.3.2.5 EPP ʺupdateʺ Command

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

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

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

The CORE Registration System supports the modification of an application using this extension to the ʺupdateʺ command. Note, however, that support for the modification of an application depends on the .sport Registry Sunrise policy, which is described elsewhere.


5.1.4 Formal Syntax

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


5.2 Extension for Auction Information

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


5.2.1 Introduction

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

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

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


5.2.2 Object Attributes

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

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


5.2.2.1 Bid

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

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


5.2.3 EPP Command Mapping

This section deals with the specific command mappings for the .sport Registry EPP extension for auctions.


5.2.3.1 EPP Query Commands

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


5.2.3.1.1 EPP ʺcheckʺ Command

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


5.2.3.1.2 EPP ʺinfoʺ Command

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

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

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


5.2.3.1.3 EPP ʺpollʺ Command

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


5.2.3.1.4 EPP ʺtransferʺ Command

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


5.2.3.2 EPP Transform Commands

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


5.2.3.2.1 EPP ʺcreateʺ Command

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

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

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


5.2.3.2.2 EPP ʺdeleteʺ Command

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


5.2.3.2.3 EPP ʺrenewʺ Command

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


5.2.3.2.4 EPP ʺtransferʺ Command

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


5.2.3.2.5 EPP ʺupdateʺ Command

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

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

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

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


5.2.4 Formal Syntax

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


5.3 Extension for Language Information

The CORE Registration System used to operate the .sport Registry provides a proprietary EPP extension for internationalised domain names (IDNs).


5.3.1 Introduction

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

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


5.3.2 Object Attributes

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


5.3.2.1 Languages and Scripts

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

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


5.3.2.2 Variants

This extension allows to specify a number of variants of the domain name to be registered together with the supplied domain name. The variants are expected to be submitted in normalised form (see also Q44, Support for Registering IDN domains). The number of variants that can be specified is limited to at most 10.


5.3.3 EPP Command Mapping

This section deals with the specific command mappings for the .sport Registry EPP extension for IDNs.


5.3.3.1 EPP Query Commands

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


5.3.3.1.1 EPP ʺcheckʺ Command

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

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

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

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


5.3.3.1.2 EPP ʺinfoʺ Command

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

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

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

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


5.3.3.1.3 EPP ʺpollʺ Command

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


5.3.3.1.4 EPP ʺtransferʺ Command

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


5.3.3.2 EPP Transform Commands

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


5.3.3.2.1 EPP ʺcreateʺ Command

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

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

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

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

Note that the .sport Registry restricts the number of domain name variants given in the ʺidn:variantsʺ element to at most 10. Submitting an empty ʺidn:variantsʺ element is allowed; this will not register any domain name variants.

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


5.3.3.2.2 EPP ʺdeleteʺ Command

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


5.3.3.2.3 EPP ʺrenewʺ Command

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


5.3.3.2.4 EPP ʺtransferʺ Command

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


5.3.3.2.5 EPP ʺupdateʺ Command

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

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

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

Note that the .sport Registry restricts the number of domain name variants given in the ʺidn:addʺ and ʺidn:remʺ elements to at most 10.

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


5.3.4 Formal Syntax

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


6. Resourcing plans


6.1 Initial Work

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


6.2 Ongoing Work

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

First Level Support: 4 man hours per month.

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

Q26 - Whois


1. Overview

The CORE Registration System used by CORE Internet Council of Registrars to operate the .sport TLD will offer Registration Data Directory Services (RDDS) in compliance with Specification 4 of the Registry Agreement, consisting of a Whois Service, Zone File Access and Bulk Registration Data Access.


2. Whois Service


2.1 Interfaces


2.1.1 Port 43 Whois Service

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

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


2.1.1.1 Input Format

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

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

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

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

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

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


2.1.1.2 Output Format

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

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

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

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

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


2.1.2 Web-based Whois Service

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

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


2.2 Searchable Whois

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

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

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

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

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

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

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


2.3 Whois Data Distribution

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

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

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

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

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


2.4 Network Structure

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

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

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

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


2.5 Inner Workings of a Whois Server Instance

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

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

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

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


2.6 Whois Data Privacy Measures

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


2.6.1 Consideration of EPP Data Disclosure Preferences

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

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


2.6.2 Web Whois

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

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


2.7 Support for Emerging Technologies

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

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


2.8 Whois Resiliency and Performance

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

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

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

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


2.9 Compliance with Specification 10 of the Registry Agreement

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

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


3. Zone File Access

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

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


4. Bulk Registration Data Access

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


5. Experience in providing ICANN-compliant Whois services

CORE has been operating Shared Registry Systems (SRS) since 1997, which all require a connected port 43 Whois server. In its role as the registry backend operator for .cat and .museum, CORE has continuously provided (and still provides) reliable Whois services for these registries, being in full compliance with RFC 3912 and ICANN registry agreements.

The experience gathered from these previous Whois related activities enables CORE to develop and operate a Whois subsystem for the .sport Registry that is fully compliant with all ICANN requirements.


6. Resourcing Plans

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

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


6.1 Initial implementation

For the initial setup, the following resources are allotted:

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


6.2 Ongoing maintenance

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

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

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

Q27 - Registration Life Cycle

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

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


1. Domain Creation

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

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

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


2. Domain Update

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


3. Domain Renewal (Automatic or Explicit)

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

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

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

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

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


4. Domain Deletion

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

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

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


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

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

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

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

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

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

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


6. Domain Transfer

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

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

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

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

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


7. EPP and Grace Period Status Values

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

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


7.1 EPP Domain Status Values (from RFC 5731)

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


7.2 EPP Grace Period Status Values (from RFC 3915)

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


8. Consistence with Commitments to Registrants

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


9. Resourcing Plans

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

For the initial setup, the following resources are allotted:

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

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 4 man hours per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

Q28 : Abuse Prevention and Mitigation

The .sport Registry, with the assistance of its backend registry provider CORE Internet Council of Registrars, will establish, thorough and effective methods to prevent abuse of .sport domain names, .sport registrant data or the associated infrastructure, as well as to mitigate any impact from such abuse (should it occur despite the preventive measures). In order to achieve this, the .sport Registry is committed to deploying extensive organizational and technical measures. The most salient examples of these measures are described below.

~1. Rapid Takedown Policy for Cases of General Malicious Activity

The .sport Registry has committed to closely collaborate with law enforcement authorities and security agencies in order to take quick action in case a .sport name is reported to be involved in malicious activity. For this purpose, a Rapid Takedown Policy is established that:

* identifies cases of malicious activity,
* defines ways for the registry to be notified of such activity (e.g. via a dedicated website, e-mail address or phone hotline),
* defines clear and consistent procedures to quickly stop the malicious activity (after the activity was confirmed and impact of the measures has been assessed),
* defines related service levels (e.g. with respect to the maximum time the registry may take to respond to takedown requests). This time limit will never exceed 15 business days in the case of less urgent cases, and not exceed 24 hours in the most urgent cases such as phishing,
* defines rules regarding the notification of involved parties (registrant, administrative contact, technical contact, registrar, informant),
* defines ways to appeal against any measures taken (through the general Eligibility Restrictions Dispute Resolution Procedure as is the case for all appeals against Registry decisions, but with panelists that are specialized in Security and Malicious Conducts).
* defines how cases covered by the policy need to be documented and reported. In this context, cases of malicious activity may include (but are not limited to):
** wrong, invalid or harmful DNS setup (e.g. pointers to false IP addresses),
** use of trademarked or otherwise reserved names without proper rights,
** use of the domain in actions that affect the stability and security of the Internet (e.g. in Denial of Service (DoS), Distributed Denial of Service (DDoS) attacks or botnets),
** use of the domain for the distribution of malware (such as computer viruses, worms, Trojan horses, spyware or rootkits),
** use of the domain for phishing or scamming,
** use of the domain for spamming (affecting e-mail or other forms of electronic messaging).
** maintaining invalid registrant contact data in the domain.

Where applicable, the policy includes metrics and thresholds for finding quantitative indications of malicious conduct.

Procedures to stop malicious activity may include (but are not limited to):

* notifying the domainʹs sponsoring registrar, specifying a deadline until which the activity needs to haveceased,
* notifying the domainʹs registrant, administrative or technical contact directly (again specifying a deadline until which the activity needs to have ceased),
* locking the domain and putting it on hold in order to prevent changes to the domain and remove it from the .sport zone (ʺtakedownʺ),
* deleting the domain name and blocking it from further registration if need be. Escalation rules (defining which steps are to be taken in which order and conditions for moving on to the next, more drastic measure) are part of the policy.

Since removing a domain name from the .sport zone usually has serious consequences (such as rendering websites and e-mail addresses utilizing the domain name unusable), the .sport Registry will, in accordance with the policy, exercise extreme caution with regard to any takedown decision.

At the same time, the .sport Registry is aware that malicious activity potentially affects a large number of Internet users, which sometimes warrants drastic measures. The Rapid Takedown Policy aims at finding appropriate measures, taking the interests of all involved parties into consideration. The Rapid Takedown Policy will be announced to both .sport registrars and .sport registrants and be part of the Registry-Registrar Agreement (RRA) and the .sport registration terms.

2. Rapid Takedown Policy for Cases of Phishing

The .sport Registry will work closely with all relevant CERTs and CSIRTs to develop an Anti-Phishing-specific simplified procedure. The goals will be to:

* get all five Swiss CERTs and CSIRTs (at least, but open to other CERTs) accredited as Authorized Intervenors),

* develop criteria and checklist for domain names eligible for Rapid Suspension,

* develop secured communications method between Authorized Intervenor and Registry, including an Affidavit form.

Names reported by Authorized Intervenors will be suspended in less than 4 hours. This system should expand to a global Authorized Intervenors list. In this regard, the .sport Registry will work with the Antiphishing Working Group and other initiatives in order to develop and complete their proposed Accelerated Takedown proposal, which is still in beta stage.

3. Single Point of Contact for Abuse

To ensure that the .sport Registry gets notified of any cases of abuse as quickly and as easily as possible, an area of the public website operated by the .sport Registry for the .sport TLD will be dedicated to the reporting of such cases.

The respective web pages establish a single point of contact where abuse cases can be reported via a simple web form. An e-mail address and a phone number will also be provided as alternative means of communication.

Every case reported will raise a high-priority ticket within the .sport support staffʹs ticket system, to be examined immediately and treated in accordance with the Rapid Takedown Policy (and the other Compliance Procedures related to Eligibility and Use, and Trademark Claims).

4. Prevention of Domain Name Tasting or Domain Name Front Running

The life cycle of a .sport domain name includes a 5-day Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee. This is common practice and corresponds to the policies of almost all existing generic top level domains.

However, in the past the Add Grace Period has been abused for practices such as domain name tasting and domain name front running.

Domain name tasting means that domains were created simply for the purpose of testing whether revenue can be generated by e.g. creating a web page with advertisements for the domain; if this was found feasible within the first few days, the domain was retained, otherwise it was deleted within the add grace period for a full refund, i.e. the domain was ʺtastedʺ for potential revenue without any payment to the registry.

Domain name front running refers to the practice of pre-registering domain names somebody has merely expressed interest in (e.g. by searching for them on the Whois web front-end of a registrar) with the purpose of reselling the domain to that person (at an inflated price) afterwards; again, the Add Grace Period has been abused for this purpose since a registrar could do that without any cost (if the unsold domain was deleted before the end of the add grace period).

In 2008, ICANN introduced the so-called ʺAGP Limits Policyʺ (http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these and other issues resulting from the Add Grace Period. The .sport Registry will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy. At the end of every month, the registration systemʹs billing module will determine every registrarʹs net domain adds and check whether the add grace period refunds granted during that month exceed the permissible number according to the policy; if this is the case, additional charges to the registrarʹs account will be initiated to effectively revert the excessive refunds.

Any exemption requests by registrars, whether they were granted (as permitted by the policy) or rejected, are documented, and such documentation will be maintained and made available for review by ICANN on request. The registryʹs monthly report to ICANN will contain per-registrar information on the granted add-deletes, as well as additional columns regarding the exemption requests.

The related report columns are (with column header names in parentheses):

* number of AGP deletes (ʺdomains-deleted-graceʺ)

* number of exemption requests (ʺagp-exemption-requestsʺ)

* number of exemptions granted (ʺagp-exemptions-grantedʺ)

* number of names affected by granted exemption request (ʺagp-exempted-domainsʺ)

5. Prevention of Domain Name Sniping (Grabbing)

Domain name sniping (also known as ʺgrabbingʺ) is another common abuse pattern; the name refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted (sometimes by accident, or because a registrant failed to renew the domain with his registrar in time).

Since .sport domains are (per registry policy) automatically renewed when they reach their expiration date, no explicit renewals by registrars are required to prevent a domain name from being deleted when they expire. Registrars need to explicitly delete domains in order to release them for re-registration. This substantially reduces opportunities for domain name sniping.

However, registrars may still send unintended domain deletions, i.e. due to clerical errors or miscommunication with the registrants. Even for these cases, measures against domain sniping are in place.Starting in 2002, registries have started to implement an ICANN proposal, the so-called ʺRedemption Grace Periodʺ (RGP, http:⁄⁄www.icann.org⁄en⁄registrars⁄redemption-proposal-14feb02.htm).

The proposal recommends introducing a 30-day period after a nameʹs deletion during which the name is removed from the TLD zone (in order to give the registrant the chance to take notice of his nameʹs deletion) but is still eligible for being restored by the previous registrar⁄registrant.

Supporting the RGP significantly reduces chances for domain grabbers to obtain inadvertently deleted domains, since a registrant gets 30 days to notice the mistake and restore the domain before it becomes available for re-registration.


The .sport Registry supports the Redemption Grace Period as proposed by ICANN and implements it in full compliance with RFC 3915 (ʺDomain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)ʺ).

6. Prevention of Orphaned Glue Records

According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebookʺ (http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf), a glue record becomes an ʺorphanʺ when the delegation point NS record (the ʺparent NS recordʺ) that references it is removed while retaining the glue record itself in the zone. Consequently, the glue record becomes ʺorphanedʺ since it no longer has a parent NS record. In such a situation, registrars and registrants usually lose administrative control over the record, and the recordʹs attribution to a certain registrar may become unclear, which makes it a potential vector for abuse.

The glue record policy in effect for the .sport TLD avoids this situation entirely by disallowing orphan glue records altogether. This corresponds to policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above. The technical implementation within the Registry and its associated zone generation process ensures this by the following measures:

* As a general principle, glue records are only created if they are really necessary, i.e. only in the case where a name server (e.g. ʺns.example.sportʺ) is used for the delegation of a superdomain of its own name, e.g. ʺexample.sportʺ in this example. If the same name server is used for e.g. ʺexample2.sportʺ, no glue record is created.

* A host object within the .sport TLD (e.g. ʺns.example.sportʺ) cannot exist without its parent domain (ʺexample.sportʺ). Any attempt to create the host ʺns.example.sportʺ will be rejected by the SRS if the domain ʺexample.sportʺ does not already exist or is not sponsored by the registrar creating the host. Likewise, the domain ʺexample.sportʺ cannot be deleted by the registrar if subordinate hosts like ʺns.example.sportʺ still exist. These subordinate hosts have to be deleted before the domain may be deleted; if such hosts are used in delegations for other .sport names, these delegations in turn have to be removed before the host may be deleted.

* If a domain name is put on hold (e.g. as a consequence of the Rapid Takedown Policy described above), this not only means that the delegation for the name itself is removed from the zone; it also means that any occurrences of NS records referencing a name server that is subordinate to the domain are also removed from other .sport domains, along with any accompanying glue records. The same of course holds true should the domain name have to be deleted entirely by the registry.

Consequently, no glue records can exist for a certain domain in the .sport zone after that domain is put on hold or deleted as part of abuse prevention or mitigation procedures.

It should be noted that this policy may lead to other domains (not directly involved in the abuse case) being affected by the takedown if they were delegated to a name server subordinate to the offending domain. Depending on their overall DNS architecture, such domains may become unreachable or less reachable after the delegation point is removed. While this could in theory be avoided by a less rigid orphan glue record policy, the overall benefit of adopting the strict policy described above is deemed higher than the potential damage to domains using an DNS infrastructure depending on an offending domain name.

7. Preventing Use of Trademarked, Reserved, Invalid, Illegal or Otherwise Unsuitable .sport Names

As laid out in the answer to Question 29 (Rights Protection Mechanisms), the .sport Registry takes extensive measures to protect the legal rights of others (such as trademark holders) with regard to .sport domain names. This includes

* conducting a Sunrise phase to allow trademark holders to secure names related to their trademarks prior to GA,

* accessing a Trademark Clearinghouse to validate trademarks presented by registrants,

* offering a Trademark Claims Service, at least during the first 60 days of general availability,

* taking precautions against phishing and pharming and

* committing to full compliance with established Dispute Resolution and Suspension Procedures, including the Uniform Rapid Suspension (URS), the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP), and the Uniform Domain Name Dispute Resolution Policy (URDP).

Please refer to the answer to Question 29 for more detailed information on these measures.

In addition to these specific rights protection measures, CORE Registration System provides the following general means to make sure that no .sport names are registered which are for other reasons deemed invalid, reserved, illegal, offensive or unsuitable.

7.1 Rule Engine

For the most part, this is achieved by the deployment of a complex rule engine that checks each registered name at the time of registration for compliance with a configurable set of rules. Among other things, these rules will include:

* a test to ensure that the domain name has the proper number of labels (which is two for a traditional registry that allows only second level domains to be registered),

* a test to ensure that no hyphens occur in position 3 and 4 of any of the domainʹs U-labels (to protect ʺxn--ʺ and future ACE prefixes),--

* a test to disallow hyphens at the beginning or end of the name,

* a test to find ASCII characters which are neither a letter, nor a digit, nor a hyphen,

* a test to find invalid IDN characters, i.e. characters not contained in any of the support IDN character tables,

* a test to disallow reserved geopolitical names,

* a test to disallow registry reserved names,

* a test to disallow ICANN reserved names,

* a test to disallow otherwise reserved or unsuitable names.

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

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

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

7.2 Compliance with Specification 5 of the Registry Agreement

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

7.3 Pattern Matching and Fuzzy String Comparison

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

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

7.4 Handling of IDNs

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

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

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

The .sport Registry is aware that even within the same script (e.g., Latin), the use of diacritics may potentially cause similar confusion among users, e.g. if the ASCII-only name ʺpaypal.sportʺ and a very similar one with diacritics (like ʺpáypàl.sportʺ) are coexisting as completely separate registrations. Hence, the .sport Registry has decided to treat such names as false variants and only allow their registration by the same registrant. Please see response to Question 44 below, and specially the IDN Table attached there, for further details.

8. Domain Data Access Control

One important point of attack that may lead to abuse of .sport domains and their associated data is the unauthorized or excessive access to data stored within the .sport repository. This applies to both read access (e.g. via public interfaces such as the port 43⁄port 80 Whois) and write access (such as registrar interfaces like EPP or the[8] web-based Control Panel). The measures taken in the .sport TLD to properly restrict access are laid out in the following sub-sections.

8.1 Prevention of Whois Data Mining

The port 43⁄port 80 Whois interfaces grant public access to domain, host and contact data. As such they are a potential target for data mining, i.e. the retrieval of large numbers of postal or e-mail addresses for e.g. the purpose of advertising.

As explained in detail in the answer to question 26 (Whois), the Whois implementation provided by the .sport Registration System prevents such data mining attempts, most importantly by:

* Access to all Whois interfaces is rate-limited (when accessed from IP addresses not whitelisted for unlimited access).

* Web interface users are required to pass a CAPTCHA before access is granted.

* Web interface users seeking access to extended Whois search capabilities are required to authenticate by entering login credentials (which are only issued to eligible parties).

* For improved spam protection, E-mail addresses may be displayed as images only in the web-based Whois.

* Contact disclosure flags as specified in RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, are fully supported. This gives registrants enhanced control over the contact fields they want to disclose in the Whois. In this respect, the system is configurable and allows restricting the use of EPP contact disclosure settings via rules defined by specific registry policies or legal requirements.

8.2 Prevention of Unauthorized Data Modifications

Domain data within the .sport Registry is exclusively provisioned by registrars, i.e. registrants have no direct write access to their data within the repository; all their modifications have to be done via the registrar sponsoring the respective domain. In this constellation, registrants need to trust their registrar and will expect that the management of domain is conducted in a diligent and correct manner. This means that the registryʹs interfaces used by registrars need to be secured in order to only allow the sponsoring registrar of a domain (and nobody else) to modify domain data.

The EPP interface provided by the .sport Registration System does this by:

* requiring SSL⁄TLS on the transport layer,

* requiring a strong EPP password (minimum length, mandatory digits and non-alphanumerical characters),

* requiring changing the EPP password on a regular basis,

* requiring registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,

* requiring registrars to use SSL client certificates known to and trusted by the registry, thus providing an additional means of authentication beyond the EPP password.

Likewise, the web-based Control Panel:

* requires SSL⁄TLS on the transport layer,

* requires registrars to log in with a user name and password (for which the same rules regarding minimum length, mandatory digits and non- alphanumerical characters apply),

* requires changing the password on a regular basis,

* requires registrars to supply lists of IP addresses or subnets from which exclusive access will be granted,

* requires registrars to install SSL client certificates known to and trusted by the registry in their web browsers, thus providing an additional means of authentication beyond the web password.

9. Whois Accuracy

Since .sport is operated as a so-called ʺthick registryʺ, the .sport Whois displays information about the registrant, as well as the administrative, technical and billing contacts of every .sport domain. In cases of malicious or abusive activity involving a .sport domain, this Whois contact information usually is the first and most important source of information, e.g. for law enforcement authorities, to determine in a timely manner the people or organizations responsible for the domain. Consequently, it is deemed very important to maximize the accuracy of contact information stored in the registry repository.

The .sport Registry is therefore committed to taking diligent measures to promote Whois accuracy, including (but not limited to) the following:

* Contact data completeness policy: While RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, merely requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request, the .sport TLD policy for contact data mandates the specification of at least one address line (street), a voice phone number and a postal code in addition. This means that, in addition to the XML schema validation conducted by the .sport SRS for every EPP request received from the registrar (which ensures the presence of all RFC-mandated contact data), the SRS also requires these essential fields to be present and will reject requests lacking them with a ʺparameter value policy errorʺ message. The validation done by the SRS also goes beyond validating against the EPP XSDs with respect to field content. For instance, contact e-mail addresses are required to contain an ʹ@ʹ character and a valid domain name; this is not mandated by the XSDs specified in RFC 5733.

Contact data monitoring: On a regular basis, the registry will run automated plausibility audits on the contact data submitted by registrars. Using publicly available databases, contact address lines will e.g. be mapped to cities and zip codes, which are then compared to the ones provided by the registrant. Likewise, phone and fax numbers will be checked for plausibility.

* Domain data change notifications: [15] The .sport Registration System can be configured (on a per-registrar basis) to automatically notify certain contacts of a domain (e.g. both the registrant and the administrative contact in order to reach multiple people concerned with the domain) after every change made to the domain (i.e. alterations of associated contacts or name servers). When enabled, this feature allows unauthorized or unintended changes to domain and contact data to be detected immediately. This functionality will however need to be deployed after consultation with .sport registrars, since many registrars do not endorse direct communication between the registry and registrants, i.e. their customers.

* WDRP auditing: In 2003, ICANN adopted the so-called ʺWhois Data Reminder Policyʺ (WDRP, http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm) which obliges ICANN-accredited registrars to send yearly Whois data reminder notices to registrants. These notices contain the Whois data currently on file for the respective domain, as well as instructions for the registrant about ways to correct the data if required. While the .sport Registry does not intend to replicate this reminder procedure on the registry level, it will establish an auditing process that monitors the WDRP activities of .sport registrars to make sure that WDRP responsibilities are honored.

10. Resourcing Plans

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

For the initial setup, the following resources are allotted:

* Registry Policy Officer: finalising policies, creating documentation: 7 man days

* System Administrator: monitoring setup: 3 man days

* First Level Support: training: 1 man day per person

* Second Level Support: training: 1 man day per person

For the ongoing maintenance, the following resources are allotted:

* First Level Support: 10 man hours per month

* Second Level Support: 20 man hours per month

* System Administrator: 3 man hours per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks conducted by CORE in the past over the course of 12 months.

Q-29 : Rights Protection Mechanisms

Whenever a new top level domain is introduced, the protection of intellectual property, legal rights and trademarks is an important objective. Using suitable technical means and appropriate policies and procedures, rights owners and trademark holders must be protected from abusive domain registrations throughout a TLDʹs launch phase(s), as well as during the period of general availability (GA) which follows these launch phase(s).

The .sport Registry is fully committed to preventing abusive uses of its namespace, regarding legal rights of third parties, and beyond. It is fully committed to an orderly and trusted namespace with clear and effective policies guaranteeing that domain names are used according to the principles of the .sport TLD by the relevant community, as explained in more detail in questions 18 and 20 above.

In this regard, below is an outline of the Enforcement Policies that will be applied in the .sport TLD having an effect on Rights Protection :

1. Launch Phase (Sunrise; Landrush)

2. Compliance Procedures: General Availability

3. Dispute Resolution Mechanisms⁄Rights Protection

4. Technical Implementation

5. Human Resources


1. Launch phase: Criteria; Conflict Resolution; Mechanisms

As explained in answers to questions 18 and 20, the .sport TLD Launch phase will consist of a long (well over the minimum 30 days as required), orderly Sunrise period during which multiple applications will be accepted and published, and then validated, prioritized and eventually accepted or rejected according to their relative priority.

The Launch phase includes several categories for registrants with prior rights:

1. Federations and Other Governing Bodies
 1.1 International, Continental, Regional, National, Local Federations
 1.2 Other International Sports-related Governing Bodies
 1.3 Public Authorities for their geographic names in relation to sports events.
2. Sports Clubs affiliated to Sports Federations
 2.1 Sports Clubs taking part in international-level championships
 2.2 Other Sports Clubs
3. Corporate Partners
 3.1 Recognised Sports Events Organizers
 3.2 Sponsors
 3.3 Rights-holders, sports-related media, and other sports-related Corporate Partners.
4. Athletes
 4.1 Athletes with participation in World Championships or Olympic Games
 4.2 Other eligible athletes.
5. Defensive Trademark Registrations (when not sports-related, as then they would fit in 3. above)
6. Same Categories as 1-3 above, but with extended Name Selection criteria.

Each application will be individually and thoroughly validated against both the general requirements of .sport registration policies and the specific requirements of each Category or Sub-Category. Priority will be differentiated by Category (and Sub-category) each one having priority over the next one.

Within the same category all conflicting validated applications will be sent through a largely automated, multi-step contention resolution process, incldudng, Mediation, Arbitration, Random Selection and Auction options available to the applicants.

Upon rejection of an application the applicant will have one week to notify their intention to appeal the decision (before an independent Mediation and Arbitration Center). In that case, no application for the same name from the same or lower rank in Sunrise priority will be approved, pending the Appeal. If the Appeal finds that the Registry failed to apply the .sport TLD Launch Registration Policies in an adequate manner, this will result in the restoration of the domain name, for which processing will then resume according to the .sport TLD Launch Registration Policies (within the category or lower priority categories)

The Registry will also offer the TM Claims mechanism as provided by the TM Clearinghouse. This service will be provided not just for the Sunrise period, but also afterwards, during the General Availability Phase.

2. Compliance Mechanisms. General Availability

As explained in questions 18 and 20, once in Ongoing (live) Registration mode, the .sport Registry will perform ex-post validation based on Whois data and use of the domain name, both against the Registrations Policies and the Intended Use Statement provided by the registrant at registration time (or updated afterwards).

2.1 Ex-officio random checks

Checks will be performed by compliance agents both based on complaints and ex-officio, through statistically targeted random checks. The .sport Registry will start with 50 such random cases per day, and will adapt the practices according to the experience gained (it is expected that the number will decrease over time, as reputation and enforcement will make compliance easier over time).

Checks will be carried out both on compliance with the .sport TLD policy and, at the same time, on registrant data accuracy.

In case the compliance agents discover any problem, they will forward the issue to the Compliance Officers, and the registrant will be contacted to clarify⁄correct the situation. If not solved in due time (15 or 30 days, according to the specific cases), the name may be put on registry hold.

2.2 Complaints, Rights Protection

Similarly, in case of a third party complaint for infringement of rights of others, the Compliance Officers will request the complainant to compile a specific form including such information as :

* identification of complainant,

* identification of infringed right,

* declaration of good faith belief that the domain name is used to violate said right,

* indemnification of the Registry in case of action based on false, inaccurate or otherwise non-applicable claims,

* acceptance of jurisdiction of the courts of Edinburgh and Registrant’s domicile, in case the name is blocked and the registrant wants to sue the complainant for damages.

Then the registrant will be contacted. In case the registrant provides within the following 15 business days a counter-statement with some specific content (identification; signed declaration of non-infringement of rights, with explanation of reasons) the domain name will not be blocked, and the complainant shall use the Uniform Rapid Suspension procedure, the UDRP, the .sport TLD Charter Compliance Dispute Resolution Procedure (CCDRP) or file a lawsuit in a competent court. In case the registrant fails to provide all the elements (which will often be the case in blatant violations) the domain name could be put on registry hold.

Against these decisions (not just for Rights Protections, but also in cases of Compliance decisions for Eligibility or use breaches and malicious conduct) the parties may appeal to an independent Mediation and Arbitration Authority according to the .sport TLD CCDRP.

3. Dispute Resolution (and Prevention) Mechanisms involving Rights Protection

3.1 Compliance with ICANN-mandated Dispute Resolution Mechanisms

The .sport Registry will fully comply with all procecures established in Specification 7 of the draft TLD Registry Agreement. the .sport Registry agrees to adhere to any remedies ICANN imposes on Registry Restrictions Dispute Resolution Procedure and Post-Delegation Dispute Resolution Procedure, as implemented and amended in the future.

The .sport Registry further agrees to implement Uniform Trademark Dispute Resolution Procedure (UDRP) and Uniform Rapid Suspension Procedures (URS) in the manner established in the .sport TLD Agreement and the Consensus Policies.

3.2 Additional compliance measures related to ICANN-mandated policies

* UDRP

While compliance with the UDRP as it is now lies on registrars’ side, the .sport Registry is not willing to accept non-compliant registrars preventing its implementation. Besides ICANN-applied sanctions, the Registry will suspend the ability to register new domain names under the .sport TLD for those registrars failing to implement UDRP decisions.

In order to do this, the .sport Registry will implement a specific complaints form for successful UDRP complainants facing non-cooperative registrars for .sport names. Upon evidence of non-compliance, the offending registrar would be prevented from registering any new .sport name for three months after effective compliance the first time, and six months in case of repeated failures to comply. This measure is more effective and less harmful for the end users than termination, and will be included in the .sport TLD RRA.

* URS

The .sport Registry will immediately comply with URS decisions upon notification from the URS Service provider, through its Compliance Team.

Furthermore, the .sport TLD will offer the successful complainant, if the name becomes available for registration at any given time, a Notification Service for any future attempt to register such a name. This service will be free of charge to the successful URS complainant.

* Trademark Claims

As noted above, the .sport Registry intends to extend the TM Claims services beyond the mandatory Sunrise period and the first 60 days of General Availability, on an ongoing base.

4. Technical Implementation

4.1 Launch phase

Technically, Sunrise phases differ from the general availability period in some important aspects:

* In addition to the usual domain data (contacts, name servers), registrars need to collect trademark information (such as trademark name, trademark number, trademark type, trademark application and trademark registration dates) from the registrants and submit this data to the registry when applying for domain names.
* The specified trademark information needs to be validated. This involves verifying the data with the help of a so-called ʺTrademark Clearinghouseʺ, a central repository authenticating, storing and disseminating trademark information (providers for this service are to be designated by ICANN). In addition, manual reviews may be part of the validation process, for which appropriate tools should be in place.
* The results of the trademark validation need to be received and properly processed. This includes notifying all involved parties (such as the registrar and registrant).
* It is possible that multiple applications for the same domain name are received. To distinguish these applications, a unique ʺapplication IDʺ is assigned to each of them in order to clearly identify them in future references, notifications and queries. If more than one of the applications for a domain name carry valid trademark data, contention resolution measures need to be taken in order to determine the registrant to whom the domain is awarded.

The CORE Registration System used by CORE Internet Council of Registrars to operate the .sport TLD fully supports these and other requirements of Sunrise phases via features described in the following.

4.1.1 Sunrise EPP Extension Support

The system supports an EPP extension for submission of trademark data along with domain applications during launch phases such as Sunrise. For multi-phase Sunrise periods, the extension also supports the specification of the phase for which an application is submitted.

Moreover, the extension offers the possibility to submit additional textual information along with an application, such as e.g. the intended use for the domain name, or a URL demonstrating the previous use of the domain name under other top level domains. The registryʹs Sunrise policy governs whether specifying this information is required, which kind of data this information needs to provide, and how this information affects the decision about whether or not a domain name is awarded.

Please refer to the answer to Question 25 (Extensible Provisioning Protocol) for more information about the launch phase EPP extension.

4.1.2 Sunrise Whois Support

CORE provides special Whois services during launch phases like Sunrise. This allows registrants to check the status of their applications independently from information they may obtain from their registrars.

However, the Whois search options and the information returned during Sunrise differs from General Availability (as described in the answer to Question 26). Only the search for application IDs is enabled, without any support for wildcards. If an application ID exactly matches the Whois clientʹs query string, the applicationʹs data (domain name, registrar, application date, contact data and trademark information) is returned, along with information about the applicationʹs status (such as ʺapprovedʺ or ʺunder reviewʺ). See the Sunrise⁄Landrush life cycle specification below for details about possible application states.

4.1.3 Registration Life Cycle Support for Sunrise (and Other Launch Phases)

The system supports the special steps of the registration life cycle that occur during Sunrise, i.e. the initial asynchronous trademark validation and⁄or selection processes.

The registration life cycle described in the answer to Question 27 (Registration Life Cycle) applies to the ʺGeneral Availabilityʺ (GA) phase of the .sport TLD, i.e. the normal ʺFirst-Come, First-Servedʺ (FCFS) period that usually starts after a TLD has finished its initial launch phase(s). Launch phases like Sunrise and Landrush usually involve a special life cycle that adds some complexity to the initial domain creation step.

During Sunrise phases, this step comprises the validation of trademark data and the determination of the winning application if multiple ones were received. Depending on the concrete registry policy in place, one or multiple Sunrise phases may be conducted.

So-called ʺLandrushʺ phases are usually conducted after (or in parallel to) Sunrise phases in order to limit the load on the Shared Registration System (SRS) that usually occurs during the initial run on popular, generic names. Their goal is to replace the brute-force FCFS approach of the GA by a fair, controlled domain assignment process that does not encourage registrars to flood the SRS with requests when GA starts. Similar to Sunrise, most Landrush approaches let registrars submit multiple applications for the same domain name, among which a winner is determined by asynchronous contention resolution measures as defined by the registryʹs policies. In contrast to Sunrise, usually no special proof of eligibility needs to be supplied by registrars or validated by the registry during Landrush.

4.1.3.1 Life Cycle Support for Sunrise

During both Sunrise and Landrush, the first step of the normal domain life cycle (ʺcreate domainʺ, position (A) in the GA life cycle diagram Q27-F1 from the answer to Question 27) consists itself of a number of individual steps representing the registryʹs rights protection workflow. The steps during Sunrise are depicted in Figure Q29-F1:

(A1) Registrars are required to submit Sunrise applications for domain names by sending EPP ʹʹdomain:createʹʹ commands containing a special EPP extension for the specification of relevant trademark data. In addition, a second EPP extension may be used to specify data required to resolve a potential contention with regard to the domain name, such as the registrantʹs bid for the case that an auction should be held to decide the final assignment of the domain name (if the registryʹs policy utilises auctions to resolve contention during Sunrise).

Application data is stored in the registry database. Checking this data for validity may involve manual evaluation that needs to be done asynchronously. Also, multiple valid applications for the same domain name may be submitted during Sunrise, which is why applications are collected until the end of the Sunrise submission period, after which evaluations (and, if required, contention resolution) take place to determine the final outcome. The final result of the application is later communicated to the registrar via an EPP poll message. A unique application ID is assigned to the application and returned to the registrar for future reference and queries.

(A2) The registry system accesses the API of the connected Trademark Clearinghouse in an attempt to validate the submitted trademark information in relation to the desired domain name.

(A3) If the check with the Trademark Clearinghouse fails, i.e. the provided trademark information is found to be evidently invalid, the application is rejected immediately without further manual review. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the negative outcome of the application. The applicationʹs status is now ʺinvalidʺ, which is also displayed in the special launch phase Whois output when the application ID is queried.

This step in the life cycle may also be reached later in the validation process, i.e. after the application was found invalid during a manual review, or when a contention resolution for a name with multiple valid applications was lost by the registrant. In the latter case, the applicationʹs status is ʺrejectedʺ, which is also displayed in the Whois output when the application ID is queried.

(A4) If the check with the Trademark Clearinghouse succeeds, i.e. the provided trademark information is found to be (at least tentatively) valid, the application is added to the pool of automatically validated applications for the given name. Such applications are collected in the registry database until the end of the Sunrise submission period. The registrar may withdraw the application by sending an EPP ʹʹdomain:deleteʹʹ before the Sunrise submission period ends.

The applicationʹs status is now ʺpendingʺ, which is also displayed in the Whois output when the application ID is queried.

(A5) At the end of the Sunrise submission period, the application may be further evaluated, potentially involving manual checks. If the outcome of this evaluation is that the application is invalid, the application is rejected by going to step (A3).

(A6) All remaining, valid applications for the given name are examined. If there is only one valid application (left) for the given name, this application may be approved in step (A7). Otherwise, a contention resolution needs to be conducted to determine the final assignee for the application, which is done in step (A8).

(A7) The application is approved, the domain is allocated and assigned to the registrar. An EPP poll message is placed in the registrarʹs message queue to inform the registrar about the positive outcome of the application. The domain proceeds into the registered state.

The applicationʹs status is now ʺallocatedʺ, which is also displayed in the Whois output when the application ID is queried.

(A8) Since multiple valid applications for the same name were submitted, a contention resolution is required to determine the registrant to which the domain is awarded (the actual contention resolution used for .sport TLD is described below). If the resolution is won, the next step is (A7); if it is lost, the next step is (A3).

During the contention resolution, the applicationʹs status is ʺvalidatedʺ, which is also displayed in the Whois output when the application ID is queried.

4.1.3.2 Life Cycle Support for Landrush

The steps during a Landrush phase are quite similar to the ones for Sunrise. As depicted in Figure Q29-F2, the basic approach is the same, except that no trademark information is submitted or reviewed in the process; the only aspects governing the assignment of the domain name during Landrush are

* whether more than one application was received for the name and
* if this should be the case, which of these applications wins the contention resolution.

The availability of Landrush support in the CORE Registration System does not imply that dedicated Landrush phases must be held. While they are technically feasible, registry policy may also dictate that Sunrise and Landrush are conducted in a single phase, or in overlapping phases. The CORE Registration System is prepared for such cases. A combined Sunrise⁄Landrush phase is e.g. possible by allowing applications during Sunrise to be submitted without carrying any trademark data (which marks them as Landrush applications). During the selection process, applications carrying trademark data (i.e. proper Sunrise applications) then always take precedence over ones that were submitted without such data; only if no valid Sunrise applications are received for a name, the Landrush applications for the name are considered, and the winning one is determined in accordance with the registryʹs contention resolution policies.

Another alternative to a dedicated Landrush phase is the use of a FCFS approach for GA with staggered pricing; in this approach, a domainʹs initial registration price is relatively high when GA starts, but is decreased over time. Registrants willing to pay the high price may register the domain early on, others will try waiting until the price goes down. Despite the FCFS principle, such staggered pricing will usually prevent a flood of requests from registrars at the beginning of GA. The CORE Registration System supports this approach by its flexible billing module, which allows the definition of prices for all billable operations for specific time periods, i.e. different prices may be defined for e.g. the first day after the start of GA, the second day, the third day and so forth. It is even possible to use a formula-based approach to express the domain price as a function of the elapsed time since the start of GA.

The billing module, in conjunction with the rule engine described in the answer to Question 28, may also be used to charge individual, higher prices for attractive, generic names (ʺpremiumʺ domains). If a registry chooses this approach, domains affected by this special pricing are configured in the rule engine, along with a so-called ʺprice modelʺ identifier that determines the tariff used for each of these domains.

See below for more information on the GA approach designated for the .sport TLD.

4.1.4 Trademark Clearinghouse Support

The CORE Registration System is prepared for accessing APIs of the Trademark Clearinghouse in order to validate the trademark information submitted by the registrar during Sunrise. In addition, the system also contains provisions to make use of the Trademark Clearinghouse APIs for providing a Trademark Claims Service as soon as the .sport TLD enters a period of general availability (see below for more information on this service).

Since Trademark Clearinghouse Service Providers have not been assigned by ICANN at the time of writing, the full technical specifications for these APIs are not yet known. While basic provisions have been made in the CORE Registration System to connect to these providers, the details will therefore have to be finalised once the service providers have been announced and API specifications are available. As described below, appropriate developer resources are allocated to perform this task.

4.1.5 Support for Multiple Applications for the Same Domain Name

The CORE Registration System is designed to maintain multiple domain objects representing the same domain name at a given point in time. This feature is required to store multiple applications for the same name during launch phases like Sunrise.

To distinguish between the various applications for the name in the database (as well as in external APIs), each application is assigned a unique application ID. These application IDs are returned to registrars in the responses to domain applications via EPP and may subsequently be used, among other things, to enquire an applicationʹs review status. Also, review results are reported back to registrars via poll messages carrying the unique application ID. Registrars can utilise the ID to clearly associate results with their various applications. Registrants may query the status of their applications from the .sport Whois server using the ID.

4.1.6 Issue System

When manual reviews of Sunrise applications are required, this typically involves a specific support team workflow that, among other things, consists of

* storing application data in a database,
* making application data available to the support staff via a web interface,
* assigning the task of reviewing applications for a certain domain name to a specific support member (for the purpose of clear responsibilities),
* having the application reviewed by the assigned person, who in the process may
** request additional information or documentation from the registrant,
** add such documentation, as well as comments concerning the review, to the application,
** make a decision about the applicationʹs outcome or
** forward the task to a different support person with better insight or higher decision privileges (who may then make the final decision).

To support this workflow, the CORE Registration System is equipped with a built-in Issue System that offers registry personnel a convenient web interface to review domain name applications and approve or reject them accordingly.

The Issue System

* offers an SSL-secured web interface accessible by the .sport Registry staff only;
* allows searching for applications by various criteria (e.g. domain name or current workflow⁄approval state);
* allows a registry support person to find newly submitted or otherwise unassigned applications and to take responsibility for them;
* offers a two-level review workflow that allows the delegation of pre-selection tasks to the first level support staff, after which a final decision - if still required - can be made by second level personnel;
* conveniently displays all application details, including registrant information, the supplied trademark information, as well as the results of the verification of that trademark data with the Trademark Clearinghouse;
* fully tracks and documents application status and history, allowing for a complete audit in case of disputes or legal enquiries and
* is fully integrated with the registry backend, i.e. it automatically notifies the SRS about the reviewersʹ decisions and immediately activates the respective domain in case of an approval. The Issue System also triggers the creation of appropriate EPP poll messages in order to keep registrars informed about the outcome of their applications.

The Issue System was first employed using puntCATʹs elaborate multi-phase Sunrise period in 2006 and proved to be an invaluable tool for efficiently organising a TLD roll-out process. It ensures that the registry staff reviewing Sunrise applications finds all information relevant to a domain name in one place and comes to well-founded decisions in a timely manner. The experience gathered from developing and operating the Issue System in that context helped to develop a second-generation version that is now part of the CORE Registration System.

4.1.7 Support for Resolving Contention

If multiple valid and eligible applications for a domain name are received, a well-defined and deterministic process is required to nominate the winning application. The details of this contention resolution procedure highly depend on a specific top level domainʹs policies; for example, a top level domain that represents a certain geographic region may have a policy that prefers trademark holding companies based in that region over other eligible trademark holders.

However, even after such policy-based considerations, multiple candidates for the winner of an application may be left in contention. In such a situation, different tie-breaker rules can be applied to make a decision.

4.1.7.1 First-Come, First-Served

The obvious tie-breaker rule is to simply award the domain to the first application submitted, i.e. the one that carries the earliest time stamp among the ones in the contention set. Since the CORE Registration System assigns a unique time stamp to each received application in a fair, unbiased manner and makes it available to the review staff of the .sport Registry, this ʺfirst-come, first-servedʺ strategy is a viable, technically supported way to resolve contentions.

4.1.7.2 Auctions

However, first-come, first-served selection processes based on application submission times have the drawback of potentially encouraging registrants and registrars to submit all their requests as soon as the registry starts accepting applications, which imposes time pressure on the involved parties, puts a considerable load on the involved systems and may cause an unfair advantage for registrars with better connectivity to the SRS.

Therefore, the CORE Registration System also supports a simple auction-based tie-breaker approach out-of-the-box. It allows the registrar to submit a single, blind bid amount along with the Sunrise or Landrush application (via a special EPP extension). To avoid the submission of more than one bid, multiple applications for the same domain name carrying identical trademark data (during Sunrise) are rejected.

In the case of a contention, the application that was submitted with the highest bid wins. In the unlikely event that two applications were submitted with the exact same bid amount, the one with the earlier time stamp wins; this also applies to the corner case that multiple applications were received but none of them carried a bid, which is treated as if all were submitted with a bid of zero. Only the winning applicant pays his bid, i.e. there is no extra fee for placing a bid; this ensures that the process cannot be regarded as a lottery. If no contention should arise (i.e. there is only one applicant left before bids would be considered as a tie-breaker), the bid amount is irrelevant and only the standard application fee (which is always due) is paid.

4.1.8 Trademark Claims

When a match of a registered name is found via the API provided by the Trademark Clearinghouse, the Trademark Claims Service is supposed to provide clear notice to a prospective registrant of the scope of the mark holderʹs rights. The registrant will in turn be required to provide statement that

* he received notification that the mark is included in the Trademark Clearinghouse,
* he received and understood the notice and
* his registration and use of the requested domain name will not infringe on the rights that are subject of the notice.

The registrant will be directed to the Trademark Clearinghouse Database information referenced in the Trademark Claims Notice to enhance understanding of the Trademark rights being claimed by the trademark holder.

Also, if a domain name is registered in the Trademark Clearinghouse, the registry will, through an interface with the Clearinghouse, promptly notify the mark holders(s) of the registration after it becomes effective.

4.2 Reducing opportunities for noncompliance

As laid out in that answer, the underlying set of checks can be tuned to block registrations of .sport names based on various syntactic rules, multiple reserved names lists, and patterns. Prior to the launch of the .sport TLD, the rule engine will be configured in accordance with the policies of the .sport Registry. Reserved names lists will be populated as governed by all eligibility restrictions that need to be enforced, which means that such names are not available for registration by registrars.

However, should eligible parties approach the .sport Registry (via a registrar) providing sufficient evidence of their eligibility for a specific reserved domain name, the .sport Registry can enable the chosen registrar to register the domain name for that specific registrant only (circumventing the rule engine check that would otherwise prevent the registration).

4.2.1 Reducing Opportunities for Phishing and Pharming

In most cases, the abusive behaviors of phishing and pharming constitute, among other things, a severe violation of the legal rights of others. Both practices are usually applied to make users enter confidential or otherwise exploitable information on fake web sites pretending to be operated by a certain company or institution. In the case of phishing, the attack is usually done by trying to conceal the real domain name in the URL, or by using a domain name very similar to the one the user originally meant to visit. In the case of pharming, the attack happens on the DNS level, i.e. while the user still sees the correct domain name of the site he meant to visit, the IP address his resolver determined for the domain name somehow gets manipulated to point to the fake web site; in many instances, this manipulation happens on a node close to the user, e.g. by altering a desktop computerʹs local hosts file (overriding normal DNS resolution), or by modifying the DNS lookup facilities of an Internet router at the userʹs home.

Due to the way these attacks are conducted, neither phishing nor pharming can be entirely prevented on the registry level. However, the registry can put mechanisms and policies in place that will make such exploits harder or limit their duration and impact.

4.2.1.1 Phishing

One important tool to rapidly address phishing activities shown by a web site operated under the .sport TLD is the Rapid Takedown Policy described in the answer to Question 28 (Abuse Prevention and Mitigation). It allows a fast takedown of an offending site after respective activities were reported and confirmed.

In addition, the flexible rule engine used by the CORE Registration System to validate permissible .sport domain names can be utilised in the context of phishing. Should a certain .sport domain name (or a pattern of such names) be repeatedly involved in attempts to mimic a rights holderʹs legitimate .sport name for phishing purposes, the set of registration validation rules can be easily augmented to prevent the offending domain name (and, if need be, even an entire pattern of names deemed too similar to a rights holderʹs legitimate domain name) from being registered again after takedown. Of course, this practise will be exercised in close collaboration with ICANN and other parties potentially involved in the definition of names deemed not eligible for registration within the .sport TLD.

As described in the answer to Question 28 (Abuse Prevention and Mitigation), the sophisticated IDN handling implemented by the CORE Registration System is designed to provide protection against the most common cases of IDN-based phishing attempts, such as IDN homograph attacks. Please refer to the answers to Question 28, as well as Question 44 (Support for Registering IDN Domains), for more information on this topic.

4.2.1.2 Pharming

With regard to pharming, neither the quick takedown of offending domain names nor the blocking of such names are suitable as countermeasures. Due to the nature of the attack, the registryʹs approach needs to aim at a robust DNS infrastructure for the .sport TLD, which ideally should guarantee the integrity and authenticity of DNS lookup results all the way from the registry-operated TLD name servers to the userʹs local resolver.

As described in detail in the answer to Question 35 (DNS service, configuration and operation of name servers), the .sport Registry will deploy a highly reliable and secure DNS subsystem for the .sport TLD, which is powered by the elaborate DNSSEC setup laid out in the answer to Question 43 (DNSSEC). The .sport Registry is therefore able to safeguard against any attempts to perform DNS manipulation on the level of the name servers operating the .sport TLD zone.

However, due to the way the domain name system (and DNSSEC in particular) works, preventing manipulations of the .sport TLD name servers alone is not sufficient to avoid pharming attacks. In order to provide complete protection, DNSSEC support is required on every level of the domain resolution process, from the root zone via the TLD name servers and the delegated name servers down to a userʹs resolver. This means that registrars need to sign the zones they host on their name servers (and offer this service to their registrants), and resolvers (or other clients looking up .sport domain names) need to verify the signatures and notify their users when inconsistencies are detected. Consequently, the .sport Registry will encourage and advertise the widespread support and use of DNSSEC among registrars, registrants and end users. Once DNSSEC has been widely adopted, web browsers, e-mail clients and similar applications will increasingly support the verification of the related signatures out-of-the-box (rather than via the extensions available today), which will drastically diminish opportunities for pharming. In this ideal setup, even a local hosts file placed by a virus on a desktop computer to override its DNS lookups would not remain undetected, since the user aware of DNSSEC would instantly get notified about wrong or lacking DNSSEC signatures.

5. Resourcing Plans

The CORE Registration System already supports the rights protection features described above at the time of writing. No coding is required for this, which means that no special developing resources will be needed. The staff on duty at CORE Internet Council of Registrars will be in charge of performing manual reviews of trademark data where required.

One aspect to be considered for resource planning is the registry systemʹs connection to the Trademark Clearinghouse; since the involved API is not fully defined at the time of writing, some software development will have to be done in order to integrate the Clearinghouse into the Sunrise workflow, as well as to incorporate it into the designated Trademark Claims Service.

For the initial setup, the following resources are allotted:

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

For the Sunrise phase, the following resources are allotted:

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

For the ongoing maintenance, the following resources are allotted:

* System Administrator: 1 man day per month

Employees already working for CORE Internet Council of Registrars will be handling these tasks. The numbers above were determined by averaging the effort required for comparable tasks.

Q30 a) - External Technical & Operational Capability

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

Knipp Medien und Kommunikation GmbH, the technical provider for CORE Internet Council of Registrars, is currently in the process of being certified according to the ISO 27001 standard. The completion of the certification process is estimated for Q4⁄2012.


1. Security Policy

As .sport Registry does not perform the technical operation of the registry itself, but has contracted CORE Internet Council of Registrars for that purpose, .sport Registry defines a general security policy framework that is imposed on itself, CORE and all further contractors and subcontractors. All participating entities have to ensure that their security policies meet the requirements of the framework.

The security policy framework has the following key objectives:

* confidentiality
* access
* accountability
* availability

These objectives are further explained in the following.


1.1 Confidentiality

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

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


1.2 Access

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

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


1.3 Accountability

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

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

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


1.4 Availability

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

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


1.5 Security Role Concept

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


2. Security Commitments to Users of the .sport TLD


2.1 Abuse Prevention and Mitigation

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


2.2 Reliability and Availability of DNS

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


2.3 Technical Progress

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


3. Security Commitments to Registrants


3.1 Protection of Investment

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

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


3.2 Adherence to Registration Policy

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

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


3.3 Privacy of Registrant Data

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

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

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

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

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