Application number: 1-959-51046 for .music LLC

.music LLC

179 Belle Forest Circle
Suite 104
Nashville TN 37221
US

615 777 3848

615 829 8718

http:⁄⁄www.farfurther.com

Mr. John Styll

President⁄Chief Operating Officer

615 479 0103

js@farfurther.com

Mr. Loren Balman

Chief Executive Officer

615 260 0290

lb@farfurther.com

Limited Liability Corporation

State of Tennessee, United States of America

Not Available

Far Further LLC

Cal Turner III
Chairman
John Styll
President
Loren Balman
Chief Executive Officer

Cal Turner III
Chairman
John Styll
President⁄Secretary
Loren Balman
Chief Executive Officer

Cal Turner III
Chairman
Loren Balman
Chief Executive Officer
Stephen Kelley
Not Applicable

music

Not Available

.MUSIC LLC foresees no known rendering issues in connection with the proposed .music string which it is seeking to apply for as a gTLD. This answer is based upon consultation with .MUSIC LLC’s backend provider, Neustar, which has successfully launched a number of new gTLDs over the last decade. In reaching this determination, the following data points were analyzed:
• ICANN’s Security Stability Advisory Committee (SSAC) entitled Alternative TLD Name Systems and Roots: Conflict, Control and Consequences (SAC009);
• IAB - RFC3696 “Application Techniques for Checking and Transformation of Names”
• Known software issues which Neustar has encountered during the last decade launching new gTLDs;
• Character type and length;
• ICANN supplemental notes to Question 16; and
• ICANN’s presentation during its Costa Rica regional meeting on TLD Universal Acceptance

The mission of .music is to collaboratively grow a domain that serves artists, songwriters and music professionals; promotes music, and nurtures the art… all for the love of music. 

Music is one of the few experiences that is both truly unique to our species and common across all people. Music is such a defining aspect of humanity that when we talk with others about music we ask them what kind of music they like, never whether they like music. One needs look no further than ICANN itself for an example of the power of music to communicate and unite. Nearly every host committee has used music to introduce participants from around the world to its country’s culture, languages and even belief systems. Music is so central to what makes us human that it’s hard to imagine a human being without a relationship with music in some shape, form or expression. 

Over the course of history, music has had various statures at different times and with different peoples. At times, the musician and their creations have been upheld and admired, banned and rejected, rewarded, punished, supported, and impoverished. Yet, throughout this turbulent and tenuous relationship we have continued to crave music as a fundamental fulfillment of self. 

Today, we are in an age of appreciation for the art of music. It is a significant force in modern cultures and even a significant force in our economic productivity. Nonetheless, resource constraints challenge our ability to educate musicians and audiences alike. While new technologies have played a central role in increasing the global availability of diverse musical traditions in recent years, we have yet to fully tap into the power of that same technology to sustain and nurture music, musical creators, and their audiences. As T. S. Elliot once said: “You are the music while the music lasts.” 

The fundamental purpose of .music is to help ensure that the music CAN last. The mission of .music is to serve artists, musicians, songwriters and music professionals that support them through a Top-Level Domain (TLD) that promotes music and nurtures the art. 

The .music TLD will provide the global community of music makers, music educators, music advocates, and music professionals with a unique identifier on the Internet that respects and supports intellectual property rights and facilitates the advancement of music education. The .music TLD will facilitate global collaboration among, and promote the musical identity of artists, musicians, songwriters and the professionals that support them, as well as music educators and arts-oriented policy makers through a relevant and shared website and email address suffix. The .music TLD will facilitate music creation, career development, promotion and distribution, and will serve as the artistʹs ally and advocate. Our goal is to make the .music TLD transform the current landscape by addressing the needs of artists, musicians, bands and songwriters who are looking for new ways to promote themselves and their creative work in the face of economic challenges and technology shifts that have eroded the efficacy of traditional methods of promotion. 

These economic challenges and technology shifts have led many to assume that the benefit of those who produce, play or practice the art of music is at loggerheads with those who consume it. The .music TLD challenges that notion by focusing on the one thing they both have in common: a passion for music. For the music to last, there has to be a balance between the needs and desires of both. The .music TLD as envisioned will strive to do just that. Providing the music community a safe and secure platform will mitigate the fears that plague and limit the natural desire of those who produce, play or practice the art of music to express themselves and seek wider distribution for their work. In turn, this provides a wider, deeper and richer content experience for the fans and consumers of music. The era of perceived friction between the producers and consumers of music is about to end, as both find a new platform where their mutual interests and desires coalesce for the combined greater benefit.

With enhanced visibility, security and protection, the .music TLD will change how we interact with music entities on the Internet. Far Further’s vision is to be a greenhouse for musical creativity and a concourse for the promotion of music creators, resulting in frictionless delivery of their music to global audiences in an environment that respects their creative works and the rights of artists. In short, it will serve as a nexus between the music community and the Internet. 

As musicians, we are challenged to keep pace with changing technology and constantly-evolving methods of accessing music. It is well known that one of the greatest concerns of this community is the protection of intellectual property (IP) rights. Part of our mission is to provide a domain with safeguards from abuse and to take appropriate measures to protect the rights of creators and owners. As a restricted TLD, .music will effectively support the community’s interests in protecting IP rights and will be unavailable to those known to operate outside the legal IP paradigm. 

How do you expect that your proposed gTLD will benefit registrants, Internet users, and others? Answers should address the following points: 

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

Our goal is to work with members of the global music community to create a trusted, secure and restricted TLD for accredited members of the music community. The dotMusic Registry will provide qualifying registrants the opportunity to register their preferred domain name in a safe, reputable and globally accessible TLD. Registrants will be identified and validated as members of the music community through their existing and maintained membership in existing associations related to the creation and support of music. 

The World Wide Web today features a large number and enormous variety of music-related websites. While our business model depends only on modest uptake in the early years, we anticipate that as the .music TLD demonstrates the trust and security of a specialized namespace over time, more and more music-related content and related economic transactions will be moved to the .music TLD from current gTLD and ccTLD domains. 

• The .music TLD will meet or exceed the ICANNʹs availability requirements. The .music TLD will operate as an exemplary registry, using best practices and deploying appropriate technology to safeguard creative rights, providing end users assurance about the identity and community qualifications of the TLD’s registrants. 
• The .music TLD will use a variety of online scanning tools that search for key words that are commonly used to signal the availability of music distributed without appropriate authorization or in violation of intellectual property rights to aid in mitigating copyright infringement for the music community in general.
• The .music TLD will maintain a reputable marketplace for end-users through our general abuse policies and their active enforcement. 

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

Among ICANN’s core values is a fundamental commitment to “Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest.” The dotMusic Registry will be a new direct competitor to the current group of global generic TLDs, offering an entirely music-focused environment and branding. Our business plan is to serve musicians in economically-developed, as well as key growing international markets, who will benefit from a TLD registry dedicated to address the unique needs of its community. 

The dotMusic Registry’s differentiation will be “supporting and sustaining musical creativity through respect for intellectual property”. More than any of the current community-focused gTLD registries, we will provide end-users a domain space that assures them of the community qualifications and identity of a registrant. The reputation of that registrant is tied to their domain registration through verification of their membership standing by their applicable music association. The dotMusic Registry will directly verify a registrant’s affiliation with a qualifying music association member both at initial application and through annual reviews of each association. Intrinsically, this adds the reputational weight of many music associations (through our .music registrants) to that of the domain name. 

The dotMusic Registry’s innovation will focus on two areas: 1) The restricted registrant participation of our string, which we believe is an ideal combination of inclusiveness for all music associations and their members AND validation of community standing, and 2) Our enhanced abuse management programs to ensure the sustainability of the artist and songwriter through protection of their creations. 

New gTLD registries have largely focused on North America and European marketplaces. Since music is the “universal language”, as the dotMusic Registry, we will offer the .music TLD to international markets, with the goal of a truly global distribution of registrants. To further serve the international market, the dotMusic Registry may at its option, offer the IDN equivalents of .music in other scripts⁄languages. 

Our intent is to operate .music with a focus on trust and security for the .music brand. This entails running a robust rights protection program from initiation, which in our case meets - and significantly exceeds - ICANN’s requirements. We will engage an abuse-detection and prevention team, as well as bring on board an experienced and disciplined management team. These, along with other strong provisions (detailed in our answers to 28, 29 and 30), will enable us to act where registrars are remiss in their responsibilities. The dotMusic Registry will have the potential to set new standards for the reduction and mitigation of domain abuse. 

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

The purpose of .music is to provide an online “home” to registrants identified as members of the .music community to hold active registrations for their name or online identity⁄brand The Internet user will know that they are dealing with a registrant that is identity-verified and compliant in their use and distribution of intellection property. This assurance allows Internet users of the .music TLD to have high expectations of trust and security regarding content purchased or consumed. These are intrinsic in the qualifications associated with our defined community. 
 
The dotMusic Registry will deploy DNS Security Extensions, also known as DNSSEC, for the .music TLD. DNSSEC will help prevent data integrity attacks, and the risk of users being diverted or hijacked to malicious or unsafe sites, which often are involved in identify theft. DNSSEC deployment will ensure that visitors to .music domain names are in fact reaching their intended website and not subject to malicious activity such as phishing or identity theft. We will also abide by all policies and practices required by ICANN in the Registry Agreement and⁄or via any Consensus Policy. 

In support of this registration requirement, we make a firm commitment to protecting users of our TLD and to maintaining the TLD as a reputable space. Our .music will have powerful policies and procedures for dealing with abusive registrations, and the illegal or malicious use of domain names. We describe those plans fully in our response to Question 28 (“Abuse Prevention and Mitigation”). 

The introduction of .music will include a rollout planned with a primary goal of protecting trademark rights and intellectual property. We describe those plans fully in our responses to Question 18(c) and Question 29 (“Rights Protection Mechanisms”). 

Users of the .music TLD will also have the use of the WHOIS service; registrants and other contacts will have their contact details available via WHOIS. Please see our answer to Question 26 regarding “searchable WHOIS” and rate-limiting. Limiting the mining of WHOIS data will mitigate spammers and other malicious parties who abuse access to WHOIS services by mining the data for their own illegitimate purposes.

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

Musical artists, musicians, songwriters and music professionals who are validated members of a qualifying music association will be permitted to register second level names (name, online identity⁄brand) in the .music TLD. As such, the TLD will have a restricted registration policy so that Internet users are assured that a .music registrant is in fact a member of at least one or more Member Organizations in the Global Music Community. The TLD is supported by music organizations and associations from around the globe, and will be available to registrants in all areas of the world. Since many qualifying music associations themselves are global in nature and⁄or accept membership from individuals globally, we anticipate rapid international participation. Domain registrations may be accepted, but will not resolve until the registrant has been identified and validated as a member of the music community via their membership in at least one existing association related to the creation and support of music. Second level .music domain names can be registered by individuals, businesses and not-for-profit entities.

Members of the community of musical artists, musicians, songwriters, and music professionals have highly varying needs and use websites in a wide variety of ways. In addition, because .music will operate as a global registry from inception, formatting flexibility is required to accommodate bandwidth constraints that may be experienced in the developing world. Accordingly, the registry will not mandate any particular formatting or usage. Registrants must, however, hold valid rights to all materials displayed on and⁄or distributed through their specific site. We anticipate this will result in innovative and creative websites by .music registrants. 

Reserved Names:
 
In .music we will reserve the following classes of domain names, which will not be available to registrants via the Sunrise or subsequent periods:

• The reserved names required in Specification 5 of the new gTLD Registry Agreement.
• The geographic names required in Specification 5 of the new gTLD Registry Agreement, and as per our response to Question 21. See our response to Question 22 (“Protection of Geographic Names”) for details.
• The registry operator will reserve its own name and variations thereof, and registry operations names (such as nic.music, and registry.music,), so that we can point them to our Web site. Reservation of the registry operator’s names was standard in ICANN’s past gTLD contracts.
• We will also reserve names related to ICANN and Internet standards bodies (iana.music, ietf.music, www.music, etc.), for delegation of those names to the relevant organizations upon their request. Reservation of this type of name was standard in ICANN’s past gTLD contracts.
The list of reserved names will be published publicly before the Sunrise period begins, so that registrars and potential registrants will know which names have been set aside. 


Premium Names: 
 
• The dotMusic Registry will also designate a set of “premium names,” which will be set aside for distribution via special mechanisms. Premium names have been a standard feature of gTLD and ccTLD rollouts since 2005. The list of premium names will be published publicly before the Sunrise period begins, so that registrars and potential registrants will know which names have been set aside. 
• Premium names will be distributed by application only. We will accept applications that describe intended use of a given premium name that best supports the development of the .music community consistently with its defining criteria. The policies and procedures for receiving, reviewing, and awarding premium name applications will be posted on the .music web site in advance, based on input from the .music Policy Advisory Board. We will create policies and procedures that ensure clear, consistent, fair, and ethical distribution of names. For example, all employees of the dotMusic Registry operator, and its contractors, will be strictly prohibited from bidding in auctions for domains in the TLD. As an additional protection for Rights Holders we will continue to use the Trademark Clearinghouse during General Availability (Trademark Claims Service) for an additional 60 days, for notifications of new registrations only where the string is a complete match with a filing in the Trademark Clearinghouse. Additionally, we will address this process asynchronously to the registration process and in consideration of the technical capabilities⁄limitations of the Trademark Clearinghouse, once an implementation model for the Clearinghouse has been finalized.

Dispute Resolution Mechanisms: 

• Registrants and rights holders will have access to several dispute mechanisms. These are fair and transparent processes to adjudicate claims to domain names, and they also protect registrants against reverse domain hijacking.
• Names registered in the Sunrise Period will be subject to a Sunrise Dispute Policy. This policy and procedure will be in effect for a finite time period, to provide special protection of qualified trademark rights. Please see our response to Question 29 (“Rights Protection Mechanisms”) for full details.
• As required by ICANN, .music domains will be subject to the Uniform Dispute Resolution Policy (UDRP). Please see our response to Question 29 (“Rights Protection Mechanisms”) for full details.
• As required by ICANN, .music domains will also be subject to the Universal Rapid Suspension (URS) policy. See the URS specifications in Applicant Guidebook Module 5. Please see our answer to Question 29 (“Rights Protection Mechanisms”) for full details about how we will provision for our URS responsibilities.
• We will provision systems to take in and administrate cases as per ICANN’s Registrar Transfer Dispute Resolutions Policy ( http:⁄⁄www.icann.org⁄en⁄transfers⁄dispute-policy-12jul04.htm ) This process will allow registrars to protect registrants by filing disputes about inter-registrar transfers that they believe were unauthorized or improperly executed.
• MEDRP: .music will support the Music Eligibility Dispute Resolution Requirements Procedure. This dispute mechanism will be available to members of the .music community and end-users to file claims against registrants of the .music domain for violations of the .music eligibility and use community rules and policies. We will select an adjudication service from the list of ICANN approved arbitrators to facilitate MEDRP claims (please see Q28 and Q29 for further details).


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. 

We will have several measures for protecting the privacy or confidential information of registrants or users. 
 
• Please see our answer to Question 26 regarding “searchable WHOIS” and rate-limiting. That section contains details about how we will limit the mining of WHOIS data by spammers and other parties who abuse access to the WHOIS. 
• Please also see our answer to Question 28, regarding the use of proxy and privacy services. We will allow the use of such services, where they comply with ICANN policies and requirements, which can protect the privacy and personal data of registrants from spammers and other parties that mine zone files and WHOIS data. If ICANN establishes a privacy⁄proxy service accreditation program, registrars will be required to use accredited providers only. We are aware that there are parties who may use privacy services to protect themselves from political or religious persecution, and we respect this need. In Question 28, we also describe our proposed policies to limit the use of privacy and proxy services by malicious parties, thereby reducing e-crime within the TLD.
• As per the requirements of the new gTLD Registry Agreement (Article 2.17), we shall notify each of our registrars regarding the purposes for which data about any identified or identifiable natural person (“Personal Data”) submitted to the Registry Operator by such registrar is collected and used, and the intended recipients (or categories of recipients) of such Personal Data. (This data is basically the registrant and contact data required to be published in the WHOIS.) We will also require each registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data. As the registry operator, we shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars.
• As the registry operator we shall take significant steps to protect Personal Data collected from registrars from loss, misuse, unauthorized disclosure, alteration, or destruction. In our responses to Question 30 (“Security Policy”) and Question 38 (“Escrow”) we detail the security policies and procedures we will use to protect the registry system and the data contained there from unauthorized access and loss. 
• As registry operator we plan to use ICANN accredited registrars who agree to a variety of information technology policies and procedures designed to verify registrant eligibility, validate registrant contact data, and protect registrant data from unauthorized access, use, or alteration. These may include standards for access to the registrar and registry system, password management protocols. Please see our response to Question 30 (“Security Policy”) for details. 
 
• We also plan to offer a “registry lock” service, designed to help protect participating registrants’ contact data from unauthorized modification, and against unauthorized domain transfers and deletions. Please see Questions 23 (“Registry Services”) for details. 

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

Our goal for .music is to create a trusted brand and secure name space for accredited members of the .music community. To achieve this, we will emphasize distribution channels internationally – not just in one or more focused regions. Our business plans call for focused outreach through our accredited community associations, who in connection with verifying registrant eligibility, may interact directly with ICANN-accredited registrars that have demonstrated their ability and willingness to adhere to the .music standards. As part of that relationship development, we will design our communication approach to initially target those accredited music associations seeking to work with registrars to distribute .music domains as potential resellers to their members. 

We anticipate that ICANNʹs outreach and communications program will benefit all new gTLDs. Media coverage about the availability of new TLDs will validate and reinforce our efforts. The more that members of the .music community understand that new TLDs are available, the faster they are likely to adopt our .music registrations and other new TLDs.

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

The dotMusic Registry will apply several mechanisms to provide a fair opportunity for potential registrants of the domain space while attempting to minimize related costs to IP holders of related strings.

As discussed in 18b iv, registrations methods will differ during the initial phases of the dotMusic Registry.

Phase 1 (Sunrise): Will be operated for a limited scheduled time period preceding Landrush and General Availability (90 days).

• Sunrise: Sunrise periods have evolved steadily over the past years during the launch of numerous TLDs such as .Info, .Biz, .Mobi, .Tel, .Me, .XXX and others. We intend to leverage what we have learned from these efforts to present a balanced approach that provides efficiencies for intellectual property (IP) holders, as well as a fair opportunity to register strings they believe apply to their IP. The dotMusic Registry will take applications during a time defined Sunrise period for all holders of internationally recognized filed trademarks or possibly holders of existing (legacy) gTLD domain strings that are a perfect match to the applied-for .music string as valid IP holders. These trademarks will be validated by a qualified 3rd party service provider (note: at this time it is unclear if this party must be an ICANN-named service provider related to the Trademark Clearinghouse but we will comply with any finalized requirement in this regard) and legacy gTLD strings must be verified as being held by the applicant prior to defined calendar date. Applicants will have to identify and declare their associative membership in an accredited music association, who will be informed of their declaration and given a defined time schedule. All these validations must be passed before the application is accepted. 
• Not knowing exactly how the Trademark Clearinghouse will be implemented, we envision being able to check Sunrise applications periodically against trademarks registered in the Trademark Clearinghouse. If a match is found, and the IP associated with the application is deemed valid, we anticipate being able to contact the party that registered the matching string in the Trademark Clearinghouse and inform them that there is a Sunrise application currently submitted that matches their string. This allows the IP holder to only participate in the Sunrise application process if there is an application against a string they have a recognized trademark against. 
• In the event there is more than one valid Sunrise application for a given string, the awarding will be determined by an auction process.

Phase 2: Operated during a scheduled time period preceding General Availability.

• Land Rush: Land Rush is designed to minimize speculation in a secondary domain marketplace and therefore reduce costs for registrants. During this period, non-IP related registration applications are accepted for a defined time period. In the event that there are multiple qualified .music applications for the same domain, the awarding of the string will be determined by an auction process. Community registration restrictions for potential registrants still apply. 

Phase 3: General Availability. 

After Land Rush is completed, we believe IP related and speculative registrations have been addressed with efforts to minimize the costs to potential registrants and provide a fair opportunity for registration. At this time it is appropriate to open the dotMusic Registry in its regular operating state, accepting live registrations on a first-come, first-serve basis; provided, however, that all prospective registrants must demonstrate their membership in an accredited music association

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

The focus of the dotMusic Registry is to create a trusted and protected namespace for the .music community. We will constantly analyse pricing in the TLD marketplace in consideration of providing .music registrants advantageous pricing, discounts⁄rebates or bulk registration discounts⁄rebates. We reserve the right to modify our pricing as market conditions dictate. 

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

We do not plan to make specific price escalation contractual commitments to our registrants. We believe that ultimately, our community market and the recognized value of our community compliance monitoring and enforcement will determine the viability of our pricing. Accordingly we intend to maintain the freedom to set pricing first, in accordance with any related ICANN and⁄or Registry Agreement criteria, and second, with the demands of what our community marketplace will bear. 

Yes

.MUSIC LLC was created with the express intent and purpose of serving a community established and known worldwide, which despite location, culture or genre, is identified and united by a single word: “music”. The .music TLD we envision is built on a commitment to foster musical creativity while protecting intellectual property rights. This commitment is evidenced via the bona fide support of the most representative, credible, diverse and sizeable organizations that comprise the global music community -- a community which is made up of the people who create music and the professionals that support them. The music community is dedicated to faithfully and concurrently meeting the needs of both “creators” and “consumers” of music alike.
The Global Music Community (GMC) is comprised of an international range of associations and organizations and the millions of individuals these organizations represent, all of whom are involved in the creation, development, publishing, recording, advocacy, promotion, distribution, education, preservation and or nurturing of the art of music.
To date, there are forty-two (42) clearly delineated, organized and pre-existing music community organizations that have provided individual written statements of support. This unparalleled level of global music community representation is referred to as the Charter Member Organizations of the Global Music Community (GMC). Collectively they represent over 4 million individual members within more than 1,000 associations in over 150 countries. Although these Charter Member Organizations are not the exhaustive list of every possible organizational member of the GMC, they do represent the largest, most well known, credible, and diverse membership of the GMC. Our application for .music is therefore designated as community based, and should be included in a community priority evaluation.
The structure of the music community is organized through diverse symbiotic and sometimes overlapping segments. Although the following list reflects core activities there is a great deal of community intersection and cross-pollination. The GMC structure can be generally illustrated by the following descriptive constituent categories:
Music Community organizations and associations whose principal focus is representing music creators, artists, songwriters, composers, publishers, record companies, and whose activities include product creation and development, promotion, distribution and the advocacy and protection of creative rights:
1. American Federation of Musicians in the U.S. and Canada (AFM)
2. American Association of Independent Music (A2IM)
3. Association of Independent Music (AIM)
4. Australian Recording Industry Association (ARIA)
5. Church Music Publishers Association (CMPA)
6. Guitar Foundation of America (GFA)
7. Indian Music Industry (IMI)
8. Independent Music Companies Association (IMPALA)
9. International Bluegrass Music Association (IBMA)
10. International Confederation of Music Publishers (ICMP)
11. International Federation of Musicians (FIM)
12. International Federation of Phonographic Industries (IFPI)
13. Music Canada
14. Music Publishers Association of the United States (MPA)
15. National Association of Recording Merchandisers⁄digitalmusic.org (NARM)
16. National Music Publishers Association (NMPA)
17. National Songwriters Association (NSA)
18. Phonographic Performance LTD (India)
19. Recording Industry Association of America (RIAA)
20. Songwriters Guild of America (SGA)
Music Community organizations and associations whose principal focus is the licensing, collection and distribution of fees for performance and mechanical rights:
21. Alliance of Artists and Recording Companies (AARC)
22. American Society of Composers, Authors and Publishers (ASCAP)
23. Australasian Mechanical Copyright Owners’ Society (AMCOS)
24. Australasian Performing Right Association (APRA)
25. Broadcast Music, Inc. (BMI)
26. Bureau International Des Societies Gerant Les Droits D’enregistrement et de Reproduction Mecanique (BIEM)
27. Indian Performing Right Society Limited (IPRS)
28. International Confederation of Authors and Composers Societies (CISAC)
29. PRS for Music (UK)
30. SESAC
31. Société d’Auteurs Belge – Belgische Auteurs Maatschappij (SABAM)
32. Société des Auteurs et Compositeurs de Musique (SACAM)
33. SoundExchange
Music Community organizations and associations, guilds, agencies and forums that provide a broad spectrum of professional support dedicated to, and from within, the music community:
34. Music Managers Forum (MMF) UK
35. Music Managers Forum (MMF) US
36. Music Producers Guild (MPG) UK⁄EU
37. National Association of Music Merchants (NAMM)
Music Community institutions, organizations, councils and associations who engage in the education, preservation, nurturing and advocacy of the music community that includes artistic, cultural and governmental institutions, national and international music councils and community outreach and advocacy organizations:
38. European Music Council (EMC)
39. National Music Council of the United States (NMC)
40. National Association for Music Education (NAfME)
41. International Music Council (IMC)
42. The Recording Academy (The GRAMMY Organization)
.MUSIC LLC is the only entity to receive the support and endorsement of the preceding music community organizations and associations in its application for the .music TLD. This unprecedented global demonstration of support from the Community is indicative of its unified political will and the strength of its belief that .music should be awarded to .MUSIC LLC.
Internet users, like the rest of us, engage in the discovery and enjoyment of music that has been created and made available by music makers and the professionals that support them. The differentiation between general Internet users and members of the music community are clearly delineated by two well defined-criteria. They are:
1. Active participation in the creation and development of music, its advocacy and promotion, its professional support, the protection and preservation of the music community’s creative rights, as well as the nurturing of the art through music education.
2. Current registration and verifiable membership in a global music community organization that was organized and in existence prior to 2007 (as per ICANN guidelines) who are active participants in the support and representation of the creation and development of music, its advocacy and promotion, its professional support, the protection and preservation of the music community’s creative rights, as well as the nurturing of the art through music education.
Music community associations date back to the 19th century. Our oldest Member Organization is the Société des Auteurs et Compositeurs de Musique, founded in 1860. In 1895, the Music Publishers Association of the United States was founded followed by the formation of the American Federation of Musicians in 1896. The 20th century witnessed the formation of the bulk of the organized music community. The 21st century ushered in the formation of the IMPALA in 2000, SoundExchange in 2003 and the American Association of Independent Music in 2005.
This community has been at the forefront of the creation, development, distribution, support, preservation, education and nurturing of music for more than a century - most recently culminating in their support for .MUSIC LLC’s application for the .music TLD as described in 20b.
The current addressable community membership is based on conservative calculations that take into account that some members may have memberships in several Member Organizations or national organizations that are also members of International or umbrella organizations. After adjusting for these factors, we estimate a current addressable community to be greater than four million unique members in more than 150 countries.

.MUSIC LLC has been at work obtaining the support of the of the Global Music Community (GMC) since 2008. Please see our answer to Q45 for details on our history and efforts from that date.
In 2011 .MUSIC LLC along with other potential applicants, expressed their interest in operating a .music TLD and reached out to several organizations, representing a broad cross section of the GMC, to garner their support and endorsement. These organizations, in turn, issued an extensive Request for Information (RFI) to solicit information from at least seven (7) potential applicants. The RFI asked for credentials, vision and specific plans to operate a .music TLD, including all aspects of registry operation, IP and trademark protection, and governance structure. All applicants presented their responses first in writing and then in person in New york City to a panel of senior-level executives of music organizations representing the global music community. Based on our proposed plans and policies, coupled with our long-standing professional involvement in the Community, .MUSIC LLC was the only entity selected to receive the collective support of these associations in its application for .music.
.MUSIC LLC’s ties to the music community are the result of decades of direct personal and professional involvment.
Loren Balman, .music’s CEO and John Styll, .music’s President are both members of The Recording Academy. Loren Balman is a member of the American Society of Composers, Authors and Publishers (ASCAP) as a songwriter and as a publisher. .MUSIC LLC is a member of the National Association of Recording Merchandisers. .MUSIC LLC’s Chairman Cal Turner also owns a music publishing company and has relationships with all three of the U.S. performance rights organizations: ASCAP, BMI and SESAC.
In addition .MUSIC LLC’s executive team has decades of professional experience in the music community. See executive bios below of each member of the executive team:
• Loren Balman, CEO, is a 30-year veteran of the music and entertainment business with diverse corporate experience. As a record label executive and by way of Artist Development, Marketing and Production, he has earned more than 30 Gold and Platinum records, a Grammy nomination and five Dove Awards.
• John Styll, President & COO, is an entrepreneur who founded a music magazine publishing company in 1978 and served as its CEO for 23 years. This experience in music journalism led to a seven-year stint as head of two music trade associations.
• John Frankenheimer, General Counsel, is Partner and Chairman Emeritus of the international entertainment and intellectual property law firm Loeb & Loeb. John has been at the epicenter of the music community as a trusted advisor to its leadership.
• Paul Zamek, VP of Global Community Development, is a veteran of the international music industry and native of South Africa. Paul has served as the US President⁄CEO of European Multimedia Group Inc. and as VP⁄General Manager of Capitol⁄EMI Records, South Africa.
• Keith Thomas, VP of Artist Relations, is a six-time Grammy-winning producer and songwriter with 40 Billboard #1 hits to his credit. Keith has worked with an elite spectrum of artists including Katy Perry, Vanessa Williams, Luther Vandross, Amy Grant, Jessica Simpson, Gladys Knight and many others.
Accountability mechanisms.
The dotMusic Registry will establish a Policy Advisory Board (PAB) before launch of the TLD. The role of the PAB will be part of the .MUSIC LLC’s contract with ICANN, the Registrar-Registry Agreement and the Registrant Agreement.
The PAB will be comprised of twenty-one (21) members representing the Charter Member Organizations of the Global Music Community. These representatives will serve on a voluntary basis and with for no more than two consecutive terms. As the organizational membership in the GMC grows, additional candidates will have the opportunity to be nominated and elected for subsequent terms.
The PAB is expected to collect input, provide insight and feedback on policies and procedure governing registration and accreditation criteria. Specifically, the PAB will oversee Registrant Accreditation Criteria and help evaluate enforcement mechanisms, including appeal procedures to ensure the protection of intellectual property rights in the .music TLD. Reasonable deference shall be given to the PAB with respect to issues dealing with the copyright protection and the promotion of non-infringing music alternatives, and reasonable deference shall be given to the dotMusic Registry concerning the technical, business and marketing operations of the TLD. They will also jointly determine a process by which policies would be reviewed, modified, or amended. These policies include, but are not limited to the following areas:
(a) Registrant qualifications;
(b) Community Organization⁄Association accreditation qualifications;
(c) Naming conventions for .music domain names;
(d) What activities may or may not be undertaken on web sites and through the use of other Internet resources associated with a .music domain name;
(e) What steps registrants will be required to take to warrant that all uses of music on their sites are fully licensed and legitimate.
(f) How policies will be enforced, including but not limited to enforcement through action upon complaints received; proactive compliance audits; suspension or termination of domain name registrations; and disqualification of parties from future participation in the .music TLD;
(g) Procedural rights and remedies of registrants and of interested third parties (e.g., copyright or related rights holders) in the enforcement and appeal process; including
i. Appeal process and procedures for registrants whose domain name was subject to suspension or deletion by the dotMusic Registry following audit, verification and enforcement procedures;
ii. Appeal process and procedure for registrars whose .music accreditation and subsequent Registry-Registrar contract was suspended or terminated by the dotMusic Registry following audit, verification and enforcement procedures;
(h) Policy terms and conditions under which registrars will be authorized to handle registrations in the .music TLD;
(i) All other policies substantially affecting the overarching goal of having the .music TLD as a venue for properly licensed music.
At the request of the PAB, The dotMusic Registry will provide an arbitration process, in the event the PAB believes the dotMusic Registry has not implemented the policies agreed to by the Registry and the PAB, or that the Registry has implemented a policy that does not reflect a consensus of the PAB. Both the dotMusic Registry and the PAB will be bound by the results of this arbitration.
Without prior review from the PAB, the dotMusic Registry will not seek a contract modification from ICANN regarding operation of the TLD; nor seek ICANN approval for a new registry service, as required by the .MUSIC LLC’s contract with ICANN.
The dotMusic Registry will brief the PAB quarterly regarding implementation and enforcement of its policies including but not limited to: 
(a) Complaints received of non-compliance, and timing and substance of actions taken in response to such complaints; 
(b) Results of pro-active compliance audits undertaken, and action taken by dotMusic Registry in response to audit findings; 
(c) Numbers and promptness of take-downs of infringing URL’s, infringing material, or suspensions or terminations of domain name registrations, (d) Overview and outcome of registrant and registrar appeal cases.
The dotMusic Registry will indemnify the members of the PAB for any claims arising from the authorized activities of the PAB, unless such activities violate ICANN policies or rules of law.

These following values are shared by all existing and potential Member Organizations of the GMC and serve as the community based purpose of the .music TLD :
o Support and encouragement for equal access to musical education
o Support and respect for all who express themselves musically
o Support for the right for universal participation
o Support for musical artists to develop their artistry and communicate through all media, and all distribution channels at their disposal
o Preservation of the global musical heritage
o Support the right for music creators to obtain fair recognition and remuneration for their work.
o Commitment to universal protection of creative and intellectual property rights.
The .music TLD is intended to serve the interests of the global community of individuals and organizations engaged in the creation, development, distribution, and promotion of music, as well as the education of musicians and audiences alike. The creation of .music will enable a unique but encompassing identifier for the collective community of artists, musicians, songwriters, teachers, and the professionals who support them with a shared commitment to fostering musical creativity and the protection of intellectual property rights. The .music TLD will enact policies and procedures to protect, safeguard, nurture and promote the interests of the music community. Protective policies and procedures would inhibit abusive practices such as copyright infringement resulting from peer to peer (P2P) sharing, illegal digital distribution, and any type of Intellectual Property infringement involving the DNS. Doing so helps to ensure the financial viability of the artist and⁄or intellectual property owner. The music community cannot be sustained without protecting the value of its creation.
Registration policies will safeguard the exclusive nature of the community by requiring potential registrants to have a bona fide membership with an at least one Organization Member of Global Music Community, before they can acquire a .music address. This helps examine and affirm the motivation of the registrant, since all community member organizations must meet qualifications that support the communities shared values.
The dotMusic Registry will nurture music by funding education endowments, as well as providing the GMC member associations with an additional source of revenue. The dotMusic Registry will create a .music Foundation and contribute $1 for every domain registration sold at full wholesale price. This fund would be administered by the dotMusic Registry’s Policy Advisory Board who will determine the recipients of the endowment. These funds may be distributed to support music education, creative and intellectual property rights protection, music community benevolence organizations, or other music related financial aid. Member Organizations of the Global Music Community will also be able to sell second-level .music domain names as domain name resellers. Those resellers who opt to use .music’s Application Programming Interface (API) will receive shared revenue for each registration that comes from within their membership through the integrated API system.
Our ultimate purpose is to sustain the art of music so that more and more people can enjoy music.

Q20(d) Explain the relationship between the applied for gTLD to the community identified in qQ20 (a). Explanations should clearly state:
• relationships to the established name, if any, of the community
An often-cited definition of music, coined by Edgard Varèse (http:⁄⁄en.wikipedia.org⁄wiki⁄Edgard_Var%C3%A8se) is that it is ʺorganized soundʺ (Goldman 1961, 133). The fifteenth edition of the Encyclopedia Britannica explains, ʺwhile there are no sounds that can be described as inherently unmusical, musicians in each culture have tended to restrict the range of sounds they will admit.ʺ
Webster’s defines music as “the science or art of ordering tones or sounds in succession, in combination, and in temporal relationships to produce a composition having unity and continuity“ (Websterʹs Collegiate Dictionary, online edition).
Therefore a human element in creating, organizing, or labeling something as music is crucial to the common understanding of music. Furthermore both the notion of science and art, require human participation or initiation. This would not only disqualify sounds, such as those produced by nature (these sounds are often described by the adjective “musical” but rarely the noun “music”), but also draws a direct connection to the human based and recognizable community responsible for its creation, production, instrumentation, promotion and education.
The global community of music makers, educators, advocates, and professionals described as the Music Community, have a single identifying label that unites them all, despite location, culture, or specialty. That nexus is one and only one simple word: “Music”.
Therefore the choice of “music” as a string is important, since the “.music” TLD will extend this common link into a common platform to, promote the musical identity of artists, musicians, songwriters and the professionals that support them, as well as music educators, music advocates and policy makers through a relevant and shared website and email address suffix.
• relationship to the identification of community members
Every member organization⁄association, and their membership in turn, identifies their primary purpose to be directly related to either the science or the art of “music”. There is no other term for which the songwriters, composers, performers, singers, instrument makers, music promoters, producers and owners can all relate to as their common descriptor.
The people who create, write, record, perform, develop, teach, preserve, nurture, promote, distribute and sell music, think of themselves as members of the music community. “Music” is the one tribal identity that is global.
• any connotations the string may have beyond the community
The term or string “music” is also relevant for the consumers or fans of music. Although the music lover or consumer is not defined as part of the Global Music Community, they DO share a common bond: a passion for music. The music lovers and consumers are very much a sustaining force and the “raison d’etre” for the Global Music Community.
As mentioned before in our answer to Question 18, for far too long the interests of the creators were assumed to be at odds with the interests of the consumers. We note that not only do both have something crucial in common: a passion for music, but also they have a symbiotic relationship. One cannot exist with out the other. So although we acknowledge that our definition of the music community does not have individual consumers of music (unless they belong to one of the Member Organizations of the Global Music Community) we are adamant that everything we do, is ultimately so that more and more people can enjoy music and thus foster its development and growth.

e) Please provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD.
The .music TLD will be a restricted domain space where second level .music domain names can be registered by eligible individuals, businesses and not-for-profit entities all around the globe. The following policies and mechanisms will be used to ensure support of the community-based purpose of the .music TLD:
1. Music Association⁄Organization membership:
Potential domain registrants must be members of or affiliated with at least one Member Organization of the Global Music Community. Domain registrations may be accepted, but will not resolve until the registrant’s membership credentials have been verified. This will require verification of relevant membership data during the registration process. This membership will be crosschecked with the relevant Member Organization. Verification of continued membership is required for renewal, to ensure ongoing eligibility.
2. Registrant Agreement:
Presented during the registration process, this agreement will require registrant compliance with the dotMusic Registry rules and Acceptable Use Policy (for details see Q28).
3. Qualified Registrars and Member based Resellers:
.music domains will only be available via ICANN accredited registrars (and their resellers) with demonstrated technical capability who have agreed to comply with .music’s Registry⁄Registrar Agreement. In order to ensure strict compliance with .music policy and offer the greatest opportunities to our community, the dotMusic registry will encourage Member Organizations of the GMC to become accredited resellers
In addition, .music will operate as a global registry from inception. Formatting flexibility is required to accommodate bandwidth constraints that may be experienced in the developing world. Accordingly, the dotMusic Registry will not mandate any particular formatting or usage.
Reserved Names:
dotMusic Registry will reserve the following classes of domain names, which will not be available to registrants via the Sunrise or subsequent periods:
• The reserved names required in Specification 5 of the new gTLD Registry Agreement.
• The geographic names required in Specification 5 of the new gTLD Registry Agreement, and as per our response to Question 21. See our response to Question 22 (“Protection of Geographic Names”) for details.
• The registry operator will reserve its own name and variations thereof, and registry operations names (such as nic.music, and registry.music,), so that we can point them to our Web site. Reservation of the registry operator’s names was standard in ICANN’s past gTLD contracts.
• We will also reserve names related to ICANN and Internet standards bodies (iana.music, ietf.music, www.music, etc.), for delegation of those names to the relevant organizations upon their request. Reservation of this type of name was standard in ICANN’s past gTLD contracts.
The list of reserved names will be public prior to the launch of the Sunrise period.
Premium Names:
• The dotMusic Registry will also designate a set of “premium names,” which will be set aside for distribution via special mechanisms. Premium names have been a standard feature of TLD rollouts since 2005. The list of premium names will be public prior to the launch of the Sunrise period.
• Premium names will be distributed by application only. Applicants would be required to describe how the intended use of a given premium name will result in demonstrable benefits to the .music community. The policies and procedures for receipt, review, and award of premium name applications will be based on input from the PAB and will be posted on the dotMusic Registry web site in advance. The rules to ensure transparency, integrity and in the distribution of names, include but are not limited to:
a. Strict prohibition of all employees of the dotMusic Registry operator, and its contractors, against bidding in auctions or having any ownership or interest in a premium name applicant.
b. Use of the Trademark Clearinghouse during General Availability (Trademark Claims Service) for an additional 60 days, for notifications of new registrations only where the string is a complete match with a filing in the Trademark Clearinghouse.
Dispute Resolution Mechanisms:
• Registrants and rights holders will have access to several dispute mechanisms. These are fair and transparent processes to adjudicate claims to domain names, and they also protect registrants against reverse domain hijacking.
• Names registered in the Sunrise Period will be subject to a Sunrise Dispute Policy. This policy and procedure will be in effect for a finite time period, to provide special protection of qualified trademark rights. Please see our response to Question 29 (“Rights Protection Mechanisms”) for full details.
• As required by ICANN, .music domains will be subject to the Uniform Dispute Resolution Policy (UDRP). Please see our response to Question 29 (“Rights Protection Mechanisms”) for full details.
• As required by ICANN, .music domains will also be subject to the Universal Rapid Suspension (URS) policy. Please see our answer to Question 29 (“Rights Protection Mechanisms”) for full details.
• We will provision systems to take in and administrate cases as per ICANN’s Registrar Transfer Dispute Resolutions Policy (http:⁄⁄www.icann.org⁄en⁄transfers⁄dispute-policy-12jul04.htm). This process will allow registrars to protect registrants by filing disputes about inter-registrar transfers that they believe were unauthorized or improperly executed.
• MEDRP: .music will support the Music Eligibility Dispute Resolution Procedure. This dispute mechanism will be available to members of the .music community and end-users to file claims against registrants of the .music domain for violations of the .music eligibility and use community rules and policies. We will select an adjudication service from the list of ICANN approved arbitrators to facilitate MEDRP claims (please see Q28 and Q29 for further details).
Eligibility: who is eligible to register a second-level name in the gTLD, and how will eligibility be determined.
- Potential domain registrants must be members of or affiliated with at least one Member Organizations of the Global Music Community. Domain registrations may be accepted, but will not resolve until the registrant’s membership credentials have been verified. Please see the “Proposed .music Registration Process” attachment in our answer to Q48 for a step-by-step visual depiction of the process. Should the registrant fail to meet the eligibility criteria, they risk the suspension and ultimately deletion or loss of their domain name. Verification of continued membership is required for renewal, to ensure ongoing eligibility.
Name selection: what types of second-level names may be registered in the gTLD.
- Please see the Reserve Name policy detailed above. Beyond these, eligible registrants may register domains in compliance with the Registrant Agreement and its Acceptable Use Policy.
Content⁄Use: what restrictions, if any, the registry operator will impose on how a registrant may use its registered name.
- Registrants must hold valid rights to all materials displayed on and⁄or distributed through their specific site. Please see Q28 for details on .music’s Acceptable Use Policy. The dotMusic registry will be regularly monitored potential violations and also provide a robust abuse reporting process for such violations noticed by others. Should the registrant be found in violation, they risk the suspension and ultimately deletion or loss of their domain name.
Enforcement: what investigation practices and mechanisms exist to enforce the policies above, what resources are allocated for enforcement, and what appeal mechanisms are available to registrants.
- The .music Registry⁄Registrar and the Registrant Agreements will include extensive monitoring, enforcement (up to and including take downs) as well as appeal provisions.
Monitoring
o The .music TLD will be monitored by online scanning tools such as those that search for keywords that are commonly used to identify the availability of music distributed without appropriate authorization or in violation of intellectual property rights. Suspected abuse from such automated search tools will flag an analyst from our abuse team (see Q28) who will then access and review the website to confirm the abuse. Neustar will enable .music analysts to suspend domain names as required.
o The dotMusic Registry will also use Abuse Mitigation Services to monitor, detect and mitigate domain name abuses (se Q29)
Enforcement and Appeal
o Registrants in violation of the Registrant Agreement risk the suspension and ultimately deletion or loss of their domain name.
o As detailed in our answer to Q28, failure to comply with the Registry⁄Registrar agreement will result in loss or revocation of registrar accreditation.
o The dotMusic Registry will use standard dispute mechanisms (see Q28 and Q29), such as UDRP, URS etc. However, in the case of serious allegations of failure to meet community member eligibility requirements, we have created a MEDRP (Music Community Eligibility Dispute Resolution Procedure). This dispute mechanism will be arbitrated by a third party approved by ICANN such as WIPO and will be binding on all parties (provisions will be named in the Registrant Agreement). Disputes may be initiated by community members or end-users; however, there will be reasonable limitations developed on the filing of disputes to prevent abuse of the mechanism. Please see our answer to Q20(b) under “Accountability mechanisms of the applicant to the community” for additional details on appeal procedures.

Not Available

No

Specification 5 of the New gTLD Registry Agreement requires the registry operator reserve all geographic names at the second level as well as any subordinate levels for which the operator controls and issues registrations. As per the draft registry agreement “the country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations”:

 
5.1)

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 toany application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166--1_decoding_table.htm#EU〉;

5.2)

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

5.3)

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;

Release of Geographic Names at the second or subordinate level (where managed and issued by the Registry Operator):

The dotMusic Registry has no current or immediate plans to release any of the aforementioned reserved geographic domains. The dotMusic Registry commits to, in the event this intention changes in the future, first develop agreements with the applicable governments affected by any proposed release, then bring said agreements and a full plan for the release of said geographic names to the Governmental Advisory Committee and ICANN for their approval. 

23.1 Introduction 



.MUSIC LLC has elected to partner with NeuStar, Inc (Neustar) to provide back-end services for the .music registry. In making this decision, .MUSIC LLC recognized that Neustar already possesses a production-proven registry system that can be quickly deployed and smoothly operated over its robust, flexible, and scalable world-class infrastructure. The existing registry services will be leveraged for the .music registry. The following section describes the registry services to be provided.



23.2 Standard Technical and Business Components



Neustar will provide the highest level of service while delivering a secure, stable and comprehensive registry platform. .MUSIC LLC will use Neustarʹs Registry Services platform to deploy the .music registry, by providing the following Registry Services (none of these services are offered in a manner that is unique to .music): 



-Registry-Registrar Shared Registration Service (SRS)

-Extensible Provisioning Protocol (EPP)

-Domain Name System (DNS)

-WHOIS

-DNSSEC

-Data Escrow

-Dissemination of Zone Files using Dynamic Updates

-Access to Bulk Zone Files

-Dynamic WHOIS Updates

-IPv6 Support

-Rights Protection Mechanisms



The following is a description of each of the services. 



23.2.1 SRS 



Neustarʹs secure and stable SRS is a production-proven, standards-based, highly reliable, and high-performance domain name registration and management system. The SRS includes an EPP interface for receiving data from registrars for the purpose of provisioning and managing domain names and name servers. The response to Question 24 provides specific SRS information. 



23.2.2 EPP



The .music registry will use the Extensible Provisioning Protocol (EPP) for the provisioning of domain names. The EPP implementation will be fully compliant with all RFCs. Registrars are provided with access via an EPP API and an EPP based Web GUI. With more than 10 gTLD, ccTLD, and private TLDs implementations, Neustar has extensive experience building EPP-based registries. Additional discussion on the EPP approach is presented in the response to Question 25.



23.2.3 DNS



.MUSIC LLC will leverage Neustarʹs world-class DNS network of geographically distributed nameserver sites to provide the highest level of DNS service. The service utilizes Anycast routing technology, and supports both IPv4 and IPv6. The DNS network is highly proven, and currently provides service to over 20 TLDs and thousands of enterprise companies. Additional information on the DNS solution is presented in the response to Questions 35.



23.2.4 WHOIS



Neustarʹs existing standard WHOIS solution will be used for the .music. The service provides supports for near real-time dynamic updates. The design and construction is agnostic with regard to data display policy is flexible enough to accommodate any data model. In addition, a searchable WHOIS service that complies with all ICANN requirements will be provided. The following WHOIS options will be provided:



Standard WHOIS (Port 43)

Standard WHOIS (Web)

Searchable WHOIS (Web)



23.2.5 DNSSEC



An RFC compliant DNSSEC implementation will be provided using existing DNSSEC capabilities. Neustar is an experienced provider of DNSSEC services, and currently manages signed zones for three large top level domains: .biz, .us, and .co. Registrars are provided with the ability to submit and manage DS records using EPP, or through a web GUI. Additional information on DNSSEC, including the management of security extensions is found in the response to Question 43.



23.2.6 Data Escrow



Data escrow will be performed in compliance with all ICANN requirements in conjunction with an approved data escrow provider. The data escrow service will:



-Protect against data loss

-Follow industry best practices

-Ensure easy, accurate, and timely retrieval and restore capability in the event of a hardware failure

-Minimizes the impact of software or business failure.



Additional information on the Data Escrow service is provided in the response to Question 38.



23.2.7 Dissemination of Zone Files using Dynamic Updates



Dissemination of zone files will be provided through a dynamic, near real-time process. Updates will be performed within the specified performance levels. The proven technology ensures that updates pushed to all nodes within a few minutes of the changes being received by the SRS. Additional information on the DNS updates may be found in the response to Question 35.



23.2.8 Access to Bulk Zone Files



.MUSIC LLC will provide third party access to the bulk zone file in accordance with specification 4, Section 2 of the Registry Agreement. Credentialing and dissemination of the zone files will be facilitated through the Central Zone Data Access Provider.



23.2.9 Dynamic WHOIS Updates



Updates to records in the WHOIS database will be provided via dynamic, near real-time updates. Guaranteed delivery message oriented middleware is used to ensure each individual WHOIS server is refreshed with dynamic updates. This component ensures that all WHOIS servers are kept current as changes occur in the SRS, while also decoupling WHOIS from the SRS. Additional information on WHOIS updates is presented in response to Question 26.



23.2.10 IPv6 Support



The .music registry will provide IPv6 support in the following registry services: SRS, WHOIS, and DNS⁄DNSSEC. In addition, the registry supports the provisioning of IPv6 AAAA records. A detailed description on IPv6 is presented in the response to Question 36.



23.2.11 Required Rights Protection Mechanisms



.MUSIC LLC, will provide all ICANN required Rights Mechanisms, including: 



-Trademark Claims Service

-Trademark Post-Delegation Dispute Resolution Procedure (PDDRP)

-Registration Restriction Dispute Resolution Procedure (RRDRP)

-UDRP

-URS

-Sunrise service.

More information is presented in the response to Question 29.



23.2.12 Internationalized Domain Names (IDN)



IDN registrations are provided in full compliance with the IDNA protocol. Neustar possesses extensive experience offering IDN registrations in numerous TLDs, and its IDN implementation uses advanced technology to accommodate the unique bundling needs of certain languages. Character mappings are easily constructed to block out characters that may be deemed as confusing to users..



23.3 Unique Services 



.MUSIC LLC will not be offering services that are unique to .music.



23.4 Security or Stability Concerns 



All services offered are standard registry services that have no known security or stability concerns. Neustar has demonstrated a strong track record of security and stability within the industry. 

24.1 Introduction



.MUSIC LLC has partnered with NeuStar, Inc (ʺNeustarʺ), an experienced TLD registry operator, for the operation of the .music Registry. The applicant is confident that the plan in place for the operation of a robust and reliable Shared Registration System (SRS) as currently provided by Neustar will satisfy the criterion established by ICANN.



Neustar built its SRS from the ground up as an EPP based platform and has been operating it reliably and at scale since 2001. The software currently provides registry services to five TLDs (.BIZ, .US, TEL, .CO and .TRAVEL) and is used to provide gateway services to the .CN and .TW registries. Neustarʹs state of the art registry has a proven track record of being secure, stable, and robust. It manages more than 6 million domains, and has over 300 registrars connected today. 

The following describes a detailed plan for a robust and reliable SRS that meets all ICANN requirements including compliance with Specifications 6 and 10.



24.2 The Plan for Operation of a Robust and Reliable SRS



24.2.1 High-level SRS System Description



The SRS to be used for .music will leverage a production-proven, standards-based, highly reliable and high-performance domain name registration and management system that fully meets or exceeds the requirements as identified in the new gTLD Application Guidebook. 



The SRS is the central component of any registry implementation and its quality, reliability and capabilities are essential to the overall stability of the TLD. Neustar has a documented history of deploying SRS implementations with proven and verifiable performance, reliability and availability. The SRS adheres to all industry standards and protocols. By leveraging an existing SRS platform, .MUSIC LLC is mitigating the significant risks and costs associated with the development of a new system. Highlights of the SRS include:



-State-of-the-art, production proven multi-layer design

-Ability to rapidly and easily scale from low to high volume as a TLD grows

-Fully redundant architecture at two sites

-Support for IDN registrations in compliance with all standards 

-Use by over 300 Registrars

-EPP connectivity over IPv6

-Performance being measured using 100% of all production transactions (not sampling).



24.2.2 SRS Systems, Software, Hardware, and Interoperability 



The systems and software that the registry operates on are a critical element to providing a high quality of service. If the systems are of poor quality, if they are difficult to maintain and operate, or if the registry personnel are unfamiliar with them, the registry will be prone to outages. Neustar has a decade of experience operating registry infrastructure to extremely high service level requirements. The infrastructure is designed using best of breed systems and software. Much of the application software that performs registry-specific operations was developed by the current engineering team and a result the team is intimately familiar with its operations.



The architecture is highly scalable and provides the same high level of availability and performance as volumes increase. It combines load balancing technology with scalable server technology to provide a cost effective and efficient method for scaling.



The Registry is able to limit the ability of any one registrar from adversely impacting other registrars by consuming too many resources due to excessive EPP transactions. The system uses network layer 2 level packet shaping to limit the number of simultaneous connections registrars can open to the protocol layer.



All interaction with the Registry is recorded in log files. Log files are generated at each layer of the system. These log files record at a minimum:



-The IP address of the client

-Timestamp

-Transaction Details

-Processing Time.



In addition to logging of each and every transaction with the SRS Neustar maintains audit records, in the database, of all transformational transactions. These audit records allow the Registry, in support of the applicant, to produce a complete history of changes for any domain name.



24.2.3 SRS Design



The SRS incorporates a multi-layer architecture that is designed to mitigate risks and easily scale as volumes increase. The three layers of the SRS are:



-Protocol Layer

-Business Policy Layer

-Database. 



Each of the layers is described below. 



24.2.4 Protocol Layer



The first layer is the protocol layer, which includes the EPP interface to registrars. It consists of a high availability farm of load-balanced EPP servers. The servers are designed to be fast processors of transactions. The servers perform basic validations and then feed information to the business policy engines as described below. The protocol layer is horizontally scalable as dictated by volume.



The EPP servers authenticate against a series of security controls before granting service, as follows:



-The registrarʹs host exchanges keys to initiates a TLS handshake session with the EPP server.

-The registrarʹs host must provide credentials to determine proper access levels.

-The registrarʹs IP address must be preregistered in the network firewalls and traffic-shapers.



24.2.5 Business Policy Layer 



The Business Policy Layer is the brain of the registry system. Within this layer, the policy engine servers perform rules-based processing as defined through configurable attributes. This process takes individual transactions, applies various validation and policy rules, persists data and dispatches notification through the central database in order to publish to various external systems. External systems fed by the Business Policy Layer include backend processes such as dynamic update of DNS, WHOIS and Billing. 



Similar to the EPP protocol farm, the SRS consists of a farm of application servers within this layer. This design ensures that there is sufficient capacity to process every transaction in a manner that meets or exceeds all service level requirements. Some registries couple the business logic layer directly in the protocol layer or within the database. This architecture limits the ability to scale the registry. Using a decoupled architecture enables the load to be distributed among farms of inexpensive servers that can be scaled up or down as demand changes.



The SRS today processes over 30 million EPP transactions daily. 



24.2.6 Database



The database is the third core components of the SRS. The primary function of the SRS database is to provide highly reliable, persistent storage for all registry information required for domain registration services. The database is highly secure, with access limited to transactions from authenticated registrars, trusted application-server processes, and highly restricted access by the registry database administrators. A full description of the database can be found in response to Question 33.



Figure 24-1 attached depicts the overall SRS architecture including network components.



24.2.7 Number of Servers



As depicted in the SRS architecture diagram above Neustar operates a high availability architecture where at each level of the stack there are no single points of failures. Each of the network level devices run with dual pairs as do the databases. For the .music registry, the SRS will operate with 8 protocol servers and 6 policy engine servers. These expand horizontally as volume increases due to additional TLDs, increased load, and through organic growth. In addition to the SRS servers described above, there are multiple backend servers for services such as DNS and WHOIS. These are discussed in detail within those respective response sections. 



24.2.8 Description of Interconnectivity with Other Registry Systems



The core SRS service interfaces with other external systems via Neustarʹs external systems layer. The services that the SRS interfaces with include:



-WHOIS 

-DNS 

-Billing

-Data Warehouse (Reporting and Data Escrow).

 

Other external interfaces may be deployed to meet the unique needs of a TLD. At this time there are no additional interfaces planned for .music.



The SRS includes an external notifier concept in its business policy engine as a message dispatcher. This design allows time-consuming backend processing to be decoupled from critical online registrar transactions. Using an external notifier solution, the registry can utilize control levers that allow it to tune or to disable processes to ensure optimal performance at all times. For example, during the early minutes of a TLD launch, when unusually high volumes of transactions are expected, the registry can elect to suspend processing of one or more back end systems in order to ensure that greater processing power is available to handle the increased load requirements. This proven architecture has been used with numerous TLD launches, some of which have involved the processing of over tens of millions of transactions in the opening hours. The following are the standard three external notifiers used the SRS: 



24.2.9 WHOIS External Notifier



The WHOIS external notifier dispatches a work item for any EPP transaction that may potentially have an impact on WHOIS. It is important to note that, while the WHOIS external notifier feeds the WHOIS system, it intentionally does not have visibility into the actual contents of the WHOIS system. The WHOIS external notifier serves just as a tool to send a signal to the WHOIS system that a change is ready to occur. The WHOIS system possesses the intelligence and data visibility to know exactly what needs to change in WHOIS. See response to Question 26 for greater detail.



24.2.10 DNS External Notifier



The DNS external notifier dispatches a work item for any EPP transaction that may potentially have an impact on DNS. Like the WHOIS external notifier, the DNS external notifier does not have visibility into the actual contents of the DNS zones. The work items that are generated by the notifier indicate to the dynamic DNS update sub-system that a change occurred that may impact DNS. That DNS system has the ability to decide what actual changes must be propagated out to the DNS constellation. See response to Question 35 for greater detail.



24.2.11 Billing External Notifier



The billing external notifier is responsible for sending all billable transactions to the downstream financial systems for billing and collection. This external notifier contains the necessary logic to determine what types of transactions are billable. The financial systems use this information to apply appropriate debits and credits based on registrar.



24.2.12 Data Warehouse



The data warehouse is responsible for managing reporting services, including registrar reports, business intelligence dashboards, and the processing of data escrow files. The Reporting Database is used to create both internal and external reports, primarily to support registrar billing and contractual reporting requirement. The data warehouse databases are updated on a daily basis with full copies of the production SRS data. 



24.2.13 Frequency of Synchronization between Servers



The external notifiers discussed above perform updates in near real-time, well within the prescribed service level requirements. As transactions from registrars update the core SRS, update notifications are pushed to the external systems such as DNS and WHOIS. These updates are typically live in the external system within 2-3 minutes.



24.2.14 Synchronization Scheme (e.g., hot standby, cold standby) 



Neustar operates two hot databases within the data center that is operating in primary mode. These two databases are kept in sync via synchronous replication. Additionally, there are two databases in the secondary data center. These databases are updated real time through asynchronous replication. This model allows for high performance while also ensuring protection of data. See response to Question 33 for greater detail. 



24.2.15 Compliance with Specification 6 Section 1.2



The SRS implementation for .music is fully compliant with Specification 6, including section 1.2. EPP Standards are described and embodied in a number of IETF RFCs, ICANN contracts and practices, and registry-registrar agreements. Extensible Provisioning Protocol or EPP is defined by a core set of RFCs that standardize the interface that make up the registry-registrar model. The SRS interface supports EPP 1.0 as defined in the following RFCs shown in Table 24-1 attached. 



Additional information on the EPP implementation and compliance with RFCs can be found in the response to Question 25.



24.2.16 Compliance with Specification 10



Specification 10 of the New TLD Agreement defines the performance specifications of the TLD, including service level requirements related to DNS, RDDS (WHOIS), and EPP. The requirements include both availability and transaction response time measurements. As an experienced registry operator, Neustar has a long and verifiable track record of providing registry services that consistently exceed the performance specifications stipulated in ICANN agreements. This same high level of service will be provided for the .music Registry. The following section describes Neustarʹs experience and its capabilities to meet the requirements in the new agreement.



To properly measure the technical performance and progress of TLDs, Neustar collects data on key essential operating metrics. These measurements are key indicators of the performance and health of the registry. Neustarʹs current .biz SLA commitments are among the most stringent in the industry today, and exceed the requirements for new TLDs. Table 24-2 compares the current SRS performance levels compared to the requirements for new TLDs, and clearly demonstrates the ability of the SRS to exceed those requirements.



Their ability to commit and meet such high performance standards is a direct result of their philosophy towards operational excellence. See response to Question 31 for a full description of their philosophy for building and managing for performance.



24.3 Resourcing Plans 



The development, customization, and on-going support of the SRS are the responsibility of a combination of technical and operational teams, including:



-Development⁄Engineering

-Database Administration

-Systems Administration

-Network Engineering.



Additionally, if customization or modifications are required, the Product Management and Quality Assurance teams will be involved in the design and testing. Finally, the Network Operations and Information Security play an important role in ensuring the systems involved are operating securely and reliably.



The necessary resources will be pulled from the pool of operational resources described in detail in the response to Question 31. Neustarʹs SRS implementation is very mature, and has been in production for over 10 years. As such, very little new development related to the SRS will be required for the implementation of the .music registry. The following resources are available from those teams:



-Development⁄Engineering 19 employees

-Database Administration- 10 employees

-Systems Administration 24 employees

-Network Engineering 5 employees



The resources are more than adequate to support the SRS needs of all the TLDs operated by Neustar, including the .music registry. 

25.1 Introduction



.MUSIC LLCʹs back-end registry operator, Neustar, has over 10 years of experience operating EPP based registries. They deployed one of the first EPP registries in 2001 with the launch of .biz. In 2004, they were the first gTLD to implement EPP 1.0. Over the last ten years Neustar has implemented numerous extensions to meet various unique TLD requirements. Neustar will leverage its extensive experience to ensure .MUSIC LLC is provided with an unparalleled EPP based registry. The following discussion explains the EPP interface which will be used for the .music registry. This interface exists within the protocol farm layer as described in Question 24 and is depicted in Figure 25-1 attached.



25.2 EPP Interface



Registrars are provided with two different interfaces for interacting with the registry. Both are EPP based, and both contain all the functionality necessary to provision and manage domain names. The primary mechanism is an EPP interface to connect directly with the registry. This is the interface registrars will use for most of their interactions with the registry. 



However, an alternative web GUI (Registry Administration Tool) that can also be used to perform EPP transactions will be provided. The primary use of the Registry Administration Tool is for performing administrative or customer support tasks. 

The main features of the EPP implementation are: 



-Standards Compliance: The EPP XML interface is compliant to the EPP RFCs. As future EPP RFCs are published or existing RFCs are updated, Neustar makes changes to the implementation keeping in mind of any backward compatibility issues.



-Scalability: The system is deployed keeping in mind that it may be required to grow and shrink the footprint of the Registry system for a particular TLD. 



-Fault-tolerance: The EPP servers are deployed in two geographically separate data centers to provide for quick failover capability in case of a major outage in a particular data center. The EPP servers adhere to strict availability requirements defined in the SLAs.



-Configurability: The EPP extensions are built in a way that they can be easily configured to turn on or off for a particular TLD.



-Extensibility: The software is built ground up using object oriented design. This allows for easy extensibility of the software without risking the possibility of the change rippling through the whole application. 



-Auditable: The system stores detailed information about EPP transactions from provisioning to DNS and WHOIS publishing. In case of a dispute regarding a name registration, the Registry can provide comprehensive audit information on EPP transactions.



-Security: The system provides IP address based access control, client credential-based authorization test, digital certificate exchange, and connection limiting to the protocol layer. 



25.3 Compliance with RFCs and Specifications



The registry-registrar model is described and embodied in a number of IETF RFCs, ICANN contracts and practices, and registry-registrar agreements. As shown in Table 25-1 attached, EPP is defined by the core set of RFCs that standardize the interface that registrars use to provision domains with the SRS. As a core component of the SRS architecture, the implementation is fully compliant with all EPP RFCs. 



Neustar ensures compliance with all RFCs through a variety of processes and procedures. Members from the engineering and standards teams actively monitor and participate in the development of RFCs that impact the registry services, including those related to EPP. When new RFCs are introduced or existing ones are updated, the team performs a full compliance review of each system impacted by the change. Furthermore, all code releases include a full regression test that includes specific test cases to verify RFC compliance.



Neustar has a long history of providing exceptional service that exceeds all performance specifications. The SRS and EPP interface have been designed to exceed the EPP specifications defined in Specification 10 of the Registry Agreement and profiled in Table 25-2 attached. Evidence of Neustarʹs ability to perform at these levels can be found in the .biz monthly progress reports found on the ICANN website.



25.3.1 EPP Toolkits



Toolkits, under open source licensing, are freely provided to registrars for interfacing with the SRS. Both Java and C++ toolkits will be provided, along with the accompanying documentation. The Registrar Tool Kit (RTK) is a software development kit (SDK) that supports the development of a registrar software system for registering domain names in the registry using EPP. The SDK consists of software and documentation as described below.



The software consists of working Java and C++ EPP common APIs and samples that implement the EPP core functions and EPP extensions used to communicate between the registry and registrar. The RTK illustrates how XML requests (registration events) can be assembled and forwarded to the registry for processing. The software provides the registrar with the basis for a reference implementation that conforms to the EPP registry-registrar protocol. The software component of the SDK also includes XML schema definition files for all Registry EPP objects and EPP object extensions. The RTK also includes a dummy server to aid in the testing of EPP clients.



The accompanying documentation describes the EPP software package hierarchy, the object data model, and the defined objects and methods (including calling parameter lists and expected response behavior). New versions of the RTK are made available from time to time to provide support for additional features as they become available and support for other platforms and languages.



25.4 Proprietary EPP Extensions



The .music registry will not include proprietary EPP extensions. Neustar has implemented various EPP extensions for both internal and external use in other TLD registries. These extensions use the standard EPP extension framework described in RFC 5730. Table 25-3 attached provides a list of extensions developed for other TLDs. Should the .music registry require an EPP extension at some point in the future, the extension will be implemented in compliance with all RFC specifications including RFC 3735.



The full EPP schema to be used in the .music registry is attached in the document titled EPP Schema Files.



25.5 Resourcing Plans



The development and support of EPP is largely the responsibility of the Development⁄Engineering and Quality Assurance teams. As an experience registry operator with a fully developed EPP solution, on-going support is largely limited to periodic updates to the standard and the implementation of TLD specific extensions.



The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31. The following resources are available from those teams:



-Development⁄Engineering 19 employees

-Quality Assurance - 7 employees.



These resources are more than adequate to support any EPP modification needs of the .music registry.

26.1 Introduction



.MUSIC LLC recognizes the importance of an accurate, reliable, and up-to-date WHOIS database to governments, law enforcement, intellectual property holders and the public as a whole and is firmly committed to complying with all of the applicable WHOIS specifications for data objects, bulk access, and lookups as defined in Specifications 4 and 10 to the Registry Agreement. .musicʹs back-end registry services provider, Neustar, has extensive experience providing ICANN and RFC-compliant WHOIS services for each of the TLDs that it operates both as a Registry Operator for gTLDs, ccTLDs and back-end registry services provider. As one of the first thick registry operators in the gTLD space, Neustarʹs WHOIS service has been designed from the ground up to display as much information as required by a TLD and respond to a very stringent availability and performance requirement.



Some of the key features of .musicʹs solution include: 



-Fully compliant with all relevant RFCs including 3912



-Production proven, highly flexible, and scalable with a track record of 100% availability over the past 10 years



-Exceeds current and proposed performance specifications 



-Supports dynamic updates with the capability of doing bulk updates 



-Geographically distributed sites to provide greater stability and performance



-In addition, .musicʹs thick-WHOIS solution also provides for additional search capabilities and mechanisms to mitigate potential forms of abuse as discussed below. (e.g., IDN, registrant data).



26.2 Software Components



The WHOIS architecture comprises the following components:



-An in-memory database local to each WHOIS node: To provide for the performance needs, the WHOIS data is served from an in-memory database indexed by searchable keys. 



-Redundant servers: To provide for redundancy, the WHOIS updates are propagated to a cluster of WHOIS servers that maintain an independent copy of the database. 



-Attack resistant: To ensure that the WHOIS system cannot be abused using malicious queries or DOS attacks, the WHOIS server is only allowed to query the local database and rate limits on queries based on IPs and IP ranges can be readily applied.



-Accuracy auditor: To ensure the accuracy of the information served by the WHOIS servers, a daily audit is done between the SRS information and the WHOIS responses for the domain names which are updated during the last 24-hour period. Any discrepancies are resolved proactively.



-Modular design: The WHOIS system allows for filtering and translation of data elements between the SRS and the WHOIS database to allow for customizations.



-Scalable architecture: The WHOIS system is scalable and has a very small footprint. Depending on the query volume, the deployment size can grow and shrink quickly.



-Flexible: It is flexible enough to accommodate thin, thick, or modified thick models and can accommodate any future ICANN policy, such as different information display levels based on user categorization.



-SRS master database: The SRS database is the main persistent store of the Registry information. The Update Agent computes what WHOIS updates need to be pushed out. A publish-subscribe mechanism then takes these incremental updates and pushes to all the WHOIS slaves that answer queries.



26.3 Compliance with RFC and Specifications 4 and 10



Neustar has been running thick-WHOIS Services for over 10+ years in full compliance with RFC 3912 and with Specifications 4 and 10 of the Registry Agreement. RFC 3912 is a simple text based protocol over TCP that describes the interaction between the server and client on port 43. Neustar built a home-grown solution for this service. It processes millions of WHOIS queries per day.



Table 26-1 attached describes Neustarʹs compliance with Specifications 4 and 10.



Neustar ensures compliance with all RFCs through a variety of processes and procedures. Members from the engineering and standards teams actively monitor and participate in the development of RFCs that impact the registry services, including those related to WHOIS. When new RFCs are introduced or existing ones are updated, the team performs a full compliance review of each system impacted by the change. Furthermore, all code releases include a full regression test that includes specific test cases to verify RFC compliance.



26.4 High-level WHOIS System Description



26.4.1 WHOIS Service (port 43)



The WHOIS service is responsible for handling port 43 queries. Our WHOIS is optimized for speed using an in-memory database and master-slave architecture between the SRS and WHOIS slaves.



The WHOIS service also has built-in support for IDN. If the domain name being queried is an IDN, the returned results include the language of the domain name, the domain nameʹs UTF-8 encoded representation along with the Unicode code page.



26.4.2 Web Page for WHOIS queries



In addition to the WHOIS Service on port 43, Neustar provides a web based WHOIS application (www.whois.music). It is an intuitive and easy to use application for the general public to use. WHOIS web application provides all of the features available in the port 43 WHOIS. This includes full and partial search on:



-Domain names

-Nameservers

-Registrant, Technical and Administrative Contacts

-Registrars



It also provides features not available on the port 43 service. These include:



1. Redemption Grace Period calculation: Based on the registryʹs policy, domains in pendingDelete can be restorable or scheduled for release depending on the date⁄time the domain went into pendingDelete. For these domains, the web based WHOIS displays Restorable or Scheduled for Release to clearly show this additional status to the user.



2. Extensive support for international domain names (IDN)



3. Ability to perform WHOIS lookups on the actual Unicode IDN



4. Display of the actual Unicode IDN in addition to the ACE-encoded name



5. A Unicode to Punycode and Punycode to Unicode translator



6. An extensive FAQ



7. A list of upcoming domain deletions



26.5 IT and Infrastructure Resources



As described above the WHOIS architecture uses a workflow that decouples the update process from the SRS. This ensures SRS performance is not adversely affected by the load requirements of dynamic updates. It is also decoupled from the WHOIS lookup agent to ensure the WHOIS service is always available and performing well for users. Each of Neustarʹs geographically diverse WHOIS sites use:



-Firewalls, to protect this sensitive data 

-Dedicated servers for MQ Series, to ensure guaranteed delivery of WHOIS updates 

-Packetshaper for source IP address-based bandwidth limiting 

-Load balancers to distribute query load 

-Multiple WHOIS servers for maximizing the performance of WHOIS service.



The WHOIS service uses HP BL 460C servers, each with 2 X Quad Core CPU and a 64GB of RAM. The existing infrastructure has 6 servers, but is designed to be easily scaled with additional servers should it be needed.

Figure 26-1 attached depicts the different components of the WHOIS architecture.



26.6 Interconnectivity with Other Registry System



As described in Question 24 about the SRS and further in response to Question 31, Technical Overview, when an update is made by a registrar that impacts WHOIS data, a trigger is sent to the WHOIS system by the external notifier layer. The update agent processes these updates, transforms the data if necessary and then uses messaging oriented middleware to publish all updates to each WHOIS slave. The local update agent accepts the update and applies it to the local in-memory database. A separate auditor compares the data in WHOIS and the SRS daily and monthly to ensure accuracy of the published data.



26.7 Frequency of Synchronization between Servers



Updates from the SRS, through the external notifiers, to the constellation of independent WHOIS slaves happens in real-time via an asynchronous publish⁄subscribe messaging architecture. The updates are guaranteed to be updated in each slave within the required SLA of 95%, less than or equal to 60 minutes. Please note that Neustarʹs current architecture is built towards the stricter SLAs (95%, less than or equal to 15 minutes) of .BIZ. The vast majority of updates tend to happen within 2-3 minutes.



26.8 Provision for Searchable WHOIS Capabilities



Neustar will create a new web-based service to address the new search features based on requirements specified in Specification 4 Section 1.8. The application will enable users to search the WHOIS directory using any one or more of the following fields: 



-Domain name



-Registrar ID



-Contacts and registrantʹs name



-Contact and registrantʹs postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.)



-Name server name and name server IP address



-The system will also allow search using non-Latin character sets which are compliant with IDNA specification.

The user will choose one or more search criteria, combine them by Boolean operators (AND, OR, NOT) and provide partial or exact match regular expressions for each of the criterion name-value pairs. The domain names matching the search criteria will be returned to the user.



Figure 26-2 attached shows an architectural depiction of the new service. 



To mitigate the risk of this powerful search service being abused by unscrupulous data miners, a layer of security will be built around the query engine which will allow the registry to identify rogue activities and then take appropriate measures. Potential abuses include, but are not limited to:



-Data Mining

-Unauthorized Access

-Excessive Querying

-Denial of Service Attacks



To mitigate the abuses noted above, Neustar will implement any or all of these mechanisms as appropriate:



-Username-password based authentication 

-Certificate based authentication

-Data encryption

-CAPTCHA mechanism to prevent robo invocation of Web query

-Fee-based advanced query capabilities for premium customers.



The searchable WHOIS application will adhere to all privacy laws and policies of the .music registry.



26.9 Resourcing Plans

 

As with the SRS, the development, customization, and on-going support of the WHOIS service is the responsibility of a combination of technical and operational teams.The primary groups responsible for managing the service include:



-Development⁄Engineering 19 employees

-Database Administration 10 employees

-Systems Administration 24 employees

-Network Engineering 5 employees 



Additionally, if customization or modifications are required, the Product Management and Quality Assurance teams will also be involved.Finally, the Network Operations and Information Security play an important role in ensuring the systems involved are operating securely and reliably. The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31.Neustarʹs WHOIS implementation is very mature, and has been in production for over 10 years.As such, very little new development will be required to support the implementation of the .music registry. The resources are more than adequate to support the WHOIS needs of all the TLDs operated by Neustar, including the .music registry. 

27.1 Registration Life Cycle



27.1.1 Introduction



.music will follow the lifecycle and business rules found in the majority of gTLDs today. Our back-end operator, Neustar, has over ten years of experience managing numerous TLDs that utilize standard and unique business rules and lifecycles. This section describes the business rules, registration states, and the overall domain lifecycle that will be use for .music.



27.1.2 Domain Lifecycle - Description



The registry will use the EPP 1.0 standard for provisioning domain names, contacts and hosts. Each domain record is comprised of three registry object types: domain, contacts, and hosts.



Domains, contacts and hosts may be assigned various EPP defined statuses indicating either a particular state or restriction placed on the object. Some statuses may be applied by the Registrar; other statuses may only be applied by the Registry. Statuses are an integral part of the domain lifecycle and serve the dual purpose of indicating the particular state of the domain and indicating any restrictions placed on the domain. The EPP standard defines 17 statuses, however only 14 of these statuses will be used in the .music registry per the defined .music business rules.



The following is a brief description of each of the statuses. Server statuses may only be applied by the Registry, and client statuses may be applied by the Registrar.



-OK Default status applied by the Registry.

-Inactive Default status applied by the Registry if the domain has less than 2 nameservers.

-PendingCreate Status applied by the Registry upon processing a successful Create command, and indicates further action is pending. This status will not be used in the .music registry.

-PendingTransfer Status applied by the Registry upon processing a successful Transfer request command, and indicates further action is pending.

-PendingDelete Status applied by the Registry upon processing a successful Delete command that does not result in the immediate deletion of the domain, and indicates further action is pending.

-PendingRenew Status applied by the Registry upon processing a successful Renew command that does not result in the immediate renewal of the domain, and indicates further action is pending. This status will not be used in the .music registry.

-PendingUpdate Status applied by the Registry if an additional action is expected to complete the update, and indicates further action is pending. This status will not be used in the .music registry.

-Hold Removes the domain from the DNS zone.

-UpdateProhibited Prevents the object from being modified by an Update command.

-TransferProhibited Prevents the object from being transferred to another Registrar by the Transfer command.

-RenewProhibited Prevents a domain from being renewed by a Renew command.

-DeleteProhibited Prevents the object from being deleted by a Delete command. 



The lifecycle of a domain begins with the registration of the domain. All registrations must follow the EPP standard, as well as the specific business rules described in the response to Question 18 above. Upon registration a domain will either be in an active or inactive state. Domains in an active state are delegated and have their delegation information published to the zone. Inactive domains either have no delegation information or their delegation information in not published in the zone. Following the initial registration of a domain, one of five actions may occur during its lifecycle:



-Domain may be updated

-Domain may be deleted, either within or after the add-grace period

-Domain may be renewed at anytime during the term

-Domain may be auto-renewed by the Registry

-Domain may be transferred to another registrar. 

 

Each of these actions may result in a change in domain state. This is described in more detail in the following section. Every domain must eventually be renewed, auto-renewed, transferred, or deleted. A registrar may apply EPP statuses described above to prevent specific actions such as updates, renewals, transfers, or deletions.



27.2 Registration States



27.2.1 Domain Lifecycle Registration States



As described above the .music registry will implement a standard domain lifecycle found in most gTLD registries today. There are five possible domain states:



-Active 

-Inactive

-Locked

-Pending Transfer

-Pending Delete.



All domains are always in either an Active or Inactive state, and throughout the course of the lifecycle may also be in a Locked, Pending Transfer, and Pending Delete state. Specific conditions such as applied EPP policies and registry business rules will determine whether a domain can be transitioned between states. Additionally, within each state, domains may be subject to various timed events such as grace periods, and notification periods. 



27.2.2 Active State



The active state is the normal state of a domain and indicates that delegation data has been provided and the delegation information is published in the zone. A domain in an Active state may also be in the Locked or Pending Transfer states.



27.2.3 Inactive State



The Inactive state indicates that a domain has not been delegated or that the delegation data has not been published to the zone. A domain in an Inactive state may also be in the Locked or Pending Transfer states. By default all domain in the Pending Delete state are also in the Inactive state.



27.2.4 Locked State



The Locked state indicates that certain specified EPP transactions may not be performed to the domain. A domain is considered to be in a Locked state if at least one restriction has been placed on the domain; however up to eight restrictions may be applied simultaneously. Domains in the Locked state will also be in the Active or Inactive, and under certain conditions may also be in the Pending Transfer or Pending Delete states.



27.2.5 Pending Transfer State



The Pending Transfer state indicates a condition in which there has been a request to transfer the domain from one registrar to another. The domain is placed in the Pending Transfer state for a period of time to allow the current (losing) registrar to approve (ack) or reject (nack) the transfer request. Registrars may only nack requests for reasons specified in the Inter-Registrar Transfer Policy.



27.2.6 Pending Delete State



The Pending Delete State occurs when a Delete command has been sent to the Registry after the first 5 days (120 hours) of registration. The Pending Delete period is 35-days during which the first 30-days the name enters the Redemption Grace Period (RGP) and the last 5-days guarantee that the domain will be purged from the Registry Database and available to public pool for registration on a first come, first serve basis.



27.3 Typical Registration Lifecycle Activities



27.3.1 Domain Creation Process



The creation (registration) of domain names is the fundamental registry operation. All other operations are designed to support or compliment a domain creation. The following steps occur when a domain is created. 



1. Contact objects are created in the SRS database. The same contact object may be used for each contact type, or they may all be different. If the contacts already exist in the database this step may be skipped.



2. Nameservers are created in the SRS database. Nameservers are not required to complete the registration process; however any domain with less than 2 name servers will not be resolvable.



3. The domain is created using the each of the objects created in the previous steps. In addition, the term and any client statuses may be assigned at the time of creation.



The actual number of EPP transactions needed to complete the registration of a domain name can be as few as one and as many as 40. The latter assumes seven distinct contacts and 13 nameservers, with Check and Create commands submitted for each object. 



27.3.2 Update Process



Registry objects may be updated (modified) using the EPP Modify operation. The Update transaction updates the attributes of the object. 



For example, the Update operation on a domain name will only allow the following attributes to be updated:



-Domain statuses

-Registrant ID

-Administrative Contact ID

-Billing Contact ID

-Technical Contact ID

-Nameservers

-AuthInfo

-Additional Registrar provided fields.



The Update operation will not modify the details of the contacts. Rather it may be used to associate a different contact object (using the Contact ID) to the domain name. To update the details of the contact object the Update transaction must be applied to the contact itself. For example, if an existing registrant wished to update the postal address, the Registrar would use the Update command to modify the contact object, and not the domain object. 



27.3.4 Renew Process 



The term of a domain may be extended using the EPP Renew operation. ICANN policy generally establishes the maximum term of a domain name to be 10 years, and Neustar recommends not deviating from this policy. A domain may be renewed⁄extended at any point time, even immediately following the initial registration. The only stipulation is that the overall term of the domain name may not exceed 10 years. If a Renew operation is performed with a term value will extend the domain beyond the 10 year limit, the Registry will reject the transaction entirely.



27.3.5 Transfer Process



The EPP Transfer command is used for several domain transfer related operations: 



-Initiate a domain transfer

-Cancel a domain transfer

-Approve a domain transfer

- Reject a domain transfer.



To transfer a domain from one Registrar to another the following process is followed:



1. The gaining (new) Registrar submits a Transfer command, which includes the AuthInfo code of the domain name.



2. If the AuthInfo code is valid and the domain is not in a status that does not allow transfers the domain is placed into pendingTransfer status



3. A poll message notifying the losing Registrar of the pending transfer is sent to the Registrarʹs message queue



4. The domain remains in pendingTransfer status for up to 120 hours, or until the losing (current) Registrar Acks (approves) or Nack (rejects) the transfer request



5. If the losing Registrar has not Acked or Nacked the transfer request within the 120 hour timeframe, the Registry auto-approves the transfer



6. The requesting Registrar may cancel the original request up until the transfer has been completed.



A transfer adds an additional year to the term of the domain. In the event that a transfer will cause the domain to exceed the 10 year maximum term, the Registry will add a partial term up to the 10 year limit. Unlike with the Renew operation, the Registry will not reject a transfer operation.



27.3.6 Deletion Process



A domain may be deleted from the SRS using the EPP Delete operation. The Delete operation will result in either the domain being immediately removed from the database or the domain being placed in pendingDelete status. The outcome is dependent on when the domain is deleted. If the domain is deleted within the first five days (120 hours) of registration, the domain is immediately removed from the database. A deletion at any other time will result in the domain being placed in pendingDelete status and entering the Redemption Grace Period (RGP). Additionally, domains that are deleted within five days (120) hours of any billable (add, renew, transfer) transaction may be deleted for credit.



27.4 Applicable Time Elements



The following section explains the time elements that are involved. 



27.4.1 Grace Periods



There are six grace periods:



-Add-Delete Grace Period (AGP)

-Renew-Delete Grace Period

-Transfer-Delete Grace Period

-Auto-Renew-Delete Grace Period

-Auto-Renew Grace Period

-Redemption Grace Period (RGP). 



The first four grace periods listed above are designed to provide the Registrar with the ability to cancel a revenue transaction (add, renew, or transfer) within a certain period of time and receive a credit for the original transaction.

The following describes each of these grace periods in detail.



27.4.2 Add-Delete Grace Period 



The APG is associated with the date the Domain was registered. Domains may be deleted for credit during the initial 120 hours of a registration, and the Registrar will receive a billing credit for the original registration. If the domain is deleted during the Add Grace Period, the domain is dropped from the database immediately and a credit is applied to the Registrarʹs billing account. 



27.4.3 Renew-Delete Grace Period 



The Renew-Delete Grace Period is associated with the date the Domain was renewed. Domains may be deleted for credit during the 120 hours after a renewal. The grace period is intended to allow Registrars to correct domains that were mistakenly renewed. It should be noted that domains that are deleted during the renew grace period will be placed into pendingDelete and will enter the RGP (see below). 



27.4.4 Transfer-Delete Grace Period 



The Transfer-Delete Grace Period is associated with the date the Domain was transferred to another Registrar. Domains may be deleted for credit during the 120 hours after a transfer. It should be noted that domains that are deleted during the renew grace period will be placed into pendingDelete and will enter the RGP. A deletion of domain after a transfer is not the method used to correct a transfer mistake. Domains that have been erroneously transferred or hijacked by another party can be transferred back to the original registrar through various means including contacting the Registry.



27.4.5 Auto-Renew-Delete Grace Period 



The Auto-Renew-Delete Grace Period is associated with the date the Domain was auto-renewed. Domains may be deleted for credit during the 120 hours after an auto-renewal. The grace period is intended to allow Registrars to correct domains that were mistakenly auto-renewed. It should be noted that domains that are deleted during the auto-renew delete grace period will be placed into pendingDelete and will enter the RGP. 



27.4.6 Auto-Renew Grace Period 



The Auto-Renew Grace Period is a special grace period intended to provide registrants with an extra amount of time, beyond the expiration date, to renew their domain name. The grace period lasts for 45 days from the expiration date of the domain name. Registrars are not required to provide registrants with the full 45 days of the period.



27.4.7 Redemption Grace Period 



The RGP is a special grace period that enables Registrars to restore domains that have been inadvertently deleted but are still in pendingDelete status within the Redemption Grace Period. All domains enter the RGP except those deleted during the AGP. 



The RGP period is 30 days, during which time the domain may be restored using the EPP RenewDomain command as described below. Following the 30day RGP period the domain will remain in pendingDelete status for an additional five days, during which time the domain may NOT be restored. The domain is released from the SRS, at the end of the 5 day non-restore period. A restore fee applies and is detailed in the Billing Section. A renewal fee will be automatically applied for any domain past expiration.



Neustar has created a unique restoration process that uses the EPP Renew transaction to restore the domain and fulfill all the reporting obligations required under ICANN policy. The following describes the restoration process.



27.5 State Diagram



Figure 27-1 attached provides a description of the registration lifecycle. 



The different states of the lifecycle are active, inactive, locked, pending transfer, and pending delete.Please refer to section 27.2 for detailed descriptions of each of these states. The lines between the states represent triggers that transition a domain from one state to another. 



The details of each trigger are described below:



-Create:Registry receives a create domain EPP command.

-WithNS:The domain has met the minimum number of nameservers required by registry policy in order to be published in the DNS zone.

-WithOutNS:The domain has not met the minimum number of nameservers required by registry policy. The domain will not be in the DNS zone.

-Remove Nameservers: Domainʹs nameserver(s) is removed as part of an update domain EPP command. The total nameserver is below the minimum number of nameservers required by registry policy in order to be published in the DNS zone.

-Add Nameservers: Nameserver(s) has been added to domain as part of an update domain EPP command.The total number of nameservers has met the minimum number of nameservers required by registry policy in order to be published in the DNS zone.

-Delete: Registry receives a delete domain EPP command.

-DeleteAfterGrace: Domain deletion does not fall within the add grace period.

-DeleteWithinAddGrace:Domain deletion falls within add grace period.

-Restore: Domain is restored.Domain goes back to its original state prior to the delete command.

-Transfer: Transfer request EPP command is received.

-Transfer Approve⁄Cancel⁄Reject:Transfer requested is approved or cancel or rejected.

-TransferProhibited: The domain is in clientTransferProhibited and⁄or serverTranferProhibited status. This will cause the transfer request to fail.The domain goes back to its original state.

-DeleteProhibited: The domain is in clientDeleteProhibited and⁄or serverDeleteProhibited status.This will cause the delete command to fail.The domain goes back to its original state.



Note: the locked state is not represented as a distinct state on the diagram as a domain may be in a locked state in combination with any of the other states: inactive, active, pending transfer, or pending delete.



27.5.1 EPP RFC Consistency



As described above, the domain lifecycle is determined by ICANN policy and the EPP RFCs. Neustar has been operating ICANN TLDs for the past 10 years consistent and compliant with all the ICANN policies and related EPP RFCs. 



27.6 Resources



The registration lifecycle and associated business rules are largely determined by policy and business requirements; as such the Product Management and Policy teams will play a critical role in working Applicant to determine the precise rules that meet the requirements of the TLD. Implementation of the lifecycle rules will be the responsibility of Development⁄Engineering team, with testing performed by the Quality Assurance team.Neustarʹs SRS implementation is very flexible and configurable, and in many case development is not required to support business rule changes. 



The .music registry will be using standard lifecycle rules, and as such no customization is anticipated. However should modifications be required in the future, the necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31.The following resources are available from those teams:



-Development⁄Engineering 19 employees

-Registry Product Management 4 employees



These resources are more than adequate to support the development needs of all the TLDs operated by Neustar, including the .music registry.

28.1 Abuse Prevention and Mitigation

Strong abuse prevention of a new gTLD is an important benefit to the internet community. .music and its registry operator and back-end registry services provider, Neustar, agree that a registry must not only aim for the highest standards of technical and operational competence, but also needs to act as a steward of the space on behalf of the Internet community and ICANN in promoting the public interest. Neustar brings extensive experience establishing and implementing registration policies. This experience will be leveraged to help .music combat abusive and malicious domain activity within the new gTLD space.

One of those public interest functions for a responsible domain name registry includes working towards the eradication of abusive domain name registrations, including, but not limited to, those resulting from:

• Illegal or fraudulent actions 
• Spam
• Phishing
• Pharming 
• Distribution of malware 
• Fast flux hosting 
• Botnets 
• Distribution of child pornography 
• Online sale or distribution of illegal pharmaceuticals.
• Intellectual Property Violation
• Copyright Violation

More specifically, although traditionally botnets have used Internet Relay Chat (IRC) servers to control registry and the compromised PCs, or bots, for DDoS attacks and the theft of personal information, an increasingly popular technique, known as fast-flux DNS, allows botnets to use a multitude of servers to hide a key host or to create a highly-available control network. This ability to shift the attacker’s infrastructure over a multitude of servers in various countries creates an obstacle for law enforcement and security researchers to mitigate the effects of these botnets. But a point of weakness in this scheme is its dependence on DNS for its translation services. By taking an active role in researching and monitoring these sorts of botnets, .music’s partner, Neustar, has developed the ability to efficiently work with various law enforcement and security communities to begin a new phase of mitigation of these types of threats.

Policies and Procedures to Minimize Abusive Registrations

A Registry must have the policies, resources, personnel, and expertise in place to combat such abusive DNS practices. As .music’s registry provider, Neustar is at the forefront of the prevention of such abusive practices and is one of the few registry operators to have actually developed and implemented an active “domain takedown” policy. We also believe that a strong program is essential given that registrants have a reasonable expectation that they are in control of the data associated with their domains, especially its presence in the DNS zone. Because domain names are sometimes used as a mechanism to enable various illegitimate activities on the Internet often the best preventative measure to thwart these attacks is to remove the names completely from the DNS before they can impart harm, not only to the domain name registrant, but also to millions of unsuspecting Internet users.

Removing the domain name from the zone has the effect of shutting down all activity associated with the domain name, including the use of all websites and e-mail. The use of this technique should not be entered into lightly. .music has an extensive, defined, and documented process for taking the necessary action of removing a domain from the zone when its presence in the zone poses a threat to the security and stability of the infrastructure of the Internet or the registry. 

Abuse Point of Contact 
 
As required by the Registry Agreement, .music will establish and publish on its website a single abuse point of contact responsible for addressing inquiries from law enforcement, its community members and the public related to malicious and abusive conduct. .music will also provide such information to ICANN prior to the delegation of any domain names in the TLD. This information shall consist of, at a minimum, a valid e-mail address dedicated solely to the handling of malicious conduct complaints, and a telephone number and mailing address for the primary contact. We will ensure that this information will be kept accurate and up to date and will be provided to ICANN if and when changes are made. In addition, with respect to inquiries from ICANN-Accredited registrars, our registry services provider, Neustar, shall have an additional point of contact, as it does today, handling requests by registrars related to abusive domain name practices. 
 
28.2 Policies Regarding Abuse Complaints

One of the key policies each new gTLD registry will need to have is an Acceptable Use Policy that clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. In addition, the policy will be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take the appropriate actions based on the type of abuse. This will include locking down the domain name - preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring to the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation.
 
The dotMusic Registry will adopt an Acceptable Use Policy that clearly defines the types of activities that will not be permitted in the TLD and reserves the right of the Applicant to lock, cancel, transfer or otherwise suspend or take down domain names violating the Acceptable Use Policy and allow the Registry where and when appropriate to share information with law enforcement. Each ICANN-Accredited Registrar (even in the case of a sole registrar model) must agree to pass through the Acceptable Use Policy to its Resellers (if applicable) and ultimately to the TLD registrants. Below is the Registry’s initial Acceptable Use Policy that we will use in connection with .music.

the dotMusic Registry Acceptable Use Policy

This Acceptable Use Policy gives the Registry the ability to quickly lock, cancel, transfer or take ownership of any .music domain name, either temporarily or permanently, if the domain name is being used in a manner that appears to threaten the stability, integrity or security of the Registry, or any of its registrar partners – and⁄or that may put the safety and security of any registrant or user at risk. The process also allows the Registry to take preventive measures to avoid any such criminal or security threats.

The Acceptable Use Policy may be triggered through a variety of channels, including, among other things, community member complaint, private complaint, public alert, government or enforcement agency outreach, and the on-going monitoring by the Registry or its partners. In all cases, the Registry or its designees will alert Registry’s registrar partners about any identified threats, and will work closely with them to bring offending sites into compliance.

The following are some (but not all) activities that will be subject to rapid domain compliance:

• Phishing: the attempt to acquire personally identifiable information by masquerading as a website other than .musicʹs own.
• Pharming: the redirection of Internet users to websites other than those the user intends to visit, usually through unauthorized changes to the Hosts file on a victim’s computer or DNS records in DNS servers.
• Dissemination of Malware: the intentional creation and distribution of ʺmaliciousʺ software designed to infiltrate a computer system without the owner’s consent, including, without limitation, computer viruses, worms, key loggers, and Trojans.
• Fast Flux Hosting: a technique used to shelter Phishing, Pharming and Malware sites and networks from detection and to frustrate methods employed to defend against such practices, whereby the IP address associated with fraudulent websites are changed rapidly so as to make the true location of the sites difficult to find.
• Botnetting: the development and use of a command, agent, motor, service, or software which is implemented: (1) to remotely control the computer or computer system of an Internet user without their knowledge or consent, (2) to generate direct denial of service (DDOS) attacks.
• Malicious Hacking: the attempt to gain unauthorized access (or exceed the level of authorized access) to a computer, information system, user account or profile, database, or security system.
• Child Pornography: the storage, publication, display and⁄or dissemination of pornographic materials depicting individuals under the age of majority in the relevant jurisdiction.
• Community Abuse Considerations: The dotMusic Registry will create a safe TLD in .music by actively monitoring and and combating copyright infringement, cybersquatting, typo-squatting and any other domain name and registration based abusive practices. They will also actively monitor and combat the harder abuse instances that plague the music industry in the online world. These are defined as copyright infringement that results from P2P sharing, illegal digital distribution, along with any and all types of Intellectual Property infringement involving the DNS.
 
The Registry reserves the right, in its sole discretion, to take any administrative and operational actions necessary, including the use of computer forensics and information security technological services, among other things, in order to implement the Acceptable Use Policy. In addition, the Registry reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to enfore the requirements of community membership and acceptable use (3) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (4) to avoid any liability, civil or criminal, on the part of Registry as well as its affiliates, subsidiaries, officers, directors, and employees; (5) per the terms of the registration agreement or (6) to correct mistakes made by the Registry or any Registrar in connection with a domain name registration. Registry also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
 
Taking Action Against Abusive and⁄or Malicious Activity

The Registry is committed to ensuring that those domain names associated with abuse or Malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security, the community requirements of the TLD, or is part of a real-time investigation by law enforcement. 

Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring registrar and the relevant reseller will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar (reseller) has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on “ServerHold”. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.
Coordination with Law Enforcement

With the assistance of Neustar as its back-end registry services provider, .music can meet its obligations under Section 2.8 of the Registry Agreement where required to take reasonable steps to investigate and respond to reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of its TLD. The Registry will respond to legitimate law enforcement inquiries within one business day from receiving the request. Such response shall include, at a minimum, an acknowledgement of receipt of the request, Questions or comments concerning the request, and an outline of the next steps to be taken by .Music for rapid resolution of the request. 
 
In the event such request involves any of the activities which can be validated by the Registry and involves the type of activity set forth in the Acceptable Use Policy, the sponsoring registrar and its reseller is then given 12 hours to investigate the activity further and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the registry to keep the name in the zone. If the registrar (reseller) has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on “serverHold”. 
 
Monitoring for Malicious Activity

28.3 Measures for Removal of Orphan Glue Records

As the Security and Stability Advisory Committee of ICANN (SSAC) rightly acknowledges, although orphaned glue records may be used for abusive or malicious purposes, the “dominant use of orphaned glue supports the correct and ordinary operation of the DNS.” See http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.
 
While orphan glue often support correct and ordinary operation of the DNS, we understand that such glue records can be used maliciously to point to name servers that host domains used in illegal phishing, bot-nets, malware, and other abusive behaviors. Problems occur when the parent domain of the glue record is deleted but its children glue records still remain in DNS. Therefore, when the Registry has written evidence of actual abuse of orphaned glue, the Registry will take action to remove those records from the zone to mitigate such malicious conduct.
 
Neustar run a daily audit of entries in its DNS systems and compares those with its provisioning system. This serves as an umbrella protection to make sure that items in the DNS zone are valid. Any DNS record that shows up in the DNS zone but not in the provisioning system will be flagged for investigation and removed if necessary. This daily DNS audit serves to not only prevent orphaned hosts but also other records that should not be in the zone. 
 
In addition, if either .music or Neustar become aware of actual abuse on orphaned glue after receiving written notification by a third party through its Abuse Contact or through its customer support, such glue records will be removed from the zone.
 
28.4 Measures to Promote WHOIS Accuracy 

The dotMusic Registry acknowledges that ICANN has developed a number of mechanisms over the past decade that are intended to address the issue of inaccurate WHOIS information. Such measures alone have not proven to be sufficient and .music will offer a mechanism whereby third parties can submit complaints directly to the Applicant (as opposed to ICANN or the sponsoring Registrar) about inaccurate or incomplete WHOIS data. Such information shall be forwarded to the sponsoring Registrar, who shall be required to address those complaints with their registrants. Thirty days after forwarding the complaint to the registrar, .music will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, Applicant reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

In addition, .music shall on its own initiative, no less than twice per year, perform a manual review of a random sampling of .music domain names to test the accuracy of the WHOIS information. Although this will not include verifying the actual information in the WHOIS record, .music will be examining the WHOIS data for prima facie evidence of inaccuracies. In the event that such evidence exists, it shall be forwarded to the sponsoring Registrar, who shall be required to address those complaints with their registrants. Thirty days after forwarding the complaint to the registrar, the Applicant will examine the current WHOIS data for names that were alleged to be inaccurate to determine if the information was corrected, the domain name was deleted, or there was some other disposition. If the Registrar has failed to take any action, or it is clear that the Registrant was either unwilling or unable to correct the inaccuracies, .music reserves the right to suspend the applicable domain name(s) until such time as the Registrant is able to cure the deficiencies.

28.4.1 Authentication of Registrant Information and Monitoring of Registration Data

Authentication of registrant information as complete and accurate at time of registration. Most .music registrations will be sold by “reseller”.music community member associations to their memberships. These resellers will in many cases be able to verify their own memberships at the time of domain sale. To address the case where the reseller lacks the ability to do this in the domain sale process, the .music reseller platform will capture all registrant declaration as to community membership including the identification of their accredited member association. All registrations associated with a given member association will be reported daily to the relevant member association for asynchronous review. Discrepancies in declared community membership will be addressed through the standard abuse practices described in the Acceptable Use Policy.
 
28.4.3 Policies and Procedures Ensuring Compliance (RRA and RA)

The dotMusic Registry intends to operate as a sole registrar model but will offer exclusive reseller services for music associations to sell domain names to their memberships. This registrar entity and subsequent resellers will be required to enforce measures, establish policies and procedures to ensure compliance, which may include audits, financial incentives, penalties, or other means. 

The Registry-Registrar Agreement (RRA) will contain the following terms which will be passed through to the Reseller Agreements where applicable:

1. Confirming that Registrants have a bona fide affiliation with a legitimate Community Member. 
2. Requiring that Registrants execute a Registrant Agreement which provides an additional level in securing the protection of creative and intellectual property rights and serves to mitigate copyright infringement, piracy and any other abuse as outlined in the dotMusic Registry policies. 
 a. The electronic acceptance of the Registrant Agreement would be a pre-requisite to the confirmation of any registration or renewal transaction performed by the Registrar (reseller).
 b. Ensuring an electronic audit trail is maintained at the registrar, referencing each and every .music registration to an acceptance date of the Registrant Agreement.
3. Requiring their registrants to certify on an annual basis that they are in compliance with all Accreditation Criteria and other policies and requirements governing domains, including, but not limited to, that the registrant:
 a. is not, and will not be involved in any form of copyright infringement, or otherwise facilitate such copyright infringement or provide access to any software, service or application that facilitates copyright infringement, directly or indirectly through the domain;
 b. has all the rights necessary to transmit, display, provide access to, reproduce, distribute, publish, link to, perform or otherwise exploit any copyrighted content made available directly or indirectly through the domain; 
 c. has and will maintain appropriate records sufficient to verify any claimed licenses or authorizations to use or exploit creative content owned by third parties; 
 d. will only use the domain in connection with activities involving legitimate⁄authorized uses of creative works and not to facilitate infringement; and 
 e. meets the other Accreditation Criteria and that their operation of the site is legal
4. Acknowledgement that proxy registrations are disallowed, except those proxy registration services that are approved by, and fully comply with ICANN standards and .Music Registry policies.
5. Acknowledgement that the registrar and⁄or reseller will enforce the terms of the Registrant Agreement.
6. Acknowledgement that the registrar and⁄or reseller will endeavor to maintain WHOIS accuracy by:
 a. authenticating the registrant information as complete and accurate at time of registration,
 b. ensure the registrant is a valid member of good standing in at least of one of Coalition Member Organizations. Means requiring submission of identifying membership information.
 c. ensuring completeness and verifying all contact information of principals mentioned in registration data. Means may include utilizing simple web based technology to discern and thus reject inaccurate data (such as mismatch of zip code and State Code), and other means,
 d. regular monitoring of registration data for accuracy and completeness, employing authentication methods, and establishing policies and procedures to address domain names with inaccurate or incomplete WHOIS data. Means to do so would include periodic email alerts to the domain name registrant to verify or correct WHOIS information.
7. Acknowledgement of and compliance with .Music Registry’s abuse detection and mitigation procedures, up to and including domain takedown.
8. Acknowledgement of the .Music Registry’s right to take action to ensure compliance with the abuse detection and mitigation policies and procedures of the .Music Registry. 
 a. Acceptance of .Music’s right to suspend domains found to be in violation of .Music policies.
 b. Implement reasonable procedures to identify repeat registrants that attempt to avoid detection as repeat offender registrants, etc. 
 c. Registrar (resellers) will be required to promptly take down⁄deregister domains that fail to comply with the Accreditation Criteria 
and other policies governing domains (including, but not limited to breach of the certification contemplated below), and to refuse to accept registrations from registrants that previously violated such criteria or policies. 
 d. Annual verification of and electronic acceptance of the RRA. 

Last but not least, the .Music Registry will create the Registrant Agreement. The RA would be furnished to all .Music registrar’s resellers as part of the reseller accreditation procedures. The RA would at a minimum require all registrants to:

1. Agree to and abide by the terms of the .Music Registrant Agreement. 
2. Adhere to the protection of Creative and Intellectual Property rights such as mitigating copyright infringement and piracy as well as guarding against other abuses such as cyber squatting, typo-squatting or other abusive registration practices defined in the agreement. 
3. Annually notifying Registrants of their current agreement to:
 a. Avoid of any form of copyright infringement, or otherwise facilitate such copyright infringement or provide access to any software, service or application that facilitates copyright infringement, directly or indirectly through the domain;
 b. Possess all necessary rights to transmit, display, provide access to, reproduce, distribute, publish, link to, perform or otherwise exploit any copyrighted content made available directly or indirectly through the domain; 
 c. Maintain appropriate records to sufficiently verify any claimed licenses or authorizations to use or exploit creative content owned by third parties; 
 d. Use the domain only in connection with activities involving legitimate⁄authorized uses of creative works and not to facilitate infringement;
 e. Meet other Accreditation Criteria as set forth from time to time
 f. Implement reasonable monitoring of their site and their domain to police against infringing activity;
 g. Implement reasonable enforcement procedures to ensure that any unauthorized content is
removed before being placed on the domain or immediately removed once the registrant becomes aware of such unauthorized content;
 h. Proactively ensure unauthorized content is not made available via the domain;
 i. Acknowledge the .Music Registry’s right to engage in monitoring and policing activity of the registrant’s domain and site; and
 j. Provide evidence of reasonable security and other measures that will be used to protect content made available from the domain.
4. Acknowledgement that if the registrant’s domain use is found to be in violation of the .Music Registrant Agreement, the domain will be subject to suspension and reclaimed by the Registry.

.Music Registry will set itself up as a sole registrar, providing reseller capability to Community Member Associations, who will in turn sell .Music domains to their memberships. This model will provide the following advantages:

• minimize malicious conduct in .music (eg: quicker takedown in case of abusive behavior),
• minimize dot Music Registry’s administrative and technical costs,
• maximize compliance with dotMusic Registry policies, and
• maximize control, as the dotMusic Registry would be the “Registrar of Record” in the WHOIS.

28.5 Resourcing Plans 

Responsibility for abuse mitigation rests with a variety of functional groups. The Abuse Monitoring team is primarily responsible for providing analysis and conducting investigations of reports of abuse. The customer service team also plays an important role in assisting with the investigations, responded to customers, and notifying registrars of abusive domains. Finally, the Policy⁄Legal team is responsible for developing the relevant policies and procedures.
 
The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31, as well as resources described under the Abuse and Compliance Team. The following resources are available from those teams:

Customer Support – 12 employees
Policy⁄Legal – 2 employees
Abuse and Compliance Monitoring Team – 4 employees

The dotMusic Registry, as noted in our financials, has provisioned for a community compliance and support function. Oncall 24⁄7⁄365, this team supports both the community eligibility verification functions as well as providing a Tier 2 escalation for abuse cases reported through the Tier 1 Neustar Customer Support Teams. We estimate the community and compliance support function will spend no more than 10% of their collective time responding to abuse complaints in view of the estimated registration volumes and for the following reasons:

– Registrants are verified members of an accredited .music community organization or association in order to have an “active” registration and are held to strict community eligibility requirements
– Registrants are well informed that IP protection is a fundamental priority to attain a .music domain. They risk substantial investment loss by risking non-compliance to the participation requirements in .music
– Registrants who lose their .music registrations due to non-compliance can put their related music organization or association memberships at risk
– The .music domain while market-competitive, is not a low cost domain space, which further has a cooling effect on attempted abusive registration
– Regular compliance scanning of the namespace for both community eligibility requirement conformance and abuse detection, as described in Q18 and earlier in Q28 will operate as a deterrent to abusive registration use.

29.1. Rights Protection Mechanisms

The dotMusic Registry is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms contained in the Applicant Guidebook. .music recognizes that although the New gTLD program includes significant protections beyond those that were mandatory for a number of the current TLDs, a key motivator for .music’s selection of Neustar as its registry services provider is Neustar’s experience in successfully launching a number of TLDs with diverse rights protection mechanisms, including many the ones required in the Applicant Guidebook. More specifically, .music will implement the following rights protection mechanisms in accordance with the Applicant Guidebook and its Community requirements as further described below:

• Trademark Clearinghouse: a one-stop shop so that trademark holders can protect their trademarks with a single registration.
• Sunrise and Trademark Claims processes for the TLD.
• Implementation of the Uniform Dispute Resolution Policy to address domain names that have been registered and used in bad faith in the TLD.
• Uniform Rapid Suspension: A quicker, more efficient and cheaper alternative to the Uniform Dispute Resolution Policy to deal with clear cut cases of cybersquatting.
• Implementation of a Thick WHOIS making it easier for rights holders to identify and locate infringing parties
• Sunrise Eligibility Requirements (SERs).
• Music Eligibility Dispute Resolution Process (MEDRP).
• The .music TLD will use a variety of online scanning tools that search for key words that are commonly used to signal the availability of music distributed without appropriate authorization or in violation of intellectual property rights to aid in mitigating copyright infringement.
• We will engage an abuse detection and prevention team


A. Trademark Clearinghouse Including Sunrise and Trademark Claims

The first mandatory rights protection mechanism (“RPM”) required to be implemented by each new gTLD Registry is support for, and interaction with, the trademark clearinghouse. The trademark clearinghouse is intended to serve as a central repository for information to be authenticated, stored and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the trademark clearinghouse will interact with each registry operator and registrars, .Music is actively monitoring the developments of the Implementation Assistance Group (“IAG”) designed to assist ICANN staff in firming up the rules and procedures associated with the policies and technical requirements for the trademark clearinghouse. In addition, .music’s back-end registry services provider is actively participating in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible and implementable.

Utilizing the trademark clearinghouse, all operators of new gTLDs must offer: (i) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a trademark claims service for at least the first 60 days that second-level registrations are open. The trademark claim service is intended to provide clear noticeʺ to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.
 
B. Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS)

1. UDRP

The UDRP is intended as an alternative dispute resolution process to transfer domain names from those that have registered and used domain names in bad faith. Although there is not much of an active role that the domain name registry plays in the implementation of the UDRP, Neustar has closely monitored UDRP decisions that have involved the TLDs for which it supports and ensures that the decisions are implemented by the registrars supporting its TLDs. When alerted by trademark owners of failures to implement UDRP decisions by its registrars, Neustar either proactively implements the decisions itself or reminds the offending registrar of its obligations to implement the decision. 
 
2. URS
In response to complaints by trademark owners that the UDRP was too cost prohibitive and slow, and the fact that more than 70 percent of UDRP cases were “clear cut” cases of cybersquatting, ICANN adopted the IRT’s recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a Uniform Rapid Suspension System (“URS”). The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet.
 
The URS is not meant to address Questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place.
 
Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the registry-level. For example, rather than requiring the registrar to lock down a domain name subject to a UDRP dispute, it is the registry under the URS that must lock the domain within 24hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names.
 
In addition, in the event of a determination in favor of the complainant, the registry is required to suspend the domain name. This suspension remains for the balance of the registration period and would not resolve the original website. Rather, the nameservers would be redirected to an informational web page provided by the URS Provider about the URS. 
Additionally, the WHOIS reflects that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates.
 
.music is fully aware of each of these requirements and will have the capability to implement these requirements for new gTLDs. In fact, during the IRT’s development of f the URS, Neustar began examining the implications of the URS on its registry operations and provided the IRT with feedback on whether the recommendations from the IRT would be feasible for registries to implement. 
Although there have been a few changes to the URS since the IRT recommendations, Neustar continued to participate in the development of the URS by providing comments to ICANN, many of which were adopted. As a result, Neustar is committed to supporting the URS for all of the registries that it provides back-end registry services.

3. CEDP

The mission of .music is to serve and represent the interests and defining elements of its membership. Appropriately, .music will develop a dispute process for members of the .music community to dispute .music domain activity that violates the RRA, RA, published acceptable use policy and⁄or community eligibility requirements for .music community membership. The CEDP will be available from the initiation of Sunrise through the ongoing operation of the registry during general availability. .music will engage ICANN accepted dispute resolution providers such as WIPO to adjudicate the CEDP and bind all relevant parties through the RRA and RA to comply with the finding of the arbitrators.
 
C. Implementation of Thick WHOIS

The .music registry will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.
 
D. Policies Handling Complaints Regarding Abuse

In addition the Rights Protection mechanisms addressed above, 〈tApplicant〉 will implement a number of measures to handle complaints regarding the abusive registration of domain names in its TLD as described in.musicʹs response to Question 28.

Registry Acceptable Use Policy
One of the key policies each new gTLD registry is the need to have is an Acceptable Use Policy that clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take the appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring to the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. .music’s Acceptable Use Policy, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy.
Monitoring for Malicious Activity 
.music is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the TLD, community requirements, or is part of a real-time investigation by law enforcement. 
Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on “ServerHold”. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

Reducing Opportunities for Behaviors such as Phishing or Pharming

Due to the extensive and exhaustive mark requirements and trademark validation protocols during Sunrise, the registration of effective Phishing domains during the startup period is effectively prevented. Pharming opportunities will be diminished since pharming requires an initially resolving domain and because Sunrise application will only result in resolving domains after the close of the Sunrise period.
Question 28 (“Abuse Prevention and Mitigation”) outlines our considerable and strong anti-abuse program. Our program has been effective is shutting down phishing and pharming and has the ability for quick takedown of domain name abuses. This program will prove a deterrent to the criminal element since it greatly reduces attempts to initiate phishing domains without infringing upon the rights of legitimate registrants. Similarly, pharming is typically done by redirecting traffic at the recursive DNS level; therefore, intervention at the ISP level has proven effective in curtailing this activity. By producing and maintaining related educational FAQs on related DNS security together with providing educational materials on how pharming works on the Registry’s public website, we will support ISP mitigation initiatives. These programs are designed for use in the Land Rush and Open Registration periods. 

29.2 Safeguards against Unqualified Registrations

Robust Sunrise Program
Sunrise
In order to fully maximize the awareness of potential trademark holders, the .Music Sunrise will be strategically marketed both directly to the general public as well as Reseller channels. Domains that are open to application will be specified through our Sunrise policy. 
The Sunrise period will include a two week quiet period and will operate for a minimum of 30 days prior to the general availability of domain names. While the work connected to Trademark Clearinghouse matches and related notifications are being completed, the registration functions will not be available throughout the quiet period.
Eligible Rights
The proposed Sunrise Eligibility Requirements (SERs) will be congruent to the following qualifications which were taken from many previous TLD Sunrise programs:
(i) Ownership of a qualifying mark. 
a. See Section 7.2, number (i): The registry will honor and recognize all word marks that are regionally or nationally registered. The Trademark Clearinghouse would have had to have received and validated proof of use of the word mark – either by a declaration or a single specimen of current use.
b. Trademarks not listed in the Clearinghouse but which are verified by a third party validation contractor and which conform to the following standards will be honored and recognized:
i. the Domain Name is identical to the textual or word elements of the trademark or service mark registration on which the registration of the Domain Name is based , AND
ii. the trademark or service mark registration on which the registration of the Domain Name is based is of national effect; AND
iii. the trademark or service mark registration on which the registration of the Domain Name was based was issued (registered) prior to [a cutoff date to be determined].
iv. representation that all provided information is true and correct; and
v. provision of data sufficient to document rights in the trademark.

(ii) Applicant must be verified as a member of the .Music community.
i. Applicant must have declared related membership in an accredited .music member association.
ii. Submitted Applicant information will be submitted to their declared member association. Applicants not found on the rosters of the member association may be declared invalid by the member association. Applicants found to have applied for a domain without community membership will be subject to the Acceptable Use Policy and will forfeit the domain.
iii. Applicant must be clear of all dispute processes (including the Community Eligibility Dispute Process prior to acceptance of their Sunrise applications. 


Application Process
Submissions received during Sunrise will be accepted as applications only. Once the Trademark has been declared to conform to the SERs listed above, it will be accepted as a full registration. Multiple applications for the same string will be allowed from multiple Trademark holders. Where more than one qualifying applicant exists, contention will be resolved through auction. The application will be promoted to a full domain registration if there is a single qualifying applicant or if an auction has been won in the case of more than one qualifying applicant.
Trademark Validation and Safeguards
Sunrise applications will be examined by a third party Trademark validator as permitted⁄approved by ICANN. This validator will have global experience and thus be well versed in intellectual property law and will engage the following process and functions:
Examination of Trademark
Trademarks will be validated against either the Trademark Clearinghouse, or against a National Trademark Database from a qualifying country. This is a strict requirement for a Sunrise application to be considered “qualified or validated”.
Additional Information
Any Sunrise application will be subject to a request for additional information or clarifying documents as decided by the Trademark Validator. This may include direct verification of the applicant’s identity with respect to the cited trademark.
Deterrents
Administration fees associated with filing Sunrise applications are NOT refundable. We will make this abundantly clear in policy documents, training materials and FAQs. This administration fee is designed to recover validation costs and will discourage frivolous applications.
Contending Applications, Sunrise Auctions
Following the close of the Sunrise period, the Registry will complete all Sunrise application validations. The only three outcomes and subsequent actions are as follows:
• Outcome: Only one valid application is received for a given string.
Action: The domain will be awarded to that applicant.

• Outcome: Two or more valid applications are received for the same string.
Action: The domain will be offered to the applicants at auction. The highest bidder will be awarded the domain.

• Outcome: No valid applications are received for a given string.
Action: The domain will be offered in subsequent phases of the Registry but without Trademark requirements.

Additional Considerations 
It may take some time to conduct a Sunrise auction and these will likely overlap other phases such as Landrush. If no applicant places a bid at auction, then the domain will be awarded to the first valid application.
Parties who may wish to file a UDRP or CEDP challenge will have 60 days in which to do so. During this time, domains awarded under Sunrise will be locked (Sunrise lock status)
Once a Sunrise domain is awarded, it will be promoted to a full registration and the relevant (RDDS) Whois data will be published as per standard Registry (RDDS) Whois policy.
Conflict of Interest restrictions will be applied to employees, contractors, consultants and significant investors of the Registry disallowing participation in Sunrise auctions.
29.3 Resourcing Plans
The rights protection mechanisms described in the response above involve a wide range of tasks, procedures, and systems. The responsibility for each mechanism varies based on the specific requirements. In general the development of applications such as sunrise and IP claims is the responsibility of the Engineering team, with guidance from the Product Management team. Customer Support and Legal play a critical role in enforcing certain policies such as the rapid suspension process. These teams have years of experience implementing these or similar processes. 
The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31. The following resources are available from those teams:
Development⁄Engineering – 19 employees
Product Management- 4 employees
Customer Support – 12 employees
Abuse and Compliance Monitoring Team – 4 employees
.Music, as noted in our financials, has provisioned for a community compliance and support function. Oncall 24⁄7⁄365, this team supports both the community eligibility verification functions as well as providing response and support required for the related dispute process beyond Neustar customer support. We estimate the community and compliance support function will spend no more than 5% of their collective time responding to related dispute procedures in view of the estimated registration volumes and for the following reasons:
– Registrants are verified members of an accredited .Music community organization or association in order to have an “active” registration and are held to strict community eligibility requirements
– Registrants are well informed that IP protection is a fundamental priority to attain a .Music domain. They risk substantial investment loss by risking non-compliance to the participation requirements in .Music
– Registrants who lose their .Music registrations due to non-compliance can put their related music organization or association memberships at risk

30.(a).1 Security Policies


.MUSIC LLC and our back-end operator, Neustar recognize the vital need to secure the systems and the integrity of the data in commercial solutions. The .music registry solution will leverage industry-best security practices including the consideration of physical, network, server, and application elements. 

Neustarʹs approach to information security starts with comprehensive information security policies. These are based on the industry best practices for security including SANS (SysAdmin, Audit, Network, Security) Institute, NIST (National Institute of Standards and Technology), and CIS (Center for Internet Security). Policies are reviewed annually by Neustarʹs information security team.


The following is a summary of the security policies that will be used in the dotMusic Registry, including:


1. Summary of the security policies used in the registry operations

2. Description of independent security assessments

3. Description of security features that are appropriate for .music

4. List of commitments made to registrants regarding security levels



.MUSIC LLC is a newly formed entity to service the dotMusic Registry. As per our plans described in Qs46-50, most staffing and front office services required to operate the registry will be developed during our ramp-up period to launching the registry. As such, .music has decided to adopt the applicable security practices of our registry service provider Neustar for the following reasons: 1) Neustarʹs policies and practices are far more extensive than ICANNʹs requirements; 2) These security policies and practices fully envelop and exceed the considerations of registry front-end services; 3) Neustarʹs practices represent registry industry specialization and best of breed practices. 

All of the security policies and levels described in this section are appropriate for the .music registry.

30.(a).2 Summary of Security Policies 


Neustar has developed a comprehensive Information Security Program in order to create effective administrative, technical, and physical safeguards for the protection of its information assets, and to comply with Neustarʹs obligations under applicable law, regulations, and contracts. This Program establishes Neustarʹs policies for accessing, collecting, storing, using, transmitting, and protecting electronic, paper, and other records containing sensitive information.

-The policies for internal users and our clients to ensure the safe, organized and fair use of information resources.

-The rights that can be expected with that use. 

-The standards that must be met to effectively comply with policy.

-The responsibilities of the owners, maintainers, and users of Neustarʹs information resources.

-Rules and principles used at Neustar to approach information security issues



The following policies are included in the Program:

1. Acceptable Use Policy

The Acceptable Use Policy provides the rules of behavior covering all Neustar Associates for using Neustar resources or accessing sensitive information.



2. Information Risk Management Policy

The Information Risk Management Policy describes the requirements for the on-going information security risk management program, including defining roles and responsibilities for conducting and evaluating risk assessments, assessments of technologies used to provide information security and monitoring procedures used to measure policy compliance.



3. Data Protection Policy 

The Data Protection Policy provides the requirements for creating, storing, transmitting, disclosing, and disposing of sensitive information, including data classification and labeling requirements, the requirements for data retention. Encryption and related technologies such as digital certificates are also covered under this policy.



4. Third Party Policy

The Third Party Policy provides the requirements for handling service provider contracts, including specifically the vetting process, required contract reviews, and on-going monitoring of service providers for policy compliance.



5. Security Awareness and Training Policy

The Security Awareness and Training Policy provide the requirements for managing the on-going awareness and training program at Neustar. This includes awareness and training activities provided to all Neustar Associates. 



6. Incident Response Policy

The Incident Response Policy provides the requirements for reacting to reports of potential security policy violations. This policy defines the necessary steps for identifying and reporting security incidents, remediation of problems, and conducting lessons learned post-mortem reviews in order to provide feedback on the effectiveness of this Program. Additionally, this policy contains the requirement for reporting data security breaches to the appropriate authorities and to the public, as required by law, contractual requirements, or regulatory bodies.



7. Physical and Environmental Controls Policy

The Physical and Environment Controls Policy provides the requirements for securely storing sensitive information and the supporting information technology equipment and infrastructure. This policy includes details on the storage of paper records as well as access to computer systems and equipment locations by authorized personnel and visitors.



8. Privacy Policy

Neustar supports the right to privacy, including the rights of individuals to control the dissemination and use of personal data that describes them, their personal choices, or life experiences. Neustar supports domestic and international laws and regulations that seek to protect the privacy rights of such individuals.



9. Identity and Access Management Policy

The Identity and Access Management Policy covers user accounts (login ID naming convention, assignment, authoritative source) as well as ID lifecycle (request, approval, creation, use, suspension, deletion, review), including provisions for system⁄application accounts, shared⁄group accounts, guest⁄public accounts, temporary⁄emergency accounts, administrative access, and remote access. This policy also includes the user password policy requirements. 



10. Network Security Policy

The Network Security Policy covers aspects of Neustar network infrastructure and the technical controls in place to prevent and detect security policy violations. 



11. Platform Security Policy

The Platform Security Policy covers the requirements for configuration management of servers, shared systems, applications, databases, middle-ware, and desktops and laptops owned or operated by Neustar Associates.



12. Mobile Device Security Policy

The Mobile Device Policy covers the requirements specific to mobile devices with information storage or processing capabilities. This policy includes laptop standards, as well as requirements for PDAs, mobile phones, digital cameras and music players, and any other removable device capable of transmitting, processing or storing information.



13. Vulnerability and Threat Management Policy

The Vulnerability and Threat Management Policy provides the requirements for patch management, vulnerability scanning, penetration testing, threat management (modeling and monitoring) and the appropriate ties to the Risk Management Policy.



14. Monitoring and Audit Policy

The Monitoring and Audit Policy covers the details regarding which types of computer events to record, how to maintain the logs, and the roles and responsibilities for how to review, monitor, and respond to log information. This policy also includes the requirements for backup, archival, reporting, forensics use, and retention of audit logs.



15. Project and System Development and Maintenance Policy

The System Development and Maintenance Policy covers the minimum security requirements for all software, application, and system development performed by or on behalf of Neustar and the minimum security requirements for maintaining information systems.



30.(a).3 Independent Assessment Reports



Neustar IT Operations is subject to yearly Sarbanes-Oxley (SOX), Statement on Auditing Standards #70 (SAS70) and ISO audits. Testing of controls implemented by Neustar management in the areas of access to programs and data, change management and IT Operations are subject to testing by both internal and external SOX and SAS70 audit groups. Audit Findings are communicated to process owners, Quality Management Group and Executive Management. Actions are taken to make process adjustments where required and remediation of issues is monitored by internal audit and QM groups.

External Penetration Test is conducted by a third party on a yearly basis. As authorized by Neustar, the third party performs an external Penetration Test to review potential security weaknesses of network devices and hosts and demonstrate the impact to the environment. The assessment is conducted remotely from the Internet with testing divided into four phases:


-A network survey is performed in order to gain a better knowledge of the network that was being tested

-Vulnerability scanning is initiated with all the hosts that are discovered in the previous phase

-Identification of key systems for further exploitation is conducted

-Exploitation of the identified systems is attempted.



Each phase of the audit is supported by detailed documentation of audit procedures and results. Identified vulnerabilities are classified as high, medium and low risk to facilitate managementʹs prioritization of remediation efforts. Tactical and strategic recommendations are provided to management supported by reference to industry best practices.



30.(a).4 Augmented Security Levels and Capabilities


There are no increased security levels specific for .music. However, Neustar will provide the same high level of security provided across all of the registries it manages. 


A key to Neustarʹs operational success is Neustarʹs highly structured operations practices. The standards and governance of these processes:

 
-Include annual independent review of information security practices 

-Include annual external penetration tests by a third party 

-Conform to the ISO 9001 standard (Part of Neustarʹs ISO-based Quality Management System)

-Are aligned to Information Technology Infrastructure Library (ITIL) and CoBIT best practices 

-Are aligned with all aspects of ISO IEC 17799

-Are in compliance with Sarbanes-Oxley (SOX) requirements (audited annually)

-Are focused on continuous process improvement (metrics driven with product scorecards reviewed monthly).



A summary view to Neustarʹs security policy in alignment with ISO 17799 can be found in section 30.(a).5 below.



30.(a).5 Commitments and Security Levels 



The .music registry commits to high security levels that are consistent with the needs of the TLD. These commitments include:



Compliance with High Security Standards


-Security procedures and practices that are in alignment with ISO 17799

-Annual SOC 2 Audits on all critical registry systems

-Annual 3rd Party Penetration Tests 

-Annual Sarbanes Oxley Audits



Highly Developed and Document Security Policies


-Compliance with all provisions described in section 30.(b) and in the attached security policy document.

-Resources necessary for providing information security

-Fully documented security policies

-Annual security training for all operations personnel



High Levels of Registry Security


-Multiple redundant data centers

-High Availability Design

-Architecture that includes multiple layers of security

-Diversified firewall and networking hardware vendors

-Multi-factor authentication for accessing registry systems

-Physical security access controls

-A 24x7 manned Network Operations Center that monitors all systems and applications

-A 24x7 manned Security Operations Center that monitors and mitigates DDoS attacks

-DDoS mitigation using traffic scrubbing technologies